idnits 2.17.1 draft-gunn-ieprep-ip-telephony-gap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 55 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...calls SHOULD be minimized, consistent ...' RFC 2119 keyword, line 208: '...ity, the service MAY impose a limit on...' RFC 2119 keyword, line 213: '...nd administration SHOULD be minimized,...' RFC 2119 keyword, line 217: '...service SHOULD be minimized, consisten...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 69 has weird spacing: '...ed with telep...' == Line 164 has weird spacing: '... during sever...' == Line 303 has weird spacing: '...tion of some ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 19, 2003) is 7433 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DIFFSERV' is defined on line 325, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft ETS Gap Analysis December 19th, 2003 3 Internet Engineering Task Force Janet P. Gunn 4 Internet Draft Dennis Berg 5 Expiration: June 19 2004 CSC 6 File: draft-gunn-ieprep-ip-telephony-gap-00.txt Pat McGregor 7 Nyquetek Inc. 9 Gap Analysis for Meeting 10 Emergency Telecommunications Service (ETS) Requirements 11 with DIFFSERV and MPLS in a Single IP Telephony Domain 13 December 19, 2003 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document presents a gap analysis for meeting ETS requirements 38 using DIFFSERV and MPLS with reference to one particular network 39 scenario: implementing Internet Telecommunications Disaster Recovery 40 (ETS) service in the context of IP Telephony in a private IP network 41 designed, engineered and managed with telephony (using DIFFSERV and 42 MPLS) as the dominant application. 44 Table of Contents 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 47 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2.0 Reference Network Topology . . . . . . . . . . . . . . . . . . 3 50 3.0 User Requirements. . . . . . . . . . . . . . . . . . . . . . . 4 51 4.0 Constraining Requirements. . . . . . . . . . . . . . . . . . . 5 52 5.0 DIFFSERV Gap Identification. . . . . . . . . . . . . . . . . . 5 53 6.0 MPLS Gap Identification. . . . . . . . . . . . . . . . . . . . 6 54 7.0 Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 8.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 9.0 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 10.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 58 11.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 12.0 Author Information . . . . . . . . . . . . . . . . . . . . . . 8 60 13.0 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 1.0 Introduction 64 This document presents a gap analysis for meeting ETS requirements 65 using DIFFSERV and MPLS with reference to one particular network 66 scenario: implementing Internet Telecommunications Disaster Recovery 67 (also known as Emergency Telecommunications Service, or ETS) service in 68 the context of IP Telephony in a private IP network designed, 69 engineered and managed with telephony (using DIFFSERV [DIFFSERV]and 70 MPLS[MPLS]) as the dominant application. In this particular network 71 scenario, the IP network serves only as a transit network, with all ETS 72 calls originating and terminating in the Circuit Switched Network 73 (CSN). This topology is referred to as "IP Bridging", or "IP in the 74 Middle" [IEPREP Term]. 76 This document has the following sections: 78 1) Introduction 79 2) Reference Network Topology 80 3) User Requirements 81 4) Constraining Requirements 82 5) DIFFSERV Gap Identification 83 6) MPLS Gap Identification 84 7) Security Considerations 85 8) IANA Considerations 86 9) Conclusion 87 10)Acknowledgements 88 11)References 89 12)Author Information 91 Comments should be sent to Janet Gunn at jgunn6@csc.com 92 2.0 Reference Network Topology 94 The IP Bridging Topology is defined in [IEPREP Term] and is sometimes 95 known as "IP in the Middle" of two CSNs. In this topology, a CSN 96 phone of any type initiates (dials) a call to another CSN phone with 97 an IP core between the two CSNs. For purposes of this document, the IP 98 in the middle is a single domain, telephony-enabled, IP network (using 99 DIFFSERV and MPLS) without issues of technological continuity and 100 interfacing that arise with multiple domains. 102 This topology should simplistically look like this: 104 ----------------->+<--------IP-Based Telephony Network------>+<-------- 105 ----- 107 --------------+ +----+ +----+ +---------- 108 | | | | | | 109 STP.....|....|.SG | | SG.|....|....STP 110 : | | : | | : | | : 111 : | | : | +--------------+ | : | | : 112 : | | MGC| | | | MGC| | : 113 : | | : | | | | : | | : 114 : | | : | | | | : | | : 115 AT ------->| MG |------LSR -----LSR----->| MG |--------> AT 116 | | | | | | | | 117 | +----+ | | +----+ | 118 -----------+ +--------------+ +----------- 120 Exploded "IP Bridging" Topology 122 This diagram is intended to portray a possible CSN carrier that has 123 introduced an IP transport island into his network, or, perhaps more 124 generally, a CSN Local Exchange Carrier (LEC) transiting an IP 125 Interexchange Carrier to another CSN LEC. Note that although the 126 topology shows the SG connected directly to the MGC and the MGC 127 connected directly to the MG, these connections should be viewed as 128 logical connections, physically formed by LSPs through the LSRs, with 129 the SG, MGC, and MG all actually connected to the LSRs. 131 The baseline telephony application design for this topology is assumed 132 to be bearer traffic from AT to MG and MG to AT via conventional TDM 133 trunks and from MG to LSR to LSR to MG via E-LSPs providing EF PHB 134 supporting RTP media exchange between the MGs. 136 The reference topology is assumed implemented for voice traffic using 137 DIFFSERV 138 and MPLS. 140 3.0 User Requirements 142 Requirements for generic ETS are presented in [IEPREP Rqmts] and 143 augmented with telephony-specific requirements in [IEPREP IP Tel 144 Rqmts]. Requirements for specific providers will be specified in 145 individual SLAs. ETS SLAs require performance to the extent possible, 146 even under circumstances of extraordinary demand and/or outages such as 147 caused by Acts of God and War for which non-ETS SLAs generally take 148 exception. 150 Some providers of the single-domain telephony service addressed in this 151 paper may be able to meet all SLA performance metrics for telephony ETS 152 calls (e.g., low probability of blocking and toll quality voice) 153 without a distinct service for ETS traffic. An example would be a 154 single-domain provider whose sum of domain access capacities is less 155 than the capacity of every possible path over which concurrent traffic 156 might be routed. 158 Other providers may be in a situation where their network can become 159 congested (and SLA ETS performance compromised), either as a result of 160 extraordinary access demand, combined with statistically rare 161 burstiness, exceeding transport capacity, or as a result of transport 162 capacity being reduced by outages, or by a combination of extraordinary 163 demand and outages. For these providers to meet SLA ETS performance 164 objectives during severe network stress, mechanisms must be provided 165 by which ETS traffic can be recognized and afforded some form of 166 treatment that enables its performance objectives to be met. For 167 convenience, we refer this as an SLA requirement to ensure ETS. 169 By addressing the signaling requirements at the application layer, ETS 170 traffic can be recognized at the application layer and resources under 171 application control can be managed to ensure their role in ETS, i.e., a 172 low probability of blocking may be achieved at the application layer by 173 Call Access Control. Although this is necessary, it is not sufficient 174 if the lower layers do not have means of supporting such allocation on 175 a sustained (i.e. duration of the call) basis. In this context, 176 "allocation" may be viewed as any techniques that ensure ETS traffic 177 receives the resources necessary to achieve its SLA performance 178 specifications. 180 The gap analysis presented here addresses the need for certain single- 181 domain telephony bridging providers to be able to support ETS SLAs to 182 provide: 184 High Probability Toll-Quality Voice - ETS calls must be given adequate 185 resources through the network to ensure a high probability that their 186 packets suffer loss, delay, and jitter consistent with achieving toll- 187 quality voice even when network congestion and / or damage are severe. 189 It is recognized that the SLA requirements must be subject to physical 190 connectivity survival and capacity limitations, and that ETS traffic 191 may be limited by the provider in terms of its absolute and/or relative 192 utilization of the total available capacity. 194 Sessions identified as ETS could be processed as normal traffic along 195 with all non-emergency traffic when sufficient network bandwidth and 196 resources are available. 198 4.0 Constraining Requirements 200 Besides the relevant requirements from IEPREP documents, and the user 201 requirements above, the following general requirements are proposed to 202 bear upon the gap analysis: 204 REQ-1) Whether or not ETS calls are being served, the impact on non-ETS 205 calls SHOULD be minimized, consistent with providing the ETS service. 207 REQ-2) In some networks, depending on the topology and overall 208 capacity, the service MAY impose a limit on the resources that can be 209 used by ETS calls when there are non-ETS calls competing for those 210 resources. 212 REQ-3) Whether or not ETS calls are being served, the impact of the ETS 213 service on network management and administration SHOULD be minimized, 214 consistent with providing the ETS service. 216 REQ-4) The additional development (by vendors) to support the ETS 217 service SHOULD be minimized, consistent with providing the ETS service. 219 As a consequence of REQ-4, identifying new labels and parameter values 220 for existing protocols is preferable to inventing new protocols or 221 completely new parameters, where possible. 223 5.0 DIFFSERV Gap Identification 225 For the reference network and service scenario, the need in DIFFSERV is 226 for a way to ensure service to ETS traffic during conditions of network 227 traffic saturation. [IEPREP Frame] has suggested the approach of using 228 AF instead of EF for ETS traffic to reduce the dropping probability. 229 This approach, however, does not provide bounds on delay and jitter, so 230 it does not appear to be acceptable in meeting the requirement for 231 toll-quality voice. 233 [IEPREP Frame] has alternatively suggested employing an additional Per 234 Hop Behavior (PHB) for ETS traffic, without specifying the behavior. 235 Using a second instance of EF, with a strict priority queue, might 236 reduce the dropping probability, and reduce the delay and jitter, for 237 ETS traffic. This approach, however appears to violate REQ-1 to 238 minimize the impact on non-ETS VoIP traffic. As described in the 239 Appendix to RFC 3246 [DIFFSERV EF], the bounds on delay for the (lower 240 priority) non-ETS EF traffic would become large, or even unbounded, 241 thereby undermining QoS for the non-ETS EF traffic. 243 The Appendix to RFC 3246 [DIFFSERV EF] points out that multiple 244 instances of EF with a WFQ-like scheduler could overcome the 245 limitations of a strict priority queue by delivering delay bounds 246 similar to a single instance of EF. Using a second instance of EF, 247 then, with some form of Fair Weighted Queuing that recognizes ETS 248 traffic as distinct, seems to be a viable approach. However, 249 employing a second instance of EF would require two distinct EF 250 DIFFSERV codepoints. 252 Based upon this analysis there appears to be a gap in DIFFSERV in 253 respect to providing the ETS service in the reference scenario. 255 6.0 MPLS Gap Identification 257 For the reference network and service scenario, the need in MPLS [MPLS] 258 is for a way to support DIFFSEV [MPLS DIFF] to ensure ETS telephony. 259 For MPLS support of DIFSERV in the reference network and service, two 260 basic approaches appear to be: 262 1) Define a separate MPLS codepoint to correlate with a 263 ETS DIFFSERV codepoint 264 2) Implement a separate set of E-LSPs for the ETS traffic uniquely 265 distinguished in DIFFSERV. 267 It is recognized that MPLS LSPs [MPLS] have very limited resources for 268 traffic differentiation, and the first (1) approach's allocating a 269 limited traffic differentiation resources for the nominally rare, but 270 occasionally heavy ETS traffic may be viewed as wasteful. However, the 271 alternative approach (2) of creating a separate ETS topology of LSPs 272 presents significant difficulties because of the ubiquitous requirement 273 for ETS support coupled with its rare use, leading to significant 274 maintenance and operating challenges. Thus approach (2) seems to 275 contravene REQ-3, which cautions that the impact of ETS on network 276 management and administration should be minimized. Complying with REQ- 277 3 implies that the ETS service should not be dependant on the 278 maintenance and management of a distinct "shadow network" or VPN. 280 Both candidate approaches have advantages and disadvantages. Approach 281 (1) satisfies REQ-3, but exposes a gap in that there is no MPLS 282 codepoint identified for the additional ETS DIFFSERV codepoint 283 distinguishing ETS packets within an MPLS path also supporting non-ETS 284 packets. 286 7.0 Security Considerations 288 There are two primary concerns: 290 - Authorization/authentication of voice traffic which is entitled to 291 ETS-treatment. In the reference IP Bridging topology, this 292 authentication and authorization takes place in the CSN. The 293 security of this authorization and authentication in the IP 294 network is a general IP Telephony security issue, and outside the 295 scope of his paper. 296 - Potential for unauthorized use of ETS, and for DoS or DDoS 297 attacks. This document recognizes these issues, but does not 298 address them because they are out of scope for a gap analysis. 300 8.0 IANA Considerations 302 There are no IANA considerations addressed in this document. The 303 alleviation of some of the gaps identified may involve IANA 304 considerations. 306 9.0 Conclusion 308 From the perspective of the reference network topology and service 309 there appear to be gaps in both DIFFSERV and MPLS. In their current 310 form they cannot provide an increased probability that ETS calls will 311 receive a satisfactory (i.e., non-degraded) quality of service in a 312 stressed network environment while meeting REQ-1, REQ-2, REQ-3 and 313 REQ-4. 315 10.0 Acknowledgements 317 The authors would like to acknowledge the helpful comments, opinions, 318 and clarifications of Richard Kaczmarek, as well as those comments 319 received from the IEPREP mailing list. 321 11.0 References 323 Normative 325 [DIFFSERV] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 326 of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 327 Headers", RFC 2474, December 1998. 329 [DIFFSERV EF] Davie, B., Charny, A., Bennett, J.C.R., K. Benson, Le 330 Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., Stiliadis, D., "An 331 Expedited Forwarding PHB (Per-Hop Behavior)" RFC 3246, March 2002 333 [IEPREP Term] Polk, J., "Internet Emergency Preparedness (IEPREP) 334 Telephony Topology Terminology", RFC 3523, April 2003. 336 [MPLS] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label 337 Switching Architecture", RFC 3031, January 2001. 339 [MPLS DIFF] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 340 P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label 341 Switching (MPLS) Support of Differentiated Services", RFC 3270, May 342 2002. 344 Non-Normative 346 [IEPREP Frame] Carlberg, K., Brown, I., Beard, C., "Framework for 347 Supporting ETS in IP Telephony",draft-ietf-ieprep-framework-07.txt , Internet-Draft, 348 December, 2003 . 350 [IEPREP Rqmts] Carlberg, K., Atkinson, R., "General Requirements for 351 Emergency Telecommunications Service", draft-ietf-ieprep-ets-general-04.txt, Internet- 352 Draft, August, 2003. 354 [IEPREP IP Tel Rqmts] Carlberg, K., Atkinson, R., "IP Telephony 355 Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-telephony-07.txt, Internet Draft, November, 2003. 357 12.0 Author Information 359 Pat McGregor 360 Nyquetek Inc 361 8397 Piping Rock 362 Millersville, MD 21108 U.S.A. 363 Email: pat_mcgregor@msn.com 364 Phone: 410-703-4486 366 Dennis Berg 367 CSC 368 15000 Conference Center Dr 369 Chantilly, VA 370 Email: Dberg3@CSC.com 371 Phone: 703-818-4608 373 Janet Gunn 374 CSC 375 15000 Conference Center Dr 376 Chantilly, VA 377 Email: JGunn6@CSC.com 378 Phone: 703-818-4725 380 13.0 Acronyms 382 The following acronyms are exploded for clarity: 384 AT = Access Tandem 386 CSN = Circuit Switched Network 388 EF = Expedited Forwarding 390 E-LSP = EXP-inferred-PSC LSPs 392 ETS = Emergency Telecommunications Service 394 EXP = field in MPLS label 396 LSP = Label Switched Path 398 LSR = Label Switching Router 400 MG = Media Gateway 402 MGC = Media Gateway Controller 404 MPLS = Multi-Protocol Label Switching 406 PHB = Per Hop Behavior 408 PSC = PHB Scheduling Class 410 SG = Signaling Gateway 412 STP = Signal Transfer Point 414 TDM = Time Division Multiplexing 416 "Copyright (C) The Internet Society (December 19, 2003). All Rights 417 Reserved. 419 This document and translations of it may be copied and furnished to 420 others, and derivative works that comment on or otherwise explain it or 421 assist in its implementation may be prepared, copied, published and 422 distributed, in whole or in part, without restriction of any kind, 423 provided that the above copyright notice and this paragraph are 424 included on all such copies and derivative works. However, this 425 document itself may not be modified in any way, such as by removing the 426 copyright notice or references to the Internet Society or other 427 Internet organizations, except as needed for the purpose of developing 428 Internet standards in which case the procedures for copyrights defined 429 in the Internet Standards process must be followed, or as required to 430 translate it into languages other than English. 432 The limited permissions granted above are perpetual and will not be 433 revoked by the Internet Society or its successors or assigns. 435 This document and the information contained herein is provided on an 436 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 437 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 438 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 439 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 440 FITNESS FOR A PARTICULAR PURPOSE." 442 The Expiration date for this Internet Draft is: 444 April 19, 2004