160 likes | 191 Views
MPLS IP Bridging Configuration Guidance for IEPREP. Janet Gunn, CSC janet.gunn@dyncorp.com Dennis Berg , CSC dennis.berg@dyncorp.com Pat McGregor, Nyquetek pat_mcgregor@msn.com Richard Kaczmarek, Nyquetek richard.kaczmarek@dyncorp.com. IETF 57 Vienna, Austria 16 July 2003. Outline.
E N D
MPLS IP Bridging Configuration Guidance for IEPREP Janet Gunn, CSC janet.gunn@dyncorp.com Dennis Berg, CSC dennis.berg@dyncorp.com Pat McGregor, Nyquetek pat_mcgregor@msn.com Richard Kaczmarek, Nyquetek richard.kaczmarek@dyncorp.com IETF 57 Vienna, Austria 16 July 2003
Outline • Introduction • Scope • Reference topology • Recommendations • Paths forward
Ieprep charter calls for following: The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. Deliverables - Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protocols and what can not be done. ID responds for one specific network scenario: Single-domain IP bridging topology IP telephony-enabled Examples CSN carrier with IP-based transport island CSN LEC through IP IXC to CSN LEC Introduction
List Discussions – Scope Issue • Document contains several recommendations for use of “experimental and local” parameter values • Authors assumed position that BCP could recommend consistent use of such experimental and local values • No intention to bypass normal review process for assignment of values to variables • “RECOMMENDS” practice of consistent use of values • “Suggests” these values be standardized • Feedback from list – such recommendations need to be worked through the normal IETF standards process • Will address at end under “Paths Forward”
Reference Network Topology Signaling Signaling Gateway Gateway STP STP Media Gateway Controller CSN CSN Switch Switch (Access (Access Tandem) Tandem) Media Media Gateway Gateway Single Gateway Gateway IP CSN CSN Telephony Domain Media Gateway Controller LSR LSR
SS7 Recommendations • R-1. Use the IP protocol stack “M2UA over SCTP over IP” for ETS SS7 call signaling between the SG and MGC • Contrary to using M3UA, M2UA allows retention of MTP3 with its existing congestion priority treatment function • E.g., GETS IAMs at priority 1; POTS IAMs at priority 0 • Facilitates reuse of existing STP application software by keeping MTP3 and application level software intact and unchanged • Assumed signaling for the baseline telephony application - nothing special for ETS
SS7 Recommendations (cont.) • R-2. Preserve the CSN (international and /or national) ETS call marking(s) and associated SS7 congestion priorities in the SS7 messages from SG to MGC • Meets [ETS Tel Req] #3 “Telephony signaling labels should have a mapping with the various emergency-related markings … used in …the PSTN” • E.g., in the U.S.A. the NSEP codepoint in the Calling Party Category (CPC) and, if present, the optional Precedence parameter • R-3. Preserve the IP network (international and /or national) ETS call marking(s) and associated congestion priorities in the call setup IAM from the IP network to the CSN • Preserves the ETS labeling into the destination network
DiffServ Recommendations • R-4. Assign two values from the experimental and local use pool of Differentiated Services codepoints for International ETS and National ETS. • Consistent with [IP Tel Frame], Sec 4.1.2 • Need separate ETS treatment because ETS must continue to function during extraordinary events (e.g., causing exceptional outages and / or congestion) beyond control of normal algorithms for admission control and policing • In these scenarios, normal QoS assurances are at risk • Recommending distinction of national / international for consistency with ITU-T E.106 • R-5. Recommended values: • National Emergency = 011111 • International Emergency = 011011 • Recommending consistent practice of using these specific values as a prelude to standardization
DiffServ Recommendations (cont.) • R-6. Functionally specify the International ETS PHB and National ETS PHB to be locally administered, additional instances of the EF PHB, with possibly different parameter values • Separate ETS DiffServ codepoints allows separate ETS PHB • EF PHB functionality is sufficient, but need separate instance with capability to set more stringent ETS-specific parameters, and to distinguish ETS traffic • Using additional instances of an existing PHB eliminates the need for new protocol extension, minimizes the additional development and reduces the probability of unintended consequences
MPLS Recommendations • R-7. Separate ETS traffic treatment, both signaling and data, from other traffic treatment by the use of a dedicated MPLS DiffServ codepoint in E-LSPs and specify application of an ETS PHB • Preferred to alternative of dedicating LSPs to ETS, which increases operational complexity and reduces bandwidth available for other traffic even when not in use for ETS traffic • R-8. Use the same MPLS DiffServ codepoint for both National and International ETS traffic • Insufficient MPLS DiffServ codepoints available to assign separate codepoints to National and International ETS traffic
MPLS LSPs Recommendations • R-9. Use MPLS DiffServ codepoint 6 for ETS traffic (both National and International) • Only two “open” codepoints in local pool (6 & 7) and 7 used for network management • R-10. Associate the DiffServ ETS PHB with the MPLS DiffServ ETS codepoint. • Ties together DiffServ and MPLS labeling and behavior in the appropriate way
SIP Recommendations • R-11. Set existing SIP Priority header field to value "emergency“ for ETS calls • Employs existing, approved parameter to notify the user of ETS identity of call • Has no affect on network behavior • Completely separate recommendation from the Resource Priority Header
SDP Recommendations • R-12. Use SDP attribute parameters to specify ETS sessions as either • National Emergency sessions using attribute parameter value "x-NatETS" or • International Emergency sessions using the attribute parameter value "x-IntETS" • SDP attributes parameters are used to ascribe attributes to the session • "x" designates non-standard values • SDP attributes can be applied now whereas RPH still to be standardized • Certain session treatments of ETS interest (such as codec selection, rate tolerance, and willingness to queue for session resources) may be influenced by this labeling
MEGACO Recommendations • R-13.For ETS calls, use MEGACO ContextRequest parameter for “emergency” (Boolean) to indicate “emergency” and MEGACO ContextRequest parameter for “priority” with priorities 11-15 • These are existing optional parameters - no extension to existing protocol • Context parameter is used to provide the MG with information for precedence handling
Paths Forward • Issued as “BCP”, but list discussion has suggested other options • Experimental • Informational • “Unofficial” • List discussions also suggested creating several requirements I-Ds, one for each relevant protocol (e.g., MPLS, DiffServ, SDP, MEGACO)
Document Links • Published IETF I-D • MPLS IP Bridging Configuration Guidance for IEPREP • http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt • Most recent version • IP Bridging Configuration Guidance for IEPREP • https://gets-ic-pmo.is.dyncorp.com/IETF/Documents.htm