idnits 2.17.1 draft-ietf-ieprep-framework-04.txt: -(1025): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1116): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1124): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 6 instances of lines with non-ascii characters in the document. == 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 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 1214: '... requiredClass NULL OPTIONAL...' RFC 2119 keyword, line 1215: '... SEQUENCE OF ClearToken OPTIONAL...' RFC 2119 keyword, line 1216: '... SEQUENCE OF CryptoH323Token OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 15 looks like a reference -- Missing reference section? '2' on line 87 looks like a reference -- Missing reference section? '3' on line 64 looks like a reference -- Missing reference section? '4' on line 66 looks like a reference -- Missing reference section? '5' on line 66 looks like a reference -- Missing reference section? '6' on line 76 looks like a reference -- Missing reference section? '7' on line 76 looks like a reference -- Missing reference section? '8' on line 84 looks like a reference -- Missing reference section? '9' on line 113 looks like a reference -- Missing reference section? '10' on line 435 looks like a reference -- Missing reference section? '11' on line 125 looks like a reference -- Missing reference section? '12' on line 125 looks like a reference -- Missing reference section? '30' on line 146 looks like a reference -- Missing reference section? '13' on line 163 looks like a reference -- Missing reference section? '18' on line 167 looks like a reference -- Missing reference section? '14' on line 494 looks like a reference -- Missing reference section? '31' on line 201 looks like a reference -- Missing reference section? '32' on line 206 looks like a reference -- Missing reference section? '38' on line 244 looks like a reference -- Missing reference section? '39' on line 264 looks like a reference -- Missing reference section? '40' on line 264 looks like a reference -- Missing reference section? '26' on line 319 looks like a reference -- Missing reference section? '15' on line 1187 looks like a reference -- Missing reference section? '19' on line 444 looks like a reference -- Missing reference section? '22' on line 446 looks like a reference -- Missing reference section? '24' on line 492 looks like a reference -- Missing reference section? '25' on line 492 looks like a reference -- Missing reference section? '16' on line 550 looks like a reference -- Missing reference section? '20' on line 676 looks like a reference -- Missing reference section? '29' on line 737 looks like a reference -- Missing reference section? '23' on line 757 looks like a reference -- Missing reference section? '17' on line 797 looks like a reference -- Missing reference section? '36' on line 890 looks like a reference -- Missing reference section? '33' on line 821 looks like a reference -- Missing reference section? '37' on line 984 looks like a reference -- Missing reference section? '35' on line 1182 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 38 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ken Carlberg 3 INTERNET DRAFT Ian Brown 4 March 2, 2003 UCL 5 Cory Beard 6 UMKC 8 Framework for Supporting ETS in IP Telephony 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document presents a framework for supporting authorized 35 emergency related communication within the context of IP telephony. 36 We present a series of objectives that reflect a general view of how 37 authorized emergency service, in line with the Emergency 38 Telecommunications Service (ETS), should be realized within today's 39 IP architecture and service models. From these objectives, we 40 present a corresponding set of protocols and capabilities, which 41 provide a more specific set of recommendations regarding existing 42 IETF protocols. Finally, we present two scenarios that act as 43 guiding models for the objectives and functions listed in this 44 document. These, models, coupled with an example of an existing 46 ^L 47 service in the PSTN, contribute to a constrained solution space. 49 1. Introduction 51 The Internet has become the primary target for worldwide communica- 52 tions. This is in terms of recreation, business, and various ima- 53 ginative reasons for information distribution. A constant fixture in 54 the evolution of the Internet has been the support of Best Effort as 55 the default service model. Best Effort, in general terms, infers 56 that the network will attempt to forward traffic to the destination 57 as best as it can with no guarantees being made, nor any resources 58 reserved, to support specific measures of Quality of Service (QoS). 59 An underlying goal is to be "fair" to all the traffic in terms of the 60 resources used to forward it to the destination. 62 In an attempt to go beyond best effort service, [2] presented an 63 overview of Integrated Services (int-serv) and its inclusion into the 64 Internet architecture. This was followed by [3], which specified the 65 RSVP signaling protocol used to convey QoS requirements. With the 66 addition of [4] and [5], specifying controlled load (bandwidth 67 bounds) and guaranteed service (bandwidth & delay bounds) respec- 68 tively, a design existed to achieve specific measures of QoS for an 69 end-to-end flow of traffic traversing an IP network. In this case, 70 our reference to a flow is one that is granular in definition and 71 applying to specific application sessions. 73 From a deployment perspective (as of the date of this document), 74 int-serv has been predominantly constrained to intra-domain paths, at 75 best resembling isolated "island" reservations for specific types of 76 traffic (e.g., audio and video) by stub domains. [6] and [7] will 77 probably contribute to additional deployment of int-serv to Internet 78 Service Providers (ISP) and possibly some inter-domain paths, but it 79 seems unlikely that the original vision of end-to-end int-serv 80 between hosts in source and destination stub domains will become a 81 reality in the near future (the mid- to far-term is a subject for 82 others to contemplate). 84 In 1998, the IETF produced [8], which presented an architecture for 85 Differentiated Services (diff-serv). This effort focused on a more 86 aggregated perspective and classification of packets than that of 87 [2]. This is accomplished with the recent specification of the 88 diff-serv field in the IP header (in the case of IPv4, it replaced 89 the old ToS field). This new field is used for code points esta- 90 blished by IANA, or set aside as experimental. It can be expected 92 ^L 93 nternet Draft IEPS Framework March 2, 2003 95 that sets of microflows, a granular identification of a set of pack- 96 ets, will correspond to a given code point, thereby achieving an 97 aggregated treatment of data. 99 One constant in the introduction of new service models has been the 100 designation of Best Effort as the default service model. If traffic 101 is not, or cannot be, associated as diff-serv or int-serv, then it is 102 treated as Best Effort and uses what resources are made available to 103 it. 105 Beyond the introduction of new services, the continued pace of addi- 106 tional traffic load experienced by ISPs over the years has continued 107 to place a high importance for intra-domain traffic engineering. The 108 explosion of IETF contributions, in the form of drafts and RFCs pro- 109 duced in the area of Multi Protocol Label Switching (MPLS), exempli- 110 fies the interest in versatile and manageable mechanisms for intra- 111 domain traffic engineering. One interesting observation is the work 112 involved in supporting QoS related traffic engineering. Specifically, 113 we refer to MPLS support of differentiated services [9], and the on- 114 going work in the inclusion of fast bandwidth recovery of routing 115 failures for MPLS [10]. 117 1.1. Emergency Related Data 119 The evolution of the IP service model architecture has traditionally 120 centered on the type of application protocols used over a network. 121 By this we mean that the distinction, and possible bounds on QoS, 122 usually centers on the type of application (e.g., audio video tools) 123 that is being referred to. 125 While protocols like SMTP [11] and SIP [12] have embedded fields 126 denoting "priority", there has not been a previous IETF standards 127 based effort to state or define what this distinction means with 128 respect to the underlying network or the end-to-end applications and 129 how it should be supported at any layer. Given the emergence of IP 130 telephony, a natural inclusion of it as part of a telephony carrier's 131 backbone network, or into the Internet as a whole, implies the abil- 132 ity to support existing emergency related services. Typically, one 133 associates emergency calls with "911" telephone service in the U.S., 134 or "999" in the U.K. -- both of which are attributed to national 135 boundaries and accessible by the general public. Outside of this 136 exists emergency telephone services that involved authorized usage, 137 as described in the following subsection. 139 ^L 141 1.1.1. Government Emergency Telecommunications Service (GETS) 143 GETS is an emergency telecommunications service available in the U.S. 144 and overseen by the National Communications System (NCS) -- an office 146 established by the White House under an executive order [30] and now 147 a part of the Department of Homeland Security . Unlike "911", it is 148 only accessible by authorized individuals. The majority of these 149 individuals are from various government agencies like the Department 150 of Transportation, NASA, the Department of Defense, and the Federal 151 Emergency Management Agency (to name but a few). In addition, a 152 select set of individuals from private industry (telecommunications 153 companies, utilities, etc.) that are involved in criticial infras- 154 tructure recovery operations are also provided access to GETS. 156 The purpose of GETS is to increase the probability that phone service 157 will be available to selected authorized personnel in times of emer- 158 gencies, such as hurricanes, earthquakes, and other disasters that 159 may produce a burden in the form of call blocking (i.e., congestion) 160 on the U.S. Public Switched Telephone Network by the general public. 162 GETS is based in part on the ANSI T1.631 standard, specifying a High 163 Probability of Completion (HPC) for SS7 signaling [13]. 165 1.1.2. International Emergency Preparedness Scheme (IEPS) 167 [18] is a recent ITU standard that describes emergency related com- 168 munications over international telephone service. While systems like 169 GETS are national in scope, IEPS acts as an extension to local or 170 national authorized emergency call establishment and provides a 171 building block for a global service. 173 As in the case of GETS, IEPS promotes mechanisms like extended queu- 174 ing, alternate routing, and exemption from restrictive management 175 controls in order to increase the probability that international 176 emergency calls will be established. The specifics of how this is to 177 be accomplished are to be defined in future ITU document(s). 179 1.2. Scope of this Document 181 The scope of this document centers on the near and mid-term support 182 of ETS within the context of IP telephony, though not necessarily 183 Voice over IP. We make a distinction between these two by treating 184 IP telephony as a subset of VoIP, where in the former case we assume 185 some form of application layer signaling is used to explicitly 187 ^L 188 establish and maintain voice data traffic. This explicit signaling 189 capability provides the hooks from which VoIP traffic can be bridged 190 to the PSTN. 192 An example of this distinction is when the Robust Audio Tool (RAT) 193 [14] begins sending VoIP packets to a unicast (or multicast) destina- 194 tion. RAT does not use explicit signaling like SIP to establish an 195 end-to-end call between two users. It simply sends data packets to 196 the target destination. On the other hand, "SIP phones" are host 197 devices that use a signaling protocol to establish a call signal 198 before sending data towards the destination. 200 One other aspect we should probably assume exists with IP Telephony 201 is an association of a target level of QoS per session or flow. [31] 202 makes an argument that there is a maximum packet loss and delay for 203 VoIP traffic, and both are interdependent. For delays of ~200ms, a 204 corresponding drop rate of 5% is deemed acceptable. When delay is 205 lower, a 15-20% drop rate can be experienced and still considered 206 acceptable. [32] discusses the same topic and makes an arguement 207 that packet size plays a significant role in what users tolerate as 208 "intelligible" VoIP. The larger the packet, correlating to longer 209 sampling rate, the lower the acceptable rate of loss. 211 Regardless of a definitive drop rate, it would seem that interactive 212 voice has a lower threshold of loss than elastic applications such as 213 email or web browsers. This places a higher burden on the problem 214 space of supporting VoIP over the Internet. This problem is further 215 compounded when toll-quality service is expected because it assumes a 216 default service model that is better than best effort. This in turn 217 can increase the probability that a form of call-blocking can occur 218 with VoIP or IP telephony traffic. 220 Beyond this, part of our motivation in writing this document is to 221 provide a framework for ISPs and telephony carriers so that they have 222 an understanding of objectives used to support ETS related IP 223 telephony traffic. In addition, we also wish to provide a reference 224 point for potential customers in order to constrain their expecta- 225 tions. In particular, we wish to avoid any temptation of trying to 226 replicate the exact capabilities of existing emergency voice service 227 currently available in the PSTN to that of IP and the Internet. If 228 nothing else, intrinsic differences between the two communications 229 architectures precludes this from happening. Note, this does not 230 prevent us from borrowing design concepts or objectives from existing 231 systems. 233 Section 2 presents several primary objectives that articulate what is 234 considered important in supporting ETS related IP telephony traffic. 235 These objectives represent a generic set of goals and desired 237 ^L 238 capabilities. Section 3 presents additional value added objectives, 239 which are viewed as useful, but not critical. Section 4 presents 240 protocols and capabilities that relate or can play a role in support 241 of the objectives articulated in section 2. Finally, Section 5 242 presents two scenarios that currently exist or are being deployed in 243 the near term over IP networks. These are not all-inclusive 244 scenarios, nor are they the only ones that can be articulated ([38] 245 provides a more extensive discussion on the topology scenarios 246 related to IP telephony). However, these scenarios do show cases 247 where some of the protocols discussed in section 4 apply, and where 248 some do not. 250 Finally, we need to state that this document focuses its attention on 251 the IP layer and above. Specific operational procedures pertaining 252 to Network Operation Centers (NOC) or Network Information Centers 253 (NIC) are outside the scope of this document. This includes the 254 "bits" below IP, other specific technologies, and service level 255 agreements between ISPs and telephony carriers with regard to dedi- 256 cated links. 258 2. Objective 260 The support of ETS within IP telephony can be realized in the form of 261 several primary objectives. From this set, we present protocols and 262 capabilities (presented below in section 3) to be considered by 263 clients and providers of ETS type services. This document uses the 264 IEPREP requirements of [39, 40] as a guide in specifying the objec- 265 tives listed in this section. 267 There are two underlying goals in the selection of these objectives. 268 One goal is to produce a design that maximizes the use of existing IP 269 protocols and minimizes the set of additional specifications needed 270 to support IP-telephony based ETS. Thus, with the inclusion of these 271 minimal augmentations, the bulk of the work in achieving ETS over an 272 IP network that is connected or unconnected to the Internet involves 273 operational issues. Examples of this would be the establishment of 274 Service Level Agreements (SLA) with ISPs, and/or the provisioning of 275 traffic engineered paths for ETS-related telephony traffic. 277 A second underlying goal in selecting the following objectives is to 278 take into account experiences from an existing emergency-type commun- 279 ication system (as described in section 1.1) as well as the existing 280 restrictions and constraints placed by some countries. In the former 281 case, we do not attempt to mimic the system, but rather extract 282 information as a reference model. With respect to constraints based 283 on laws or agency regulations, this would normally be considered 285 ^L 286 outside of the scope of any IETF document. However, these con- 287 straints act as a means of determining the lowest common denominator 288 in specifying technical functional requirements. If such constraints 289 do not exist, then additional capabilities can be added to the base- 290 line set. This last item will be expanded upon in the description of 291 Objective #3 below. 293 The primary Objectives in support of authorized emergency calls: 295 1) High Probability of Call Completion 296 2) No loss of information when interacting with PSTN signaling 297 3) Distinction of ETS data traffic 298 4) Non-preemptive action 299 5) Non-ubiquitous support 300 6) Authenticated service 302 The first objective is the crux of our work because it defines our 303 expectations for both data and call signaling for IP telephony. As 304 stated, our objective is achieving a high probability that emergency 305 related calls (both data and signaling packets) will be forwarded 306 through an IP network. Specifically, we envision the relevance of 307 this objective during times of congestion, the context of which we 308 describe further below in this section. The critical word in this 309 objective is "probability", as opposed to assurance or guarantee -- 310 the latter two placing a higher burden on the network. Objectives 4 311 and 5 listed above help us to qualify the term probability in the 312 context of other objectives. 314 The second objective involves the interaction of IP telephony signal- 315 ing with existing PSTN support for emergency related voice communica- 316 tions. As mentioned above in Section 1.2, standard T1.631 [26] speci- 317 fies emergency code points for SS7. Specifically, the National Secu- 318 rity and Emergency Preparedness (NS/EP) Calling Party Category code 319 point is defined for ISUP IAM messages used by SS7 [26]. Hence, when 320 IP providers choose to interconnect with the PSTN, it is our objec- 321 tive that this interaction between the PSTN and IP telephony with 322 respect to ETS (and national indicators) is a semantically straight- 323 forward, reversible mapping of comparable code points. 325 The third objective focuses on the ability to distinguish ETS data 326 packets from other types of VoIP packets. With such an ability, 327 transit providers can more easily ensure that pre-existing service 328 level agreements relating to ETS are adhered to. Note that we do not 329 assume that the actions taken to distinguish ETS type packets are 330 easy. Nor, in this section, do we state the form of this distinc- 331 tion. We simply present the objective of identifying flows that 332 relate to IEPS versus others that traverse a transit network. 334 ^L 335 At an abstract level, the fourth objective pertains to the actions 336 taken when an IP telephony call, via a signaling protocol such as 337 SIP, cannot be forwarded because the network is experiencing a form 338 of congestion. We state this in general terms because of two rea- 339 sons: a) there may exist applications other than SIP, like H.248, 340 used for call establishment, and b) congestion may come in several 341 forms. For example, congestion may exist at the IP packet layer with 342 respect to queues being filled to their configured limit. Congestion 343 may also arise from resource allocation (i.e., QoS) attributed per 344 call or aggregated sets of calls. In this latter case, while there 345 may exist resources to forward the packets, a stateful signaling 346 server may have reached its configured limit as to how many telephony 347 calls it will support while retaining toll-quality service per call. 348 Typically, one terms this form of congestion as call blocking. Note 349 that we do not address the case when congestion occurs at the bit 350 level below that of IP, due to the position that it is outside the 351 scope of IP and the IETF. 353 So, given the existence of congestion in its various forms, our 354 objective is to support ETS-related IP telephony call signaling and 355 data traffic via non-preemptive actions taken by the network. More 356 specifically, we associate this objective in the context of IP 357 telephony acting as part of the Public Telephone Network (PTN). 358 This, as opposed to the use of IP telephony within a private or stub 359 network. In section 5 below, we expand on this through the descrip- 360 tion of two distinct scenarios of IP telephony and its operation with 361 IEPS and the PSTN. 363 It is important to mention that the fourth objective is a default 364 position influenced by existing laws & regulations of some countries. 365 Those countries, regions, or private networks not bound by these res- 366 trictions can remove this objective and make provisions to enforce 367 preemptive action. In this case, it would probably be advantageous 368 to deploy a signaling system similar to that proposed in [15], 369 wherein multiple levels of priority are defined and preemption via 370 admission control from SIP servers is enforced. 372 The fifth objective stipulates that we do not advocate the need or 373 expectation for ubiquitous support of ETS across all administrative 374 domains of the Internet. While it would be desirable to have ubiqui- 375 tous support, we feel the reliance of such a requirement would doom 376 even the contemplation of supporting ETS by the IETF and the expected 377 entities (e.g., ISPs and vendors) involved in its deployment. 379 We use the existing GETS service in the U.S. as an existing example 380 in which emergency related communications does not need to be ubiqui- 381 tous. As mentioned previously, the measure and amount of support 382 provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs 384 ^L 385 nor LECs. Given the fact that GETS still works within this context, 386 it is our objective to follow this deployment model such that we can 387 accomplish the first objective listed above -- a higher probability 388 of call completion than that of normal IP telephony call traffic. 390 Our final objective is that only authorized users may use the ser- 391 vices outlined in this framework. GETS users are authenticated using 392 a PIN provided to the telephony carrier, which signals authentication 393 to subsequent networks via the HPC class mark. In an IP network, the 394 authentication center will need to securely signal back to the IP 395 ingress point that a given user is authorized to send ETS related 396 flows. Similarly, transit networks that chose to support ETS SLAs 397 must securely interchange authorized ETS traffic. In both cases, 398 IPSec authentication transforms may be used to protect this traffic. 399 This is entirely separate from end-to-end IPSec protection of user 400 traffic, which will be configured by users. IP-PSTN gateways must 401 also be able to securely signal ETS authorization for a given flow. 402 As these gateways are likely to act as SIP servers, we further con- 403 sider the use of SIP's security functions to aid this objective. 405 3. Value Added Objective 407 This objective is viewed as being helpful in achieving a high proba- 408 bility of call completion. Its realization within an IP network 409 would be in the form of new protocols or enhancements to existing 410 ones. Thus, objectives listed in this section are treated as value 411 added -- an expectation that their existence would be beneficial, and 412 yet not viewed as critical to support ETS related IP telephony 413 traffic. 415 3.1. Alternate Path Routing 417 This objective involves the ability to discover and use a different 418 path to route IP telephony traffic around congestion points and thus 419 avoid them. Ideally, the discovery process would be accomplished in 420 an expedient manner (possibly even a priori to the need of its 421 existence). At this level, we make no assumptions as to how the 422 alternate path is accomplished, or even at which layer it is achieved 423 -- e.g., the network versus the application layer. But this kind of 424 capability, at least in a minimal form, would help contribute to 425 increasing the probability of call completion of IEPS traffic by mak- 426 ing use of noncongested alternate paths. We use the term "minimal 427 form" to emphasize the fact that care must be taken in how the system 428 provides alternate paths so it does not significantly contribute to 429 the congestion that is to be avoided (e.g., via excess 430 control/discovery messages). 432 ^L 433 At the time that this document was written, we can identify two 434 work-in-progress areas in the IETF that can be helpful in providing 435 alternate paths for call signaling. The first is [10], which is 436 focused on network layer routing and describes a framework for 437 enhancements to the LDP specification of MPLS to help achieve fault 438 tolerance. This in itself does not provide alternate path routing, 439 but rather helps minimize loss in intradomain connectivity when MPLS 440 is used within a domain. 442 The second effort comes from the IP Telephony working group and 443 involves Telephony Routing over IP (TRIP). To date, a framework 444 document [19] has been published as an RFC which describes the 445 discovery and exchange of IP telephony gateway routing tables between 446 providers. The TRIP protocol [22] specifies application level 447 telephony routing regardless of the signaling protocol being used 448 (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises 449 reachability and attributes of destinations. In its current form, 450 several attributes have already been defined, such as LocalPreference 451 and MultiExitDisc. Additional attributes can be registered with 452 IANA. 454 3.2. End-to-End Fault Tolerance 456 This topic involves the work that has been done in trying to compen- 457 sate for lossy networks providing best effort service. In particu- 458 lar, we focus on the use of a) Forward Error Correction (FEC), and b) 459 redundant transmissions that can be used to compensate for lost data 460 packets. (Note that our aim is fault tolerance, as opposed to an 461 expectation of always achieving it). 463 In the former case, additional FEC data packets are constructed from 464 a set of original data packets and inserted into the end-to-end 465 stream. Depending on the algorithm used, these FEC packets can 466 reconstruct one or more of the original set that were lost by the 467 network. An example may be in the form of a 10:3 ratio, in which 10 468 original packets are used to generate three additional FEC packets. 469 Thus, if the network loses 30% or less number of packets, then the 470 FEC scheme will be able to compensate for that loss. The drawback to 471 this approach is that to compensate for the loss, a steady state 472 increase in offered load has been injected into the network. This 473 makes an arguement that the act of protection against loss has con- 474 tributed to additional pressures leading to congestion, which in turn 475 helps trigger packet loss. In addition, in using a ratio of 10:3, 476 the source (or some proxy) must "hold" all 10 packets in order to 477 construct the three FEC packets. This contributes to the end-to-end 478 delay of the packets as well as minor bursts of load in addition to 480 ^L 481 changes in jitter. 483 The other form of fault tolerance we discuss involves the use of 484 redundant transmissions. By this we mean the case in which an origi- 485 nal data packet is followed by one or more redundant packets. At 486 first glance, this would appear to be even less friendly to the net- 487 work than that of adding FEC packets. However, the encodings of the 488 redundant packets can be of a different type (or even transcoded into 489 a lower quality) that produce redundant data packets that are signi- 490 ficantly smaller than the original packet. 492 Two RFCs [24, 25] have been produced that define RTP payloads for FEC 493 and redundant audio data. An implementation example of a redundant 494 audio application can be found in [14]. We note that both FEC and 495 redundant transmissions can be viewed as rather specific and to a 496 degree tangential solutions regarding packet loss and emergency com- 497 munications. Hence, these topics are placed under the category of 498 value added objectives. 500 4. Protocols and Capabilities 502 In this section, we take the objectives presented above and present a 503 set of protocols and capabilities that can be used to achieve them. 504 Given that the objectives are predominantly atomic in nature, the 505 measures used to address them are to be viewed separately with no 506 specific dependency upon each other as a whole. Various protocols 507 and capabilities may be complimentary to each other, but there is no 508 need for all to exist given different scenarios of operation, and 509 that ETS support is not viewed as a ubiquitously available service. 510 We divide this section into 4 areas: 512 1) Signaling 513 2) Policy 514 3) Traffic Engineering 515 4) Security 517 4.1. Signaling & State Information 519 Signaling is used to convey various information to either intermedi- 520 ate nodes or end nodes. It can be out-of-band of a data flow, and 521 thus in a separate flow of its own, such as SIP messages. It can be 522 in-band and part of the state information in a datagram containing 523 the voice data. This latter example could be realized in the form of 524 diff-serv code points in the IP packet. 526 ^L 527 In the following subsections, we discuss potential augmentations to 528 different types of signaling and state information to help support 529 the distinction of emergency related communications in general, and 530 IEPS specifically. 532 4.1.1. SIP 534 With respect to application level signaling for IP telephony, we 535 focus our attention to the Session Initiation Protocol (SIP). 536 Currently, SIP has an existing "priority" field in the Request- 537 Header-Field that distinguishes different types of sessions. The 538 five currently defined values are: "emergency", "urgent", "normal", 539 "non-urgent", "other-priority". These values are meant to convey 540 importance to the end-user and have no additional sematics associated 541 with them. 543 [15] is a (soon to be) RFC that defines the requirements for a new 544 header field for SIP in reference to resource priority. This new 545 header field is meant to provide an additional measure of distinction 546 that can influence the behavior of gateways and SIP proxies. 548 4.1.2. Diff-Serv 550 In accordance with [16], the differentiated services code point 551 (DSCP) field is divided into three sets of values. The first set is 552 assigned by IANA. Within this set, there are currently, three types 553 of Per Hop Behaviors that have been specified: Default (correlating 554 to best effort forwarding), Assured Forwarding, and Expedited For- 555 warding. The second set of DSCP values are set aside for local or 556 experimental use. The third set of DSCP values are also set aside 557 for local or experimental use, but may later be reassigned to IANA in 558 case the first set has been completely assigned. 560 One candidate approach to consider involves the specification of a 561 new type of Per-Hop Behavior (PHB). This would provide a specific 562 means of distinguishing emergency related traffic (signaling and user 563 data) from other traffic. The existence of this PHB then provides a 564 baseline by which specific code points may be defined related to 565 various emergency related traffic: authorized emergency sessions 566 (e.g., ETS), general public emergency calls (e.g., "911"), MLPP. 567 Aggregates would still exist with respect to the bundling of applica- 568 tions per code point. Further, one would associate a forwarding 569 paradigm aimed at a low loss rate reflective of the code point 570 selected. The new PHB could be in the form of a one or more code 571 points that duplicate EF-type traffic characteristics. Policies 572 would determine IF a measure of importance exists per EF-type code- 574 ^L 575 point. 577 A potential issue that could be addressed by a new PHB involves merge 578 points of flows within a diff-serv domain. With EF, one can expect 579 admission control being performed at the edges of the domain. 580 Presumably, careful traffic engineering would be applied to avoid 581 congestion of EF queues at internal/core merge points stemming from 582 flows originating from different ingress nodes of the diff-serv 583 domain. However, traffic engineering may not be able to compensate 584 for congestion of EF-type traffic at the domain's core routers. 585 Hence, a new PHB that has more than one code point to identify EF- 586 type traffic may address congestion by associating a drop precedence 587 for certain types of EF-type datagrams. Note that local policy and 588 SLAs would define which EF-type of traffic, if any, would be associ- 589 ated with a specific drop precedence. 591 4.1.3. Variations Related to Diff-Serv and Queuing 593 One variation to consider with respect to existing diff-serv work 594 would be to define a new or fifth class for the existing AF PHB. 595 Unlike the other currently defined classes, this new one would be 596 based on five levels of drop precedence. This increase in the number 597 of levels would conveniently correlate to the levels of MLPP, which 598 has five types of priorities. The five levels would also correlate 599 to a recent effort in the Study Group 11 of the ITU to define 5 lev- 600 els for Emergency Telecommunications Service (ETS). Beyond these 601 other standardization efforts, the 5 levels would provide a higher 602 level of variance that could be used to supercede the existing 3 lev- 603 els used in the other classes. Hence, if other non-emergency aggre- 604 gate traffic were assigned to the new class, the highest drop pre- 605 cedence they are assigned to is (3) -- corresponding to the other 606 four currently defined classes. Emergency traffic would be set to 607 (4) or (5), depending on the SLA that has been defined. 609 Another variation to Another approach would be to make modifications 610 or additions to the existing AF PHB's, with their four classes and 611 three drop precedences per class. One could use the existing AF 612 PHB's if one assumed that a relatively homogeneous set of packet 613 flows were marked with the same AF class markings (i.e., have only 614 TCP flows, or only UDP-voice flows, but not both, within a class). 615 Then one could allocate the lowest drop precedence to the emergency 616 traffic, and the other two drop precedences to the rest of the 617 traffic. 619 One original rationale for having three drop precedences was to be 620 able to separate TCP flows from UDP flows by different drop pre- 621 cedences, so UDP packets could be dropped more frequently than TCP 623 ^L 624 packets. TCP flows would reduce their sending rates while UDP likely 625 would not, so this could be used to prevent UDP from bullying the TCP 626 traffic. But if the design does not create a mixing of TCP and UDP, 627 then three drop precedences are not as necessary and one could be 628 used for emergency traffic. 630 To implement preferential dropping between classes of traffic, with 631 one being emergency traffic, one would need to use a more advanced 632 form of Active Queue Management (AQM). AQM would need to protect 633 emergency traffic as much as possible until most, if not all, of the 634 non-emergency traffic had been dropped. This would require creation 635 of drop probabilities based on counting the number of packets in the 636 queue for each drop precedence individually. Instead, current imple- 637 mentations use an overall queue fill measurement to make decisions; 638 this might cause emergency packets to be dropped. This new from of 639 AQM would be a Multiple Average-Multiple Threshold approach, instead 640 of the Single Average-Multiple Threshold approach used today. 642 So, it could be possible to use the current set of AF PHB's if each 643 class where reasonably homogenous in the traffic mix. But one might 644 still have a need to be able to differentiate three drop precedences 645 just within non-emergency traffic. If so, more drop precedences 646 could be implemented. Also, if one wanted discrimination within 647 emergency traffic, as with MLPP's five levels of precedence, more 648 drop precedences might also be considered. The five levels would 649 also correlate to a recent effort in the Study Group 11 of the ITU to 650 define 5 levels for Emergency Telecommunications Service. 652 The other question with AF PHB's would be whether one should create a 653 new fifth class. This might be a useful approach, but, given the 654 above discussion, a fifth class would only be needed if emergency 655 traffic were considered a totally different type of traffic from a 656 QoS perspective. Scheduling mechanisms like Weighted Fair Queueing 657 and Class Based Queueing are used to designate a percentage of the 658 output link bandwidth that would be used for each class if all queues 659 were backlogged. Its purpose, therefore, it to manage the rates and 660 delays experienced by each class. But emergency traffic does not 661 necessarily require QoS any better or different than non-emergency 662 traffic. It just needs higher probability of completion which could 663 be accomplished simply through drop precedences within a class. 664 Emergency requirements are primarily related to preferential packet 665 dropping probabilities. 667 It is important to note that as of the time that this document was 668 written, the IETF is taking a conservative approach in specifying new 669 PHBs. This is because the number of code points that can be defined 670 is relatively small, and understandably considered a scarce resource. 672 ^L 673 Therefore, the possibility of a new PHB being defined for emergency 674 related traffic is at best a long term project that may or may not be 675 accepted by the IETF. In the near term, we would initially recommend 676 using the Assured Forwarding (AF) PHB [20] for distinguishing emer- 677 gency traffic from other types of flows. At a minimum, AF could be 678 used for the different SIP call signaling messages. If EF was also 679 supported by the domain, then it would be used for IP telephony data 680 packets. Otherwise, another AF class would be used for those data 681 flows. 683 It is critical to understand that one cannot specify an exact code 684 point used for emergency related data flows because the relevance of 685 a code point is local to the given diff-serv domain (i.e., they are 686 not globally unique per micro-flow or aggregate of flows). In addi- 687 tion, we can expect that the existence of a codepoint for emergency 688 related flows is based on the service level agreements established 689 with a given diff-serv domain. 691 4.1.4. RTP 693 The Real-Time Transport Protocol (RTP) provides end-to-end delivery 694 services for data with real-time characteristics. The type of data 695 is generally in the form of audio or video type applications, and are 696 frequently interactive in nature. RTP is typically run over UDP and 697 has been designed with a fixed header that identifies a specific type 698 of payload representing a specific form of application media. The 699 designers of RTP also assumed an underlying network providing best 700 effort service. As such, RTP does not provide any mechanism to 701 ensure timely delivery or provide other QoS guarantees. However, the 702 emergence of applications like IP telephony, as well as new service 703 models, presents new environments where RTP traffic may be forwarded 704 over networks that support better than best effort service. Hence, 705 the original scope and target environment for RTP has expanded to 706 include networks providing services other than best effort. 708 In 4.1.2, we discussed one means of marking a data packet for emer- 709 gencies under the context of the diff-serv architecture. However, we 710 also pointed out that diff-serv markings for specific PHBs are not 711 globally unique, and may be arbitrarily removed or even changed by 712 intermediary nodes or domains. Hence, with respect to emergency 713 related data packets, we are still missing an in-band marking in a 714 data packet that stays constant on an end-to-end basis. 716 There are three choices in defining a persistent marking of data 717 packets and thus avoid the transitory marking of diff-serv code 718 points. One can propose a new PHB dedicated for emergency type 719 traffic as discussed in 4.1.2. One can propose a specification of a 721 ^L 722 new shim layer protocol at some location above IP. Or, one can add a 723 new specification to an existing application layer protocol. The 724 first two cases are probably the "cleanest" architecturally, but they 725 are long term efforts that may not come to pass because of a limited 726 amount of diff-serv code points and the contention that yet another 727 shim layer will make the IP stack too large. The third case, placing 728 a marking in an application layer packet, also has drawbacks; the key 729 weakness being the specification of a marking on a per-application 730 basis. 732 Discussions have been held in the Audio/Visual Transport (AVT) work- 733 ing group of augmenting RTP so that it can carry a marking that dis- 734 tinguishes emergency-related traffic from that which is not. Specif- 735 ically, these discussions centered on defining a new extention that 736 contains a "classifier" field indicating the condition associated 737 with the packet (e.g., authorized-emergency, emergency, normal) [29]. 738 The rationale behind this idea was that focusing on RTP would allow 739 one to rely on a point of aggregation that would apply to all pay- 740 loads that it encapsulates. However, the AVT group has expressed a 741 rough consensus that placing additional classifier state in the RTP 742 header to denote the importance of one flow over another is not an 743 approach that they wish to advance. Objections ranging from relying 744 on SIP to convey importance of a flow, as well as the possibility of 745 adversely affecting header compression, were expressed. There was 746 also the general feeling that the extension header for RTP that acts 747 as a signal should not be used. 749 4.1.5. MEGACO/H.248 751 The Media Gateway Control protocol (MEGACO) [23] defines the interac- 752 tion between a media gateway and a media gateway controller. [23] is 753 viewed as common text with ITU-T Recommendation H.248 and is a result 754 of applying the changes of RFC 2886 (Megaco Errata) to the text of 755 RFC 2885 (Megaco Protocol version 0.8). 757 In [23], the protocol specifies a Priority and Emergency field for a 758 context attribute and descriptor. The Emergency is an optional 759 boolean (True or False) condition. The Priority value, which ranges 760 from 0 through 15, specifies the precedence handling for a context. 762 The protocol does not specify individual values for priority. We 763 also do not recommend the definition of a well known value for the 764 MEGAGO priority. Any values set should be a function of any SLAs 766 ^L 767 that have been established regarding the handling of emergency 768 traffic. In addition, given that priority values denote precedence 769 (according to the Megaco protocol), then by default the ETS telephony 770 data flows should probably receive the same priority as other non- 771 emergency calls. This approach follows the objective of not relying 772 on preemption as the default treatment of emergency-related. 774 4.2. Policy 776 One of the objectives listed in section 3 above is to treat ETS- sig- 777 naling, and related data traffic, as non-preemptive in nature. 778 Further, that this treatment is to be the default mode of operation 779 or service. This is in recognition that existing regulations or laws 780 of certain countries governing the establishment of SLAs may not 781 allow preemptive actions (e.g., dropping existing telephony flows). 782 On the other hand, the laws and regulations of other countries 783 influencing the specification of SLA(s) may allow preemption, or even 784 require its existence. Given this disparity, we rely on local policy 785 to determine the degree by which emergency related traffic affects 786 existing traffic load of a given network or ISP. Important note: we 787 reiterate our earlier comment that laws and regulations are generally 788 outside the scope of the IETF and its specification of designs and 789 protocols. However, these constraints can be used as a guide in pro- 790 ducing a baseline capability to be supported; in our case, a default 791 policy for non-preemptive call establishment of ETS signaling and 792 data. 794 Policy can be in the form of static information embedded in various 795 components (e.g., SIP servers or bandwidth brokers), or it can be 796 realized and supported via COPS with respect to allocation of a 797 domain's resources [17]. There is no requirement as to how policy is 798 accomplished. Instead, if a domain follows actions outside of the 799 default non-preemptive action of ETS related communication, then we 800 stipulate that some type of policy mechanism is in place to satisfy 801 the local policies of an SLA established for ETS type traffic. 803 4.3. Traffic Engineering 805 In those cases where a network operates under the constraints of 806 SLAs, one or more of which pertains to ETS based traffic, it can be 807 expected that some form of traffic engineering is applied to the 808 operation of the network. We make no recommendations as to which 809 type of traffic engineering mechanism is used, but that such a system 810 exists in some form and can distinguish and support ETS signaling 811 and/or data traffic. We recommend a review of [36] by clients and 812 prospective providers of ETS service, which gives an overview and a 814 ^L 815 set of principles of Internet traffic engineering. 817 MPLS is generally the first protocol that comes to mind when the sub- 818 ject of traffic engineering is brought up. This notion is heightened 819 concerning the subject of IP telephony because of MPLS's ability to 820 permit a quasi-circuit switching capability to be superimposed on the 821 current Internet routing model [33]. 823 However, having cited MPLS, we need to stress that it is an intra- 824 domain protocol, and so may or may not exist within a given ISP. 825 Other forms of traffic engineering, such as weighted OSPF, may be the 826 mechanism of choice by an ISP. 828 Note: As a point of reference, existing SLAs established by the NCS 829 for GETS service tend to focus on a maximum allocation of (e.g., 1%) 830 of calls allowed to be established through a given LEC using HPC. 831 Once this limit is reached, all other GETS calls experience the same 832 probability of call completion as the general public. It is 833 expected, and encouraged, that ETS related SLAs will have a limit 834 with respect to the amount of traffic distinguished as being emer- 835 gency related, and initiated by an authorized user. 837 4.4. Security 839 If ETS support moves from intra-domain PSTN and IP networks to 840 inter-domain end-to-end IP, authenticated service becomes more com- 841 plex to provide. Where an ETS call is carried from PSTN to PSTN via 842 one telephony carrier's backbone IP network, very little IP-specific 843 security support is required. The user authenticates themself as 844 usual to the network using a PIN. The gateway from the PSTN connec- 845 tion into the backbone IP network must be able to signal that the 846 flow has an ETS label. Conversely, the gateway back into the PSTN 847 must similarly signal the call's label. A secure link between the 848 gateways may be set up using IPSec or SIP security functionality. If 849 the endpoint is an IP device, the link may be set up securely from 850 the ingress gateway to the end device. 852 As flows traverse more than one IP network, domains whose peering 853 agreements include ETS support must have the means to securely signal 854 a given flow's ETS status. They may choose to use physical link secu- 855 rity and/or IPSec authentication, combined with traffic conditioning 856 measures to limit the amount of ETS traffic that may pass between the 857 two domains. The inter-domain agreement may require the originating 858 network to take responsibility for ensuring only authorized traffic 859 is marked with ETS priority; the downstream domain may still perform 860 redundant conditioning to prevent the propagation of theft and denial 861 of service attacks. Security may be provided between ingress and 863 ^L 864 egress gateways or IP endpoints using IPSec or SIP security func- 865 tions. 867 When a call originates from an IP device, the ingress network may 868 authorize IEPS traffic over that link as part of its user authentica- 869 tion procedures. These authentication procedures may occur at the 870 link or network layers, but are entirely at the discretion of the 871 ingress network. That network must decide how often it should update 872 its list of authorized ETS users based on the bounds it is prepared 873 to accept on traffic from recently-revoked users. 875 5. Key Scenarios 877 There are various scenarios in which IP telephony can be realized, 878 each of which can imply a unique set of functional requirements that 879 may include just a subset of those listed above. We acknowledge that 880 a scenario may exist whose functional requirements are not listed 881 above. Our intention is not to consider every possible scenario by 882 which support for emergency related IP telephony can be realized. 883 Rather, we narrow our scope using a single guideline; we assume there 884 is a signaling & data interaction between the PSTN and the IP network 885 with respect to supporting emergency-related telephony traffic. We 886 stress that this does not preclude an IP-only end-to-end model, but 887 rather the inclusion of the PSTN expands the problem space and 888 includes the current dominant form of voice communication. 890 Note: as stated in section 1.2, [36] provides a more extensive set of 891 scenarios in which IP telephony can be deployed. Our selected set 892 below is only meant to provide an couple of examples of how the pro- 893 tocols and capabilities presented in Section 3 can play a role. 895 Single IP Administrative Domain 896 ------------------------------- 898 This scenario is a direct reflection of the evolution of the PSTN. 899 Specifically, we refer to the case in which data networks have 900 emerged in various degrees as a backbone infrastructure connecting 901 PSTN switches at its edges. This represents a single isolated IP 902 administrative domain that has no directly adjacent IP domains con- 903 nected to it. We show an example of this scenario below in Figure 1. 904 In this example, we show two types of telephony carriers. One is the 905 legacy carrier, whose infrastructure retains the classic switching 906 architecture attributed to the PSTN. The other is the next genera- 907 tion carrier, which uses a data network (e.g., IP) as its core 908 infrastructure, and Signaling Gateways at its edges. These gateways 909 "speak" SS7 externally with peering carriers, and another protocol 911 ^L 912 (e.g., SIP) internally, which rides on top of the IP infrastructure. 914 Legacy Next Generation Next Generation 915 Carrier Carrier Carrier 916 ******* *************** ************** 917 * * * * ISUP * * 918 SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG 919 * * (SS7) * (SIP) * (SS7) * (SIP) * 920 ******* *************** ************** 922 SW - Telco Switch 923 SG - Signaling Gateway 925 Figure 1 927 The significant aspect of this scenario is that all the resources of 928 each IP "island" fall within a given administrative authority. 929 Hence, there is not a problem of retaining toll quality Grade of Ser- 930 vice as the voice traffic (data and signaling) exits the IP network 931 because of the existing SS7 provisioned service between telephony 932 carriers. Thus, the need for support of mechanisms like diff-serv, 933 and an expansion of the defined set of Per-Hop Behaviors is reduced 934 (if not eliminated) under this scenario. 936 Another function that has little or no importance within the closed 937 IP environment of Figure 1 is that of IP security. The fact that 938 each administrative domain peers with each other as part of the PSTN, 939 means that existing security, in the form of Personal Identification 940 Number (PIN) authentication (under the context of telephony infras- 941 tructure protection), is the default scope of security. We do not 942 claim that the reliance on a PIN based security system is highly 943 secure or even desirable. But, we use this system as a default 944 mechanism in order to avoid placing additional requirements on exist- 945 ing authorized emergency telephony systems. 947 Multiple IP Administrative Domains 948 ---------------------------------- 950 We view the scenario of multiple IP administrative domains as a 951 superset of the previous scenario. Specifically, we retain the 952 notion that the IP telephony system peers with the existing PSTN. In 953 addition, segments 955 (i.e., portions of the Internet) may exchange signaling with other IP 956 administrative domains via non-PSTN signaling protocols like SIP. 958 ^L 959 Legacy Next Generation Next Generation 960 Carrier Carrier Carrier 961 ******* *************** ************** 962 * * * * * * 963 SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG 964 * * (SS7) * (SIP) * (SIP) * (SIP) * 965 ******* *************** ************** 967 SW - Telco Switch 968 SG - Signaling Gateway 970 Figure 2 972 Given multiple IP domains, and the presumption that SLAs relating to 973 ETS traffic may exist between them, the need for something like 974 diff-serv grows with respect to being able to distinguish the emer- 975 gency related traffic from other types of traffic. In addition, IP 976 security becomes more important between domains in order to ensure 977 that the act of distinguishing ETS-type traffic is indeed valid for 978 the given source. 980 We conclude this section by mentioning a complimentary work in pro- 981 gress in providing ISUP transparency across SS7-SIP interworking 982 [37]. The objective of this effort is to access services in the SIP 983 network and yet maintain transparency of end-to-end PSTN services. 984 Not all services are mapped (as per the design goals of [37], so we 985 anticipate the need for an additional document to specify the mapping 986 between new SIP labels and existing PSTN code points like NS/EP and 987 MLPP. 989 6. Security Considerations 991 Information on this topic is presented in sections 2 and 4. 993 7. References 995 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 996 9, RFC 2026, October 1996. 998 2 Braden, R., et. al., "Integrated Services in the Internet 999 Architecture: An Overview", Informational, RFC 1633, June 1994. 1001 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 1003 ^L 1004 Version 1, Functional Specification", Proposed Standard, RFC 1005 2205, Sept. 1997. 1007 4 Shenker, S., et. al., "Specification of Guaranteed Quality of 1008 Service", Proposed Standard, RFC 2212, Sept 1997. 1010 5 Wroclawski, J., "Specification for Controlled-Load Network 1011 Service Element", Proposed Standard, RFC 2211, Sept 1997. 1013 6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 1014 Reservations", Proposed Standard, RFC 3175, September 2001. 1016 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 1017 Proposed Standard, RFC 2961, April, 2001. 1019 8 Blake, S., et. al., "An Architecture for Differentiated 1020 Service", Proposed Standard, RFC 2475, Dec. 1998. 1022 9 Faucheur, F., et. al., "MPLS Support of Differentiated Services", 1023 Standards Track, RFC 3270, May 2002. 1025 10 Sharma, V., Hellstrand, F., �Framework for MPLS-Based Recovery�, 1026 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 1027 August 1982. 1029 12 Handley, M., et. al., "SIP: Session Initiation Protocol", 1030 Proposed Standard, RFC 2543, March 1999. 1032 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 1033 Completion (HPC) Network Capability_, ANSI T1.631-1993, (R1999). 1035 14 Robust Audio Tool (RAT): 1036 http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 1038 15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for 1039 the Session Initiation Protocol", Internet Draft, Work In Pro- 1040 gress, 1041 December, 2001. 1043 16 Nichols, K., et. al.,"Definition of the Differentiated Services 1044 Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed 1045 Standard, RFC 2474, December 1998. 1047 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 1048 Proposed Standard, RFC 2748, Jan 2000. 1050 ^L 1052 18 ITU, "International Emergency Preparedness Scheme", ITU 1053 Recommendation, E.106, March 2000. 1055 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 1056 Over IP", Informational, RFC 2871, June 2000 1058 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 1059 Standard, RFC 2597, June 1999 1061 21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 1062 Recomendation, I.255.3, July, 1990. 1064 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", 1065 Standards Track, RFC 3219, January 2002. 1067 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 1068 Track, RFC 3015, November 2000 1070 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 1071 Standards Track, RFC 2198, September, 1997 1073 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 1074 Generic Forward Error Correction", Standards Track, RFC 2733, 1075 December, 1999. 1077 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 1078 2000. 1080 27 Brown, I., "Securing IEPS over IP", White Paper, 1081 http://iepscheme.net/docs/secure_IEPS.doc 1083 28 "Description of an International Emergency Preference 1084 Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002 1086 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 1087 Draft, Work In Progress, October 2001. 1089 30 National Communications System: http://www.ncs.gov 1091 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 1092 http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, 1093 IETF Presentation: IPPM-Voiceip, Aug, 1997 1095 32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 1096 Proceedings, INET'95, Aug, 1995. 1098 33 Awduche, D, et al, "Requirements for Traffic Engineering Over 1099 MPLS", Informational, RFC 2702, September, 1999. 1101 ^L 1103 34 Polk, J., "An Architecture for Multi-Level Precedence and 1104 Preemption over IP", Internet Draft, Work In Progress, 1105 November, 2001. 1107 35 "Service Class Designations for H.323 Calls", ITU 1108 Recommendation H.460.4, November, 2002 1110 36 Awduche, D., et. al., "Overview and Principles of Internet Traffic 1111 Engineering", Informational, RFC 3272, May 2002. 1113 37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and 1114 Architectures", work in progress, Internet-Draft, June, 2002. 1116 38 Polk, J., �IEPREP Topology Scenarios�, Work in Progress, Internet- 1117 Draft, December, 2002 1119 39 Carlberg, K., Atkinson, R., �General Requirements for Emergency 1120 Telecommunications Service�, Work in Progress, Internet-Draft, 1121 January, 2003 1123 40 Carlberg, K., Atkinson, R., �IP Telephony Requirements for 1124 Emergency Telecommunications Service�, Work In Progress, Internet- 1125 Draft, January, 2003 1127 8. Appendix A: Government Telephone Preference Scheme (GTPS) 1129 This framework document uses the T1.631 and ITU IEPS standard as a 1130 target model for defining a framework for supporting authorized emer- 1131 gency related communication within the context of IP telephony. We 1132 also use GETS as a helpful model to draw experience from. We take 1133 this position because of the various areas that must be considered; 1134 from the application layer to the (inter)network layer, in addition 1135 to policy, security (authorized access), and traffic engineering. 1137 The U.K. has a different type of authorized use of telephony services 1138 referred to as the Government Telephone Preference Scheme (GTPS). At 1139 present, GTPS only applies to a subset of the local loop lines of 1140 within the UK. The lines are divided into Categories 1, 2, and 3. 1141 The first two categories involve authorized personnel involved in 1142 emergencies such as natural disasters. Category 3 identifies the 1143 general public. Priority marks, via C7/NUP, are used to bypass 1144 call-gaping for a given Category. The authority to activate GTPS has 1145 been extended to either a central or delegated authority. 1147 ^L 1149 8.1. GTPS and the Framework Document 1151 The design of the current GTPS, with its designation of preference 1152 based on physical static devices, precludes the need for several 1153 aspects presented in this document. However, one component that can 1154 have a direct correlation is the labeling capability of the proposed 1155 Resource Priority extension to SIP. A new label mechanism for SIP 1156 could allow a transparent interoperation between IP telephony and the 1157 U.K. PSTN that supports GTPS. 1159 9. Appendix B: Related Standards Work 1161 The process of defining various labels to distinguish calls has been, 1162 and continues to be, pursued in other standards groups. As mentioned 1163 in section 1.1.1, the ANSI T1S1 group has previously defined a label 1164 SS7 ISUP Initial Address Message. This single label or value is 1165 referred to as the National Security and Emergency Preparedness 1166 (NS/EP) indicator and is part of the T1.631 standard. The following 1167 subsections presents a snap shot of parallel on-going efforts in 1168 various standards groups. 1170 It is important to note that the recent activity in other groups have 1171 gravitated to defining 5 labels or levels of priority. The impact of 1172 this approach is minimal in relation to this ETS framework document 1173 because it simply generates a need to define a set of corresponding 1174 labels for the resource priority header of SIP. 1176 9.1. Study Group 16 (ITU) 1178 Study Group 16 (SG16) of the ITU is responsible for studies relating 1179 to multimedia service definition and multimedia systems, including 1180 protocols and signal processing. 1182 A contribution [35] has been accepted by this group that adds a 1183 Priority Class parameter to the call establishment messages of H.323. 1184 This class is further divided into two parts; one for Priority Value 1185 and the other is a Priority Extension for indicating subclasses. It 1186 is this former part that roughly corresponds to the labels tran- 1187 sported via the Resource Priority field for SIP [15]. 1189 The draft recommendation advocates defining PriorityClass information 1190 that would be carried in the GenericData parameter in the H323-UU-PDU 1191 or RAS messages. The GenericData parameter contains Priori- 1192 tyClassGenericData. The PriorityClassInfo of the PriorityClassGener- 1193 icData contains the Priority and Priority Extension fields. 1195 ^L 1196 At present, 5 levels have been defined for the Priority Value part of 1197 the Priority Class parameter: Low, Normal, High, Emergency-Public, 1198 Emergency-Authorized. An additional 8-bit priority extension has been 1199 defined to provide for subclasses of service at each priority. 1201 The suggested ASN.1 definition of the service class is the following: 1203 ServiceClassInfo ::= SEQUENCE 1204 { 1205 priority CHOICE 1206 { 1207 emergencyAuthorized NULL, 1208 emergencyPublic NULL, 1209 high NULL, 1210 normal NULL, 1211 low NULL 1212 } 1213 priorityExtension INTEGER (0..255) OPTIONAL; 1214 requiredClass NULL OPTIONAL 1215 tokens SEQUENCE OF ClearToken OPTIONAL 1216 cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL 1217 } 1219 The advantage in using the GenericData parameter is that an existing 1220 parameter is used, as opposed to defining a new parameter and causing 1221 subsequent changes in existing H.323/H.225 documents. 1223 10. Acknowledgments 1225 The authors would like to acknowledge the helpful comments, opinions, 1226 and clarifications of Stu Goldman, James Polk, Dennis Berg, as well 1227 as those comments received from the IEPS and IEPREP mailing lists. 1228 Additional thanks to Peter Walker of Oftel for private discussions on 1229 the operation of GTPS, and Gary Thom on clarifications of the SG16 1230 draft contribution. 1232 11. Author's Addresses 1234 Ken Carlberg Ian Brown 1235 University College London University College London 1236 Department of Computer Science Department of Computer Science 1237 Gower Street Gower Street 1238 London, WC1E 6BT London, WC1E 6BT 1239 United Kingdom United Kingdom 1241 ^L 1242 Cory Beard 1243 University of Missouri-Kansas City 1244 Division of Computer Science 1245 Electrical Engineering 1246 5100 Rockhill Road 1247 Kansas City, MO 64110-2499 1248 USA 1249 BeardC@umkc.edu 1251 ^L 1252 Table of Contents 1254 1. Introduction ................................................... 2 1255 1.1 Emergency Related Data ....................................... 3 1256 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 4 1257 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4 1258 1.2 Scope of this Document ....................................... 4 1259 2. Objective ..................................................... 6 1260 3. Value Added Objective ......................................... 9 1261 3.1 Alternate Path Routing ....................................... 9 1262 3.2 End-to-End Fault Tolerance ................................... 10 1263 4. Protocols and Capabilities .................................... 11 1264 4.1 Signaling & State Information ................................ 11 1265 4.1.1 SIP ........................................................ 12 1266 4.1.2 Diff-Serv .................................................. 12 1267 4.1.3 Variations Related to Diff-Serv and Queuing ................ 13 1268 4.1.4 RTP ........................................................ 15 1269 4.1.5 MEGACO/H.248 ............................................... 16 1270 4.2 Policy ....................................................... 17 1271 4.3 Traffic Engineering .......................................... 17 1272 4.4 Security ..................................................... 18 1273 5. Key Scenarios ................................................. 19 1274 6. Security Considerations ....................................... 21 1275 7. References .................................................... 21 1276 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 24 1277 8.1 GTPS and the Framework Document .............................. 25 1278 9. Appendix B: Related Standards Work ............................ 25 1279 9.1 Study Group 16 (ITU) ......................................... 25 1280 10. Acknowledgments .............................................. 26 1281 11. Author's Addresses ........................................... 26 1283 Full Copyright Statement 1285 "Copyright (C) The Internet Society (date). All Rights Reserved. 1286 This document and translations of it may be copied and furnished to 1287 others, and derivative works that comment on or otherwise explain it 1288 or assist in its implementation may be prepared, copied, published 1289 and distributed, in whole or in part, without restriction of any 1290 kind, provided that the above copyright notice and this paragraph are 1291 included on all such copies and derivative works. However, this 1292 document itself may not be modified in any way, such as by removing 1293 the copyright notice or references to the Internet Society or other 1295 ^L 1296 Internet organizations, except as needed for the purpose of develop- 1297 ing Internet standards in which case the procedures for copyrights 1298 defined in the Internet Standards process must be followed, or as 1299 required to translate it into languages other than English. 1301 The limited permissions granted above are perpetual and will not be 1302 revoked by the Internet Society or its successors or assigns. 1304 This document and the information contained herein is provided as an 1305 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1306 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1307 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1308 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- 1309 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.