1 / 16

Janet Gunn, CSC janet.gunn@dyncorp Dennis Berg , CSC dennis.berg@dyncorp

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.

joylyn
Download Presentation

Janet Gunn, CSC janet.gunn@dyncorp Dennis Berg , CSC dennis.berg@dyncorp

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. Outline • Introduction • Scope • Reference topology • Recommendations • Paths forward

  3. 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

  4. 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”

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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)

  16. 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

More Related