IETF-Vienna IEPREP WG, July 2003 Ken Carlberg

Discussion Update –draft-ietf-ieprep-framework-05.txt –draft-ietf-ieprep-ets-general-03.txt –draft-ietf-ieprep-ets-telephony-05.txt New Material –draft-carlberg-ets-stub-frame-00.txt –draft-carlberg-ets-req-stub-00.txt

draft-ietf-ieprep-framework-05.txt rewrote “Objectives” section –Confusion still existed in its relation to “Protocols & Mechanisms” section Inserted “Considerations” section To Be Done –Insert correction suggested by Dennis Berg –Another scrubbing of the draft

draft-ietf-ieprep-ets-general-03.txt Last Call (early Feb) –comments made on list, responses provided AD change Changes requested by AD (early June) –Added a boiler plate and reference to rfc-2119 –Capitalized the normative keywords in Requirements 5-7 –Separated the security related requirements –Added a reference to rfc-3487 under the subject of "related work" –Added the caveat that integrity checks can themselves be a target for DoS attacks –Added sentence describing IAA application –Added a note discussing what is a “label”

draft-ietf-ieprep-ets-telephony-05.txt Last Call ( Feb 2) –comments made on list, responses provided Changes requested by AD (Jun 7) –Added a boiler plate and reference to rfc-2119

New Material Stems from discussion at San Francisco IETF, and subsequent thread on IEPREP list –Focus on support of ETS within a Stub Domain Resources under a single authority Use similar Requirements/Framework approach in presenting material Note: Overlap can occur with other drafts Not focused on a particular application nor set of users

draft-carlberg-ets-req-stub-00.txt Builds on General Requirements Define terms –Stub, Transit, Resource, etc. Requirements –Application & transport must avoid “on/off” label mech. –Network should avoid “on/off” –Proxies may set ETS labels –QoS mechanisms should be used when over-provisioning cannot be achieved –Appl layer mechanisms must support ETS & non-ETS users Requirements (cont.) –Policy must be used to determine % of resources –Discovery may be used to determine where to forward ETS labeled flows –MIBs should be defined for ETS related mechanisms –Security (?) does something more need to stated beyond the General Requirements draft –NAT/PAT (?)

draft-carlberg-ets-req-stub-00.txt Issues –Discussion of different services: better than best effort, best available, and degraded service –“Emergency” ITU uses the term “Telecommunications for Disaster Relief” –Redundancy – a means of making networks fault tolerant

draft-carlberg-ets-stub-frame-00.txt Scope –Focusing on protocols and mechanisms that can be applied within a domain –Access links between the stub and transit are out of scope Common Practice: Provisioning Scenarios –User in a Home network –User in a Foreign network

Framework: Topic Areas MPLS –RFC 3270: MPLS support for Diff-Serv mapping 3-bit EXP field with PHB Subnet Technologies –802.1d 3-bit Priority Field –Cable (DOCSIS) Uses 802.1d frames RSVP –RFC 3209: Extensions for LSP Tunnels –RFC 2750: Extensions for Policy Control Policy –COPS (RFC 2748) Policy control of QoS signaling protocols like RSVP

Framework: Topic Areas (cont.) Multicast –One-to-many distribution model Compliments the push-to-talk communication used by First Responders –IP (PIM/IGMP) and 802.1d Becoming more common in the IP enterprise/subnets Discovery –Service Location Protocol –Anycasting

Framework: Topic Areas (cont.) Mobility –Home Agent / Foreign Agent & triangle routing supports application layer transparency Diff-Serv –Points to old Baker BCP draft –Should discuss space of experimental codes points Middle Boxes (?) VPN(?)

Final Comments What’s missing? Should a different direction be taken? Should these “stub” contributions become working group items?