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