Internet Draft ETS Gap Analysis December 19th, 2003 Internet Engineering Task Force Janet P. Gunn Internet Draft Dennis Berg Expiration: June 19 2004 CSC File: draft-gunn-ieprep-ip-telephony-gap-00.txt Pat McGregor Nyquetek Inc. Gap Analysis for Meeting Emergency Telecommunications Service (ETS) Requirements with DIFFSERV and MPLS in a Single IP Telephony Domain December 19, 2003 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a gap analysis for meeting ETS requirements using DIFFSERV and MPLS with reference to one particular network scenario: implementing Internet Telecommunications Disaster Recovery (ETS) service in the context of IP Telephony in a private IP network designed, engineered and managed with telephony (using DIFFSERV and MPLS) as the dominant application. Gunn Page 1 Internet Draft ETS Gap Analysis December 19th, 2003 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 Reference Network Topology . . . . . . . . . . . . . . . . . . 3 3.0 User Requirements. . . . . . . . . . . . . . . . . . . . . . . 4 4.0 Constraining Requirements. . . . . . . . . . . . . . . . . . . 5 5.0 DIFFSERV Gap Identification. . . . . . . . . . . . . . . . . . 5 6.0 MPLS Gap Identification. . . . . . . . . . . . . . . . . . . . 6 7.0 Security Considerations . . . . . . . . . . . . . . . . . . . 7 8.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9.0 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 11.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.0 Author Information . . . . . . . . . . . . . . . . . . . . . . 8 13.0 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.0 Introduction This document presents a gap analysis for meeting ETS requirements using DIFFSERV and MPLS with reference to one particular network scenario: implementing Internet Telecommunications Disaster Recovery (also known as Emergency Telecommunications Service, or ETS) service in the context of IP Telephony in a private IP network designed, engineered and managed with telephony (using DIFFSERV [DIFFSERV]and MPLS[MPLS]) as the dominant application. In this particular network scenario, the IP network serves only as a transit network, with all ETS calls originating and terminating in the Circuit Switched Network (CSN). This topology is referred to as "IP Bridging", or "IP in the Middle" [IEPREP Term]. This document has the following sections: 1) Introduction 2) Reference Network Topology 3) User Requirements 4) Constraining Requirements 5) DIFFSERV Gap Identification 6) MPLS Gap Identification 7) Security Considerations 8) IANA Considerations 9) Conclusion 10)Acknowledgements 11)References 12)Author Information Comments should be sent to Janet Gunn at jgunn6@csc.com Gunn Page 2 Internet Draft ETS Gap Analysis December 19th, 2003 2.0 Reference Network Topology The IP Bridging Topology is defined in [IEPREP Term] and is sometimes known as "IP in the Middle" of two CSNs. In this topology, a CSN phone of any type initiates (dials) a call to another CSN phone with an IP core between the two CSNs. For purposes of this document, the IP in the middle is a single domain, telephony-enabled, IP network (using DIFFSERV and MPLS) without issues of technological continuity and interfacing that arise with multiple domains. This topology should simplistically look like this: ----------------->+<--------IP-Based Telephony Network------>+<-------- ----- --------------+ +----+ +----+ +---------- | | | | | | STP.....|....|.SG | | SG.|....|....STP : | | : | | : | | : : | | : | +--------------+ | : | | : : | | MGC| | | | MGC| | : : | | : | | | | : | | : : | | : | | | | : | | : AT ------->| MG |------LSR -----LSR----->| MG |--------> AT | | | | | | | | | +----+ | | +----+ | -----------+ +--------------+ +----------- Exploded "IP Bridging" Topology This diagram is intended to portray a possible CSN carrier that has introduced an IP transport island into his network, or, perhaps more generally, a CSN Local Exchange Carrier (LEC) transiting an IP Interexchange Carrier to another CSN LEC. Note that although the topology shows the SG connected directly to the MGC and the MGC connected directly to the MG, these connections should be viewed as logical connections, physically formed by LSPs through the LSRs, with the SG, MGC, and MG all actually connected to the LSRs. The baseline telephony application design for this topology is assumed to be bearer traffic from AT to MG and MG to AT via conventional TDM trunks and from MG to LSR to LSR to MG via E-LSPs providing EF PHB supporting RTP media exchange between the MGs. The reference topology is assumed implemented for voice traffic using DIFFSERV and MPLS. Gunn Page 3 Internet Draft ETS Gap Analysis December 19th, 2003 3.0 User Requirements Requirements for generic ETS are presented in [IEPREP Rqmts] and augmented with telephony-specific requirements in [IEPREP IP Tel Rqmts]. Requirements for specific providers will be specified in individual SLAs. ETS SLAs require performance to the extent possible, even under circumstances of extraordinary demand and/or outages such as caused by Acts of God and War for which non-ETS SLAs generally take exception. Some providers of the single-domain telephony service addressed in this paper may be able to meet all SLA performance metrics for telephony ETS calls (e.g., low probability of blocking and toll quality voice) without a distinct service for ETS traffic. An example would be a single-domain provider whose sum of domain access capacities is less than the capacity of every possible path over which concurrent traffic might be routed. Other providers may be in a situation where their network can become congested (and SLA ETS performance compromised), either as a result of extraordinary access demand, combined with statistically rare burstiness, exceeding transport capacity, or as a result of transport capacity being reduced by outages, or by a combination of extraordinary demand and outages. For these providers to meet SLA ETS performance objectives during severe network stress, mechanisms must be provided by which ETS traffic can be recognized and afforded some form of treatment that enables its performance objectives to be met. For convenience, we refer this as an SLA requirement to ensure ETS. By addressing the signaling requirements at the application layer, ETS traffic can be recognized at the application layer and resources under application control can be managed to ensure their role in ETS, i.e., a low probability of blocking may be achieved at the application layer by Call Access Control. Although this is necessary, it is not sufficient if the lower layers do not have means of supporting such allocation on a sustained (i.e. duration of the call) basis. In this context, "allocation" may be viewed as any techniques that ensure ETS traffic receives the resources necessary to achieve its SLA performance specifications. The gap analysis presented here addresses the need for certain single- domain telephony bridging providers to be able to support ETS SLAs to provide: High Probability Toll-Quality Voice - ETS calls must be given adequate resources through the network to ensure a high probability that their packets suffer loss, delay, and jitter consistent with achieving toll- quality voice even when network congestion and / or damage are severe. Gunn Page 4 Internet Draft ETS Gap Analysis December 19th, 2003 It is recognized that the SLA requirements must be subject to physical connectivity survival and capacity limitations, and that ETS traffic may be limited by the provider in terms of its absolute and/or relative utilization of the total available capacity. Sessions identified as ETS could be processed as normal traffic along with all non-emergency traffic when sufficient network bandwidth and resources are available. 4.0 Constraining Requirements Besides the relevant requirements from IEPREP documents, and the user requirements above, the following general requirements are proposed to bear upon the gap analysis: REQ-1) Whether or not ETS calls are being served, the impact on non-ETS calls SHOULD be minimized, consistent with providing the ETS service. REQ-2) In some networks, depending on the topology and overall capacity, the service MAY impose a limit on the resources that can be used by ETS calls when there are non-ETS calls competing for those resources. REQ-3) Whether or not ETS calls are being served, the impact of the ETS service on network management and administration SHOULD be minimized, consistent with providing the ETS service. REQ-4) The additional development (by vendors) to support the ETS service SHOULD be minimized, consistent with providing the ETS service. As a consequence of REQ-4, identifying new labels and parameter values for existing protocols is preferable to inventing new protocols or completely new parameters, where possible. 5.0 DIFFSERV Gap Identification For the reference network and service scenario, the need in DIFFSERV is for a way to ensure service to ETS traffic during conditions of network traffic saturation. [IEPREP Frame] has suggested the approach of using AF instead of EF for ETS traffic to reduce the dropping probability. This approach, however, does not provide bounds on delay and jitter, so it does not appear to be acceptable in meeting the requirement for toll-quality voice. [IEPREP Frame] has alternatively suggested employing an additional Per Hop Behavior (PHB) for ETS traffic, without specifying the behavior. Using a second instance of EF, with a strict priority queue, might reduce the dropping probability, and reduce the delay and jitter, for ETS traffic. This approach, however appears to violate REQ-1 to Gunn Page 5 Internet Draft ETS Gap Analysis December 19th, 2003 minimize the impact on non-ETS VoIP traffic. As described in the Appendix to RFC 3246 [DIFFSERV EF], the bounds on delay for the (lower priority) non-ETS EF traffic would become large, or even unbounded, thereby undermining QoS for the non-ETS EF traffic. The Appendix to RFC 3246 [DIFFSERV EF] points out that multiple instances of EF with a WFQ-like scheduler could overcome the limitations of a strict priority queue by delivering delay bounds similar to a single instance of EF. Using a second instance of EF, then, with some form of Fair Weighted Queuing that recognizes ETS traffic as distinct, seems to be a viable approach. However, employing a second instance of EF would require two distinct EF DIFFSERV codepoints. Based upon this analysis there appears to be a gap in DIFFSERV in respect to providing the ETS service in the reference scenario. 6.0 MPLS Gap Identification For the reference network and service scenario, the need in MPLS [MPLS] is for a way to support DIFFSEV [MPLS DIFF] to ensure ETS telephony. For MPLS support of DIFSERV in the reference network and service, two basic approaches appear to be: 1) Define a separate MPLS codepoint to correlate with a ETS DIFFSERV codepoint 2) Implement a separate set of E-LSPs for the ETS traffic uniquely distinguished in DIFFSERV. It is recognized that MPLS LSPs [MPLS] have very limited resources for traffic differentiation, and the first (1) approach's allocating a limited traffic differentiation resources for the nominally rare, but occasionally heavy ETS traffic may be viewed as wasteful. However, the alternative approach (2) of creating a separate ETS topology of LSPs presents significant difficulties because of the ubiquitous requirement for ETS support coupled with its rare use, leading to significant maintenance and operating challenges. Thus approach (2) seems to contravene REQ-3, which cautions that the impact of ETS on network management and administration should be minimized. Complying with REQ- 3 implies that the ETS service should not be dependant on the maintenance and management of a distinct "shadow network" or VPN. Both candidate approaches have advantages and disadvantages. Approach (1) satisfies REQ-3, but exposes a gap in that there is no MPLS codepoint identified for the additional ETS DIFFSERV codepoint distinguishing ETS packets within an MPLS path also supporting non-ETS packets. Gunn Page 6 Internet Draft ETS Gap Analysis December 19th, 2003 7.0 Security Considerations There are two primary concerns: - Authorization/authentication of voice traffic which is entitled to ETS-treatment. In the reference IP Bridging topology, this authentication and authorization takes place in the CSN. The security of this authorization and authentication in the IP network is a general IP Telephony security issue, and outside the scope of his paper. - Potential for unauthorized use of ETS, and for DoS or DDoS attacks. This document recognizes these issues, but does not address them because they are out of scope for a gap analysis. 8.0 IANA Considerations There are no IANA considerations addressed in this document. The alleviation of some of the gaps identified may involve IANA considerations. 9.0 Conclusion From the perspective of the reference network topology and service there appear to be gaps in both DIFFSERV and MPLS. In their current form they cannot provide an increased probability that ETS calls will receive a satisfactory (i.e., non-degraded) quality of service in a stressed network environment while meeting REQ-1, REQ-2, REQ-3 and REQ-4. 10.0 Acknowledgements The authors would like to acknowledge the helpful comments, opinions, and clarifications of Richard Kaczmarek, as well as those comments received from the IEPREP mailing list. 11.0 References Normative [DIFFSERV] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [DIFFSERV EF] Davie, B., Charny, A., Bennett, J.C.R., K. Benson, Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., Stiliadis, D., "An Expedited Forwarding PHB (Per-Hop Behavior)" RFC 3246, March 2002 [IEPREP Term] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003. Gunn Page 7 Internet Draft ETS Gap Analysis December 19th, 2003 [MPLS] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [MPLS DIFF] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. Non-Normative [IEPREP Frame] Carlberg, K., Brown, I., Beard, C., "Framework for Supporting ETS in IP Telephony",draft-ietf-ieprep-framework-07.txt , Internet-Draft, December, 2003 . [IEPREP Rqmts] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-general-04.txt, Internet- Draft, August, 2003. [IEPREP IP Tel Rqmts] Carlberg, K., Atkinson, R., "IP Telephony Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-telephony-07.txt, Internet Draft, November, 2003. 12.0 Author Information Pat McGregor Nyquetek Inc 8397 Piping Rock Millersville, MD 21108 U.S.A. Email: pat_mcgregor@msn.com Phone: 410-703-4486 Dennis Berg CSC 15000 Conference Center Dr Chantilly, VA Email: Dberg3@CSC.com Phone: 703-818-4608 Janet Gunn CSC 15000 Conference Center Dr Chantilly, VA Email: JGunn6@CSC.com Phone: 703-818-4725 Gunn Page 8 Internet Draft ETS Gap Analysis December 19th, 2003 13.0 Acronyms The following acronyms are exploded for clarity: AT = Access Tandem CSN = Circuit Switched Network EF = Expedited Forwarding E-LSP = EXP-inferred-PSC LSPs ETS = Emergency Telecommunications Service EXP = field in MPLS label LSP = Label Switched Path LSR = Label Switching Router MG = Media Gateway MGC = Media Gateway Controller MPLS = Multi-Protocol Label Switching PHB = Per Hop Behavior PSC = PHB Scheduling Class SG = Signaling Gateway STP = Signal Transfer Point TDM = Time Division Multiplexing "Copyright (C) The Internet Society (December 19, 2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Gunn Page 9 Internet Draft ETS Gap Analysis December 19th, 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." The Expiration date for this Internet Draft is: April 19, 2004 Gunn Page 10