idnits 2.17.1 draft-carlberg-ieprep-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 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. 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 14 looks like a reference -- Missing reference section? '2' on line 84 looks like a reference -- Missing reference section? '3' on line 61 looks like a reference -- Missing reference section? '4' on line 63 looks like a reference -- Missing reference section? '5' on line 63 looks like a reference -- Missing reference section? '6' on line 73 looks like a reference -- Missing reference section? '7' on line 74 looks like a reference -- Missing reference section? '8' on line 81 looks like a reference -- Missing reference section? '9' on line 801 looks like a reference -- Missing reference section? '10' on line 108 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? '13' on line 162 looks like a reference -- Missing reference section? '18' on line 204 looks like a reference -- Missing reference section? '28' on line 206 looks like a reference -- Missing reference section? '14' on line 529 looks like a reference -- Missing reference section? '26' on line 339 looks like a reference -- Missing reference section? '15' on line 615 looks like a reference -- Missing reference section? '21' on line 449 looks like a reference -- Missing reference section? '19' on line 458 looks like a reference -- Missing reference section? '22' on line 460 looks like a reference -- Missing reference section? '24' on line 527 looks like a reference -- Missing reference section? '25' on line 527 looks like a reference -- Missing reference section? '16' on line 620 looks like a reference -- Missing reference section? '20' on line 668 looks like a reference -- Missing reference section? '29' on line 724 looks like a reference -- Missing reference section? '27' on line 731 looks like a reference -- Missing reference section? '23' on line 741 looks like a reference -- Missing reference section? '17' on line 779 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 31 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 UCL 4 February 15, 2002 Ian Brown 5 UCL 7 Framework for Supporting IEPS in IP Telephony 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 25 Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 For potential updates to the above required-text see: 29 http://www.ietf.org/ietf/1id-guidelines.txt 31 Abstract 33 This document presents a framework for supporting authorized 34 emergency related communication within the context of IP telephony. 35 We present a series of objectives that reflect a general view of how 36 authorized emergency service, in line with the International 37 Emergency Preparedness Scheme (IEPS), should be realized within 38 today's IP architecture and service models. From these objectives, 39 we present a corresponding set of functional requirements, which 40 provide a more specific set of recommendations regarding existing 41 IETF protocols. Finally, we present two scenarios that act as 42 guiding models for the objectives and functions listed in this 43 document. These, models, coupled with an example of an existing 44 service in the PSTN, contribute to a constrained solution space. 46 1. Introduction 48 The Internet has become the primary target for worldwide 49 communications. This is in terms of recreation, business, and 50 various imaginative reasons for information distribution. A constant 51 fixture in the evolution of the Internet has been the support of Best 52 Effort as the default service model. Best Effort, in general terms, 53 infers that the network will attempt to forward traffic to the 54 destination as best as it can with no guarantees being made, nor any 55 resources reserved, to support specific measures of Quality of 56 Service (QoS). An underlying goal is to be 'fair' to all the traffic 57 in terms of the resources used to forward it to the destination. 59 In an attempt to go beyond best effort service, [2] presented an 60 overview of Integrated Services (int-serv) and its inclusion into the 61 Internet architecture. This was followed by [3], which specified the 62 RSVP signaling protocol used to convey QoS requirements. With the 63 addition of [4] and [5], specifying control load (bandwidth bounds) 64 and guaranteed service (bandwidth & delay bounds) respectively, a 65 design existed to achieve specific measures of QoS for an end-to-end 66 flow of traffic traversing an IP network. In this case, our 67 reference to a flow is one that is granular in definition and 68 applying to specific application sessions. 70 From a deployment perspective (as of the date of this document), 71 int-serv has been predominantly constrained to stub intra-domain 72 paths, at best resembling isolated "island" reservations for specific 73 types of traffic (e.g., audio and video) by stub domains. [6] and 74 [7] will probably contribute to additional deployment of int-serv to 75 Internet Service Providers (ISP) and possibly some inter-domain 76 paths, but it seems unlikely that the original vision of end-to-end 77 int-serv between hosts in source and destination stub domains will 78 become a reality in the near future (the mid- to far-term is a 79 subject for others to contemplate). 81 In 1998, the IETF produced [8], which presented an architecture for 82 Differentiated Services (diff-serv). This effort focused on a more 83 aggregated perspective and classification of packets than that of 84 [2]. This is accomplished with the recent specification of the 85 diff-serv field in the IP header (in the case of IPv4, it replaced 86 the old ToS field). This new field is used for code points 87 established by IANA, or set aside as experimental. It can be 88 expected that sets of microflows, a granular identification of a set 89 of packets, will correspond to a given code point, thereby achieving 90 an aggregated treatment of data. 92 One constant in the introduction of new service models has been the 93 designation of Best Effort as the default service model. If traffic 94 is not, or cannot be, associated as diff-serv or int-serv, then it is 95 treated as Best Effort and uses what resources are made available to 96 it. 98 Beyond the introduction of new services, the continued pace of 99 additional traffic load experienced by ISPs over the years has 100 continued to place a high importance for intra-domain traffic 101 engineering. The explosion of IETF contributions, in the form of 102 drafts and RFCs produced in the area of Multi Protocol Label 103 Switching (MPLS), exemplifies the interest in versatile and 104 manageable mechanisms for intra-domain traffic engineering. One 105 interesting observation is the work involved in supporting QoS 106 sensitive traffic like Voice over IP (VoIP). Specifically, we refer 107 to the work in progress discussion of a framework to support VoIP 108 using MPLS [9], and the inclusion of fault tolerance [10]. This 109 latter item can be viewed as being similar to "crank-back", a term 110 used to describe the means by which the Public Switched Telephone 111 Network (PSTN) routes around congested switches. 113 1.2 Emergency Related Data 115 The evolution of the IP service model architecture has traditionally 116 centered on the type of application protocols used over a network. 117 By this we mean that the distinction, and possible bounds on QoS, 118 usually centers on the type of application (e.g., audio video tools). 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 and how it should be supported. 124 Given the emergence of IP telephony, a natural inclusion of it as 125 part of a telco carriers backbone network, or into the Internet as a 126 whole, implies the ability to support existing emergency related 127 services. Typically, one associates emergency calls with "911" 128 telephone service in the U.S., or "999" in the U.K. -- both of which 129 are attributed to national boundaries and accessible by the general 130 public. Outside of this exists emergency telephone services that 131 involved authorized usage, as described in the following subsection. 133 GETS is an emergency telecommunications service available in the U.S. 134 and established by the National Communications System (NCS) -- an 135 office established by the White House under an executive order. 136 Unlike "911", it is only accessible by authorized individuals. The 137 majority of these individuals are from various government agencies 138 like the Department of Transportation, NASA, the Department of 139 Defense, and the Federal Emergency Management Agency (to name but a 140 few). In addition, individuals from private industry 141 (telecommunications companies, utilities, etc.) that are involved in 142 criticial infrastructure recovery operations are also provided access 143 to GETS. 145 The purpose of GETS is to increase the probability that phone service 146 will be available to selected government agency personnel in times of 147 emergencies, such as hurricanes, earthquakes, and other disasters 148 that may produce a burden in the form of call blocking (i.e., 149 congestion) on the U.S. Public Switched Telephone Network by the 150 general public. 152 The key aspect is that GETS only supports a probabilistic approach to 153 call completion, as opposed to call preemption. This distinction is 154 important because emergency systems like GETS are not allowed to 155 terminate existing calls in order to allow a GETS call to be 156 established. Thus, the mechanisms and specifications that comprise 157 GETS only focus on increasing the chances that a particular telephone 158 call will be established. 160 The basis for GETS with respect to Signaling System 7 (SS7) support 161 is found in the T1.631 protocol on High Probability of Completion 162 (HPC) network capability [13]. This document describes the 163 specification of a National Security and Emergency Preparedness 164 (NS/EP) Calling Party Category (CPC) code point used for SS7 ISDN 165 User Part (ISUP) Initial Address Message (IAM). In the presense of 166 this code point, Local Exchange Carriers (LEC) will attempt (if 167 necessary and if the option is supported) to route the call through 168 alternate inter-exchange carriers (IXC) if it cannot complete the 169 call through the default IXC. 171 The procedure for a user (i.e., a person) establishing a GETS call is 172 as follows: 174 1) Dial a non-geographical area code number: 710-XXX-XXXX 175 2) Dial a PIN used to authenticate the call 176 3) Dial the actual destination number to be reached 178 In conjunction with the above, the source LEC (where the call 179 originated) attempts to establish the call through an IXC. This is 180 done even if the destination number is within the LEC itself. If the 181 IXC cannot forward the call to the destination LEC, then the source 182 LEC attempts to route the call through an alternate IXC. If 183 alternate IXCs cannot help establish the call, then a busy signal is 184 finally returned to the user. Otherwise, the call is completed and 185 retains the same quality of service as all other telephone calls. 187 The HPC component of GETS is not ubiquitously supported by the U.S. 188 PSTN. The only expectation is that the 710 area code is recognized 189 by all carriers. Additional support is conditional and dependent 190 upon the equivalent service level agreements established between the 191 U.S. Government and various telco carriers. Thus, the default end- 192 to-end service for establishing a GETS call can be viewed as best 193 effort and associated with the same priority as calls from the 194 general public. The exception to this rule is when the call is 195 forwarded through carriers that have been contracted through a 196 service level agreement to support HPC, which results in a higher 197 probability that the GETS call will be established. 199 It should be noted from the above description that GETS is separate 200 and unrelated to other emergency services like "911". 202 1.2.1 International Emergency Preparedness Scheme (IEPS) 204 [18] is a recent ITU standard that describes emergency related 205 communications over international telephone service (Note, this 206 document has also been published as a draft-RFC in [28]. While 207 systems like GETS are national in scope, IEPS acts as an extension to 208 local or national authorized emergency call establishment and 209 provides a building block for a global service. 211 As in the case of GETS, IEPS promotes mechanisms like extended 212 queuing, alternate routing, and exemption from restrictive management 213 controls in order to increase the probability that international 214 emergency calls will be established. The specifics of how this is to 215 be accomplished are to be defined in future ITU document(s). 217 1.3 Scope of this Document 219 The scope of this document centers on the support of IEPS within the 220 context of IP telephony, though not necessarily Voice over IP. We 221 make a distinction between these two by treating IP telephony as a 222 subset of VoIP, where in the former we assume some form of 223 application layer signaling is used to explicitly establish and 224 maintain voice data traffic. This explicit signaling capability 225 provides the hooks from which VoIP traffic can be bridged to the 226 PSTN. 228 An example of this distinction is when the Redundant Audio Tool (RAT) 229 [14] begins sending VoIP packets to a unicast (or multicast) 230 destination. RAT does not use explicit signaling like SIP to 231 establish an end-to-end call between two users. It simply sends data 232 packets to the target destination. On the other hand, "SIP phones" 233 are host devices that use a signaling protocol to establish a call 234 signal before sending data towards the destination. 236 Beyond this, part of our motivation in writing this document is to 237 provide a reference point for ISPs and carriers so that they have an 238 understanding of objectives and accompanying functional requirements 239 used to support IEPS related IP telephony traffic. In addition, we 240 also wish to provide a reference point for potential customers (users 241 of IEPS) in order to constrain their expectations. In particular, we 242 wish to avoid any temptation of trying to replicate the exact 243 capabilities of existing emergency voice service currently available 244 in the PSTN to that of IP and the Internet. If nothing else, 245 intrinsic differences between the two communications architectures 246 precludes this from happening. Note, this does not prevent us from 247 borrowing design concepts or objectives from existing systems. 249 Section 2 presents several primary objectives that articulate what is 250 considered important in supporting IEPS related IP telephony traffic. 251 These objectives represent a generic set of goals and capabilities 252 attributed to supporting IEPS based IP telephony. Section 3 presents 253 additional value added objectives. These are capabilities that are 254 viewed as useful, but not critical in support of IEPS. Section 4 255 presents a series of functional requirements that stem from the 256 objectives articulated in section 2. Finally, Section 5 presents two 257 scenarios in IEPS that exist or are being deployed over IP networks. 258 These are not all-inclusive scenarios, nor are they the only ones 259 that can be articulated. However, they do show cases where some of 260 the functional requirements apply, and where some do not. 262 Finally, we need to state that this document focuses its attention on 263 the IP layer and above. Specific operational procedures pertaining 264 to Network Operation Centers (NOC) or Network Information Centers 265 (NIC) are outside the scope of this document. This includes the 266 "bits" below IP, other specific technologies, and service level 267 agreements between ISPs and carriers with regard to dedicated links. 269 2. Objective 271 The support of IEPS within IP telephony can be realized in the form 272 of several primary objectives. These objectives define the generic 273 functions or capabilities associated with IEPS, and the scope of the 274 support needed to achieve these capabilities. From this generic set 275 of objectives, we present specific functional requirements of 276 existing IP protocols (presented below in section 3). 278 There are two underlying goals in the selection of these objectives. 279 One goal is to produce a design that maximizes the use of existing IP 280 protocols and minimizes the set of additional specifications needed 281 to support IP-telephony based IEPS. Thus, with the inclusion of 282 these minimal augmentations, the bulk of the work in achieving IEPS 283 over an IP network that is connected or unconnected to the Internet 284 involves operational issues. Examples of this would be the 285 establishment of Service Level Agreements (SLA) with ISPs, and/or the 286 provisioning of traffic engineered paths for IEPS-related telephony 287 traffic. 289 A second underlying goal in selecting the following objectives is to 290 take into account experiences from an existing emergency-type 291 communication system (as described in section 1.2.1) as well as the 292 existing restrictions and constraints placed by some countries. In 293 the former case, we do not attempt to mimic the system, but rather 294 extract information as a reference model. With respect to 295 constraints based on laws or agency regulations, this would normally 296 be considered outside of the scope of any IETF document. However, 297 these constraints act as a means of determining the lowest common 298 denominator in specifying technical functional requirements. If such 299 constraints do not exist, then additional functions can be added to 300 the baseline set of functions. This last item will be expanded upon 301 in the description of Objective #3 below. 303 The following list of objectives are termed primary because they 304 pertain to that which defines the underlying goals of IEPS in 305 relation to IP telephony. However, the primary objectives are not 306 meant to dictate major overhauls of existing IP protocols, nor do 307 they require new protocols to be developed. 309 Primary Objectives in support of authorized emergency calls: 311 1) High Probability of Call Completion 312 2) Interaction with PSTN 313 3) Distinction of IEPS data traffic 314 4) Non-preemptive action 315 5) Non-ubiquitous support 316 6) Authenticated service 318 The first objective is the crux of our work because it defines our 319 expectations for both data and call signaling for IP telephony. As 320 stated, our objective is achieving a high probability that emergency 321 related calls (both data and signaling) will be forwarded through an 322 IP network. Specifically, we envision the relevance of this 323 objective during times of congestion, the context of which we 324 describe further below in this section. The critical word in this 325 objective is "probability", as opposed to assurance or guarantee -- 326 the latter two placing a higher burden on the network. It stands to 327 reason, though, that the word "probability" is a less tangible 328 description that cannot be easily quantified. It is relative in 329 relation to other traffic transiting the same network. Objectives 3 330 through 5 below help us to qualify the term probability in the 331 context of other objectives. 333 The second objective involves the interaction of IP telephony 334 signaling with existing PSTN support for emergency related voice 335 communications. As mentioned above in Section 1.2, standard T1.631 336 [26] specifies emergency code points for SS7. Specifically, the 337 National Security and Emergency Preparedness (NS/EP) Calling Party 338 Category code point is defined for ISUP IAM messages used by SS7 339 [26]. Hence, our objective in the interaction between the PSTN and 340 IP telephony with respect to IEPS (and national indicators) is a 341 direct mapping between related code points. 343 The third objective focuses on the ability to distinguish IEPS data 344 packets from other types of VoIP packets. With such an ability, 345 transit providers can more easily ensure that service level 346 agreements relating to IEPS are adhered. Note that we do not assume 347 that the actions taken to distinguish IEPS type packets is easy. 348 Nor, in this section, do we state the form of this distinction. We 349 simply present the objective of identifying flows that relate to IEPS 350 versus others that traverse a transit network. 352 At an abstract level, the forth objective pertains to the actions 353 taken when an IP telephony call, via a signaling protocol such as 354 SIP, cannot be forwarded because the network is experiencing a form 355 of congestion. We state this in general terms because of two 356 reasons: a) there may exist applications other than SIP, like H.248, 357 used for call establishment, and b) congestion may come in several 358 forms. For example, congestion may exist at the IP packet layer with 359 respect to queues being filled to their configured limit. Congestion 360 may also arise from resource allocation attributed per call or 361 aggregated sets of calls. In this latter case, while there may exist 362 resources to forward the packets, a signaling server may have reached 363 its limit as to how many telephony calls it will support while 364 retaining toll-quality service per call. Typically, one terms this 365 form of congestion as call blocking. Note that we do not address the 366 case when congestion occurs at the bit level below that of IP, due to 367 the position that it is outside the scope of IP and the IETF. 369 So, given the existence of congestion in its various forms, our 370 objective is to support IEPS-related IP telephony call signaling and 371 data traffic via non-preemptive actions taken by the network. More 372 specifically, we associate this objective in the context of IP 373 telephony acting as part of the Public Telephone Network (PTN). 374 This, as opposed to the use of IP telephony within a private or stub 375 network. In section 5 below, we expand on this through the 376 description of two distinct scenarios of IP telephony and its 377 operation with IEPS and the PSTN. 379 It is important to mention that this is a default objective 380 influenced by existing laws & regulations. Those countries not bound 381 by these restrictions can remove this objective and make provisions 382 to enforce preemptive action. In this case, it would probably be 383 advantageous to deploy a signaling system similar to that proposed in 384 [15], wherein multiple levels of priority are defined and preemption 385 via admission control from SIP servers is enforced. 387 The fifth objective stipulates that we do not advocate the need or 388 expectation for ubiquitous support of IEPS across all administrative 389 domains of the Internet. While it would be desirable to have 390 ubiquitous support, we feel the reliance of such a requirement would 391 doom even the contemplation of supporting IEPS by the IETF and the 392 expected entities (e.g., ISPs and vendors) involved in its 393 deployment. 395 We use the existing GETS service in the U.S. as an existing example 396 in which emergency related communications does not need to be 397 ubiquitous. As mentioned previously, the measure and amount of 398 support provided by the U.S. PSTN for GETS is not ubiquitous across 399 all U.S. Inter-exchange Carriers (IXC) nor Local Exchange Carriers 400 (LEC). Given the fact that GETS still works within this context, it 401 is our objective to follow this deployment model such that we can 402 accomplish the first objective listed above -- a higher probability 403 of call completion than that of normal IP telephony call traffic. 405 Our final objective is that only authorized users may use the 406 services outlined in this framework. GETS users are authenticated 407 using a PIN provided to the telecommunications carrier, which signals 408 approval back to the user's local exchange over SS7. In an IP 409 network, the authentication center will need to securely signal back 410 to the IP ingress point that a given user is authorized to send IEPS 411 related flows. Similarly, transit networks with IEPS SLAs must 412 securely interchange authorized IEPS traffic. In both cases, IPSec 413 authentication transforms may be used to protect this traffic. This 414 is entirely separate from end-to-end IPSec protection of user 415 traffic, which will be configured by users. IP-PSTN gateways must 416 also be able to securely signal IEPS authorization for a given flow. 417 As these gateways are likely to act as SIP servers, we further 418 consider the use of SIP's security functions to aid this objective. 420 3. Value Added Objective 422 This objective is viewed as being helpful in achieving a high 423 probability of call completion. Its realization within an IP network 424 would be in the form of new protocols or enhancements to existing 425 ones. Thus, objective listed in this section are treated as value 426 added -- an expectation that their existence would be beneficial, and 427 yet not viewed as critical to support IEPS related IP telephony 428 traffic. 430 3.1 Alternate Path Routing 432 This objective involves the ability to discover and use a different 433 path to route IP telephony traffic around congestion points and thus 434 avoid them. Ideally, the discovery process would be accomplished in 435 an expedient manner (possibly even a priori to the need of its 436 existence). At this level, we make no requirements as to how the 437 alternate path is accomplished, or even at which layer it is achieved 438 -- e.g., the network versus the application layer. But this kind of 439 capability, at least in a minimal form, would help contribute to 440 increasing the probability of call completion of IEPS traffic by 441 making use of noncongested alternate paths. We use the term "minimal 442 form" to concede the fact that care must be taken in how the system 443 provides alternate paths so it does not significantly contribute to 444 the congestion that is to be avoided (e.g., via excess 445 control/discovery messages). 447 At the time that this document was written, we can identify two 448 work-in-progress areas in the IETF that can be helpful in providing 449 alternate paths for call signaling. The first is [21], which is 450 focused on network layer routing and describes enhancements to the 451 LDP specification of MPLS to help achieve fault tolerance. This in 452 itself does not provide alternate path routing, but rather helps 453 minimize loss in intradomain connectivity when MPLS is used within a 454 domain. 456 The second effort comes from the IP Telephony working group and 457 involves Telephony Routing over IP (TRIP). To date, a framework 458 document [19] has been published as an RFC which describes the 459 discovery and exchange of IP telephony gateway routing tables between 460 providers. The TRIP protocol [22], a supplemental work in progress, 461 specifies application level telephony routing regardless of the 462 signaling protocol being used (e.g., SIP or H.323). TRIP is modeled 463 after BGP-4 and advertises reachability and attributes of 464 destinations. In its current form, several attributes have already 465 been defined, such as LocalPreference and MultiExitDisc. Upon 466 standardization of TRIP, additional attributes can be registered with 467 IANA. Initially, we would recommend two additional attributes that 468 would relate to emergency related flows. These being: 470 EmergencyMultiExitDisc 472 The EmergencyMultiExitDisc attribute is similar to the 473 MultiExitDisc in that it is an inter-domain attribute used 474 to express a preference of one or more links over others 475 between domains. Unlike the MultiExitDisc, this attribute 476 specifically identifies links that are preferred for emergency 477 related calls that span domains. 479 EmergencyLocalPreference 481 The EmergencyLocalPreference attribute is similar to the 482 LocalPreference in that it is an intra-domain attribute used 483 to inform other LSs of the local LSs preference for a given 484 route. The difference between the two types attributes is 485 that the preferred route specifically relates to emergency-type 486 calls (e.g., 911). This attribute has no significance between 487 domains. Local policy determines if there is an association 488 between the EmergencyLocalPreference and the 489 EmergencyMultiExitDisc attribute. 491 3.2 End-to-End Fault Tolerance 493 This topic involves the work that has been done in trying to 494 compensate for lossy networks providing best effort service. In 495 particular, we focus on the use of a) Forward Error Correction (FEC), 496 and b) redundant transmissions that can be used to compensate for 497 lost data packets. (Note that our aim is fault tolerance, as opposed 498 to an expectation of always achieving it). 500 In the former case, additional FEC data packets are constructed from 501 a set of original data packets and inserted into the end-to-end 502 stream. Depending on the algorithm used, these FEC packets can 503 reconstruct one or more of the original set that were lost by the 504 network. An example may be in the form of a 10:3 ratio, in which 10 505 original packets are used to generate three additional FEC packets. 506 Thus, if the network loses 30% or less number of packets, then the 507 FEC scheme will be able to compensate for that loss. The drawback to 508 this approach is that to compensate for the loss, a steady state 509 increase in offered load has been injected into the network. This 510 makes an arguement that the act of protection against loss has 511 contributed to additional pressures leading to congestion, which in 512 turn helps trigger packet loss. In addition, in using a ratio of 513 10:3, the source (or some proxy) must 'hold' all 10 packets in order 514 to construct the three FEC packets. This contributes to the end-to- 515 end delay of the packets as well as minor bursts of load in addition 516 to changes in jitter. 518 The other form of fault tolerance we discuss involves the use of 519 redundant transmissions. By this we mean the case in which an 520 original data packet is followed by one or more redundant packets. 521 At first glance, this would appear to be even less friendly to the 522 network than that of adding FEC packets. However, the encodings of 523 the redundant packets can be of a different type (or even transcoded 524 into a lower quality) that produce redundant data packets that are 525 significantly smaller than the original packet. 527 Two RFCs [24, 25] have been produced that define RTP payloads for FEC 528 and redundant audio data. An implementation example of a redundant 529 audio application can be found in [14]. We note that both FEC and 530 redundant transmissions can be viewed as rather specific and to a 531 degree tangential solutions regarding packet loss and emergency 532 communications. Hence, these topics are placed under the category of 533 value added objectives. 535 4. Functional Requirements 537 In this section, we take the objectives presented above and specify a 538 corresponding set of functional requirements to achieve them. Given 539 that the objectives are predominantly atomic in nature, the 540 corresponding functional requirements are to be viewed separately 541 with no specific dependency upon each other as a whole. They may be 542 complimentary with each other, but there is no need for all to exist 543 given different scenarios of operation, and that IEPS support is not 544 viewed as a ubiquitously available service. We divide the functional 545 requirements into 4 areas: 547 1) Signaling 548 2) Policy 549 3) Traffic Engineering 550 4) Security 552 4.1 Signaling 554 Signaling is used to convey various information to either 555 intermediate nodes or end nodes. It can be out-of-band of a data 556 flow, and thus in a separate flow of its own, such as SIP messages. 557 It can also be in-band and part of the datagram containing the voice 558 data. This latter example could also be in the form of diff-serv 559 code points in the IP packet, and/or in an extension to the RTP 560 header denoting an additional classification of the payload -- the 561 latter predominantly being used on an end-to-end basis. 563 In the following subsections, we discuss augmentations to three 564 specific types of signaling to help support the distinction of 565 emergency related communications in general, and IEPS specifically. 566 We also discuss Media Gateway Control (MEGACO). 568 4.1.1 SIP 570 With respect to application level signaling for IP telephony, we 571 focus our attention to the Session Initiation Protocol (SIP). 572 Currently, SIP has an existing "priority" field in the Request- 573 Header-Field that distinguishes different types of sessions. The 574 five currently defined values are: "emergency", "urgent", "normal", 575 "non-urgent", "other-priority". 577 It is understood that the IETF prefers that no changes or additions 578 be made to these existing values. Hence, we shall follow the 579 approach taken in [15] and propose the specification of a new field 580 in the "Request-Header-Field" titled "Emergency-State". This new 581 field provides an additional level in distinguishing types of 582 emergencies. Currently, we would propose defining two values for 583 this field: 585 1) "authorized-emergency" 586 2) "general-emergency" 588 The former would correlate to calls that have been initiated by an 589 authorized individual. Specifically, this single SIP value would 590 correlate to other authorized PSTN based code points like NS/EP and 591 IEPS. The second defined value would correlate to the more commonly 592 known type of local emergency calls initiated by the general public 593 (e.g., "911" in the U.S., "999", in the UK, and "112" in Germany). 594 The objective is to define a single generic value that correlates to 595 several similar but different types of emergency calls. 597 It is important to note that this is the one functional requirement 598 that is considered mandatory with respect to supporting IEPS within 599 IP telephony. We take this position because regardless of the extent 600 by which the underlying network supports IEPS-based traffic, there is 601 a need to distinguish IEPS sessions (i.e., authorized-emergency 602 calls) from others. 604 The existence of this new value in the SIP priority field allows an 605 IP telephony domain to map an IEPS call to the existing NS/EP code 606 point from an SS7 telephony domain. This will help facilitate a 607 seamless interaction between the PSTN and the an IP network acting as 608 either an internal backbone or as a peering ISP. 610 Author's Note: The work put forth by James Polk in [15] is quite 611 similar to our own in that both articulate a need to specify a more 612 granular and specific means of identifying different types of 613 emergencies. Beyond the different values specified for MLPP, the 614 main difference between the two efforts involves the use of 615 preemption for [15], as opposed to our need to simply increase the 616 probability of call completion. 618 4.1.2 Diff-Serv 620 In accordance to [16], the differentiated services code point (DSCP) 621 field is divided into three sets of values. The first set is 622 assigned by IANA. Within this set, there are currently, three types 623 of Per Hop Behaviors have been specified: Default (correlating to 624 best effort forwarding), Assured Forwarding, and Expedited 625 Forwarding. The second set of DSCP values are set aside for local or 626 experimental use. The third set of DSCP values are also set local or 627 experimental use, but may later be reassigned to IANNA in case the 628 first set has been completely assigned. 630 One recomendation involves the specification of a new type of Per-Hop 631 Behavior (PHB) we term Emergency Related Forwarding (ERF). This 632 would provide a specific means of distinguishing emergency related 633 traffic (signaling and user data) from other traffic. The existence 634 of this PHB then provides a baseline by which specific code points 635 may be defined related to various emergency related traffic: 636 authorized emergency sessions (e.g., IEPS), general public emergency 637 calls (e.g., "911"), MLPP. Aggregates would still exist with respect 638 to the bundling of applications per code point. Further, one would 639 associate a forwarding paradigm aimed at a low loss rate reflective 640 of the code point selected. Hence, SIP or H.323 messages marked with 641 "authorized-emergency" or "emergency" may be assigned a code point 642 reflecting a lower loss rate than other type of traffic (even the 643 emergency-related data flow itself). The jitter associated with 644 application layer signaling of IP telephony would be inversely 645 important with respect to loss rate, and thus would be reflective of 646 the code points defined for the proposed PHB. 648 Another recomendation would be to define a new or fifth class for the 649 existing AF PHB. Unlike the other currently defined classes, this 650 new one would be based on five levels of drop precedence. This 651 increase in the number of levels would conveniently correlate to the 652 worst case scenario posed by MLPP, which has five types of 653 priorities. In addition, it would provide a higher level of variance 654 that could be used to supercede the existing 3 levels used in the 655 other classes. Hence, if other non-emergency aggregate traffic where 656 assigned to the class, the highest drop precedence they are assigned 657 to is (3) -- corresponding to the other four currently defined 658 classes. Emergency traffic would be set to (4) or (5), depending on 659 the SLA tht has been defined. 661 It is important to note that as of the time that this document was 662 written, the IETF is taking a conservative approach in specifying new 663 PHBs. This is because the number of code points that can be defined 664 is relatively small, and thus understandably considered a scarce 665 resource. Therefore, the possibility of a new PHB being defined for 666 emergency-related traffic is at best a long term project that may or 667 may not be accepted by the IETF. In the meantime, we would initially 668 recommend using the Assured Forwarding (AF) PHB [20] for 669 distinguishing emergency traffic from other types of flows. 670 Specifically, we would suggest the use the low drop precedence of one 671 of the four defined classes of AF codepoints. It is critical to note 672 that one cannot specify an exact code point used for emergency 673 related data flows because the relevance of a code point is local to 674 the given diff-serv domain (i.e., they are not globally unique per 675 micro-flow or aggregate of flows). In addition, we can expect that 676 the existence of a codepoint for emergency related flows is based on 677 the service level agreements established with a given diff-serv 678 domain. 680 4.1.3 RTP 682 The Real-Time Transport Protocol (RTP) provides end-to-end delivery 683 services for data with real-time characteristics. The type of data 684 is generally in the form of audio or video type applications, and are 685 frequently interactive in nature. RTP is typically run over UDP and 686 has been designed with a fixed header that identifies a specific type 687 of payload -- typically representing a specific form of application 688 media. The designers of RTP also assumed an underlying network 689 providing best effort service. As such, RTP does not provide any 690 mechanism to ensure timely delivery or provide other QoS guarantees. 691 However, the emergence of applications like IP telephony, as well as 692 new service models, presents new environments where RTP traffic may 693 be forwarded over networks that support better than best effort 694 service. Hence, the original scope and target environment for RTP 695 has expanded to include networks providing services other than best 696 effort. 698 In 4.1.2, we discussed one means of marking a data packet for 699 emergencies under the context of the diff-serv architecture. 700 However, we also pointed out that diff-serv markings for specific 701 PHBs are not globally unique, and may be arbitrarily removed or even 702 changed by intermediary nodes or domains. Hence, with respect to 703 emergency related data packets, we are still missing an in-band 704 marking in a data packet that stays constant on an end-to-end basis. 706 We have three choices in defining a persistent marking of data 707 packets and thus avoid the transitory marking of diff-serv code 708 points. We can propose a new PHB dedicated for emergency type 709 traffic as discussed in 4.1.2. We can propose a specification of a 710 new shim layer protocol at some location above IP. Or, we can add a 711 new specification to an existing upper layer protocol. The first two 712 cases are probably the "cleanest" architecturally, but they are long 713 term efforts that will take time to support in terms of design and 714 implementation. It also may be argued that yet another shim layer 715 will make the IP stack too large. The third case, placing a marking 716 in an application layer packet, has the potential to be more 717 appealing depending on where the augmentation is targeted. 719 An approach in realizing this third case involves an augmentation to 720 RTP so that it can carry a marking that distinguishes emergency- 721 related traffic from that which is not. Specifically, one would 722 define a new extention that contains a "classifier" field indicating 723 the condition associated with the packet (e.g., authorized-emergency, 724 emergency, normal) [29]. 726 An issue in defining a new extension to RTP is that its presence may 727 adversely affect header compression for those implementations that 728 are not expecting added optional octets in RTP packets. In addition, 729 the issue of security and authentication of such a marking remains an 730 important issue and is subject to the constraints discussed below in 731 section 4.4, and in more detail in [27]. 733 4.1.4 MEGACO/H.248 735 The Media Gateway Control protocol (MEGACO) [23] defines the 736 interaction between a media gateway and a media gateway controller. 737 [23] is viewed as common text with ITU-T Recommendation H.248 and is 738 a result of applying the changes of RFC 2886 (Megaco Errata) to the 739 text of RFC 2885 (Megaco Protocol version 0.8). 741 In [23], the protocol specifies a Priority and Emergency field for a 742 context attribute and descriptor. The Emergency is an optional 743 boolean (True or False) condition. The Priority value, which ranges 744 from 0 through 15, specifies the precedence handling for a context. 746 The protocol does not specify individual values for priority. We 747 also do not recommend the definition of a well known value for the 748 MEGAGO priority. Any values set should be a function of any SLAs 749 that have been established regarding the handling of emergency 750 traffic. In addition, given that priority values denote precedence 751 (according to the Megaco protocol), then by default the IEPS flows 752 should probably receive the same priority as other non-emergency 753 calls. This approach follows the objective of not relying on 754 preemption as the default treatment of emergency-related. 756 4.2 Policy 758 One of the objectives listed in section 3 above is to treat IEPS- 759 signaling, and related data traffic, as non-preemptive in nature. 760 Further, that this treatment is to be the default mode of operation 761 or service. This is in recognition that existing regulations or laws 762 of certain countries governing the establishment of SLAs may not 763 allow preemptive actions (e.g., dropping existing telephony flows). 764 On the other hand, the laws and regulations of other countries 765 influencing the specification of SLA(s) may allow preemption, or even 766 require its existence. Given this disparity, we rely on local policy 767 to determine the degree by which emergency related traffic affects 768 existing traffic load of a given network or ISP. Important note: we 769 reiterate our earlier comment that laws and regulations are generally 770 outside the scope of the IETF and its specification of designs and 771 protocols. However, these constraints can be used as a guide in 772 producing a baseline function to be supported; in our case, a default 773 policy for non-preemptive call establishment of IEPS-signaling and 774 data. 776 Policy can be in the form of static information embedded in various 777 components (e.g., SIP servers or bandwidth brokers), or it can be 778 realized and supported via COPS with respect to allocation of a 779 domain's resources [17]. There is no requirement as to how policy is 780 accomplished. Instead, if a domain follows actions outside of the 781 default non-preemptive action of IEPS-related communication, then we 782 stipulate a functional requirement that some type of policy mechanism 783 is in place to satisfy the local policies of an SLA established for 784 IEPS type traffic. 786 4.3 Traffic Engineering 788 In those cases where a network operates under the constraints of 789 SLAs, one or more of which pertains to IEPS based traffic, it can be 790 expected that some form of traffic engineering is applied to the 791 operation of the network. We make no requirements as to which type 792 of traffic engineering mechanism is used, but that such a system 793 exists and can distinguish and support IEPS signaling and data 794 traffic. 796 A potentially complimentary work in progress can be found in [9], 797 which articulates a framework for Voice over MPLS. We cite the draft 798 only as a point of reference, with the idea that it may be augmented 799 to reflect labeled path(s) dedicated to different values in the SIP 800 priority field -- such as those pertaining to emergencies. But of 801 more significance, [9] presents a specific framework for traffic 802 engineering support of toll quality (i.e., a particular grade of 803 service) IP telephony. 805 Note: As a point of reference, existing SLAs established by the NCS 806 for GETS service tend to focus on a maximum allocation of 1% of calls 807 allowed to be established through a given LEC using HPC. Once this 808 limit is reached, all other GETS calls experience the same probably 809 of call completion as the general public. It is expected, and 810 encouraged, that IEPS related SLAs will have a limit with respect to 811 the amount of traffic distinguished as being emergency related, and 812 initiated by an authorized user. 814 4.4 Security 816 As IEPS support moves from intra-domain PSTN and IP networks to 817 diffuse inter-domain pure IP, authenticated service becomes more 818 complex to provide. Where an IEPS call is carried from PSTN to PSTN 819 via one carrier's backbone IP network, very little IP-specific 820 security support is required. The user authenticates herself as 821 usual to the network using a PIN. The gateway from her PSTN 822 connection into the backbone IP network must be able to signal that 823 the flow has IEPS priority. Conversely, the gateway back into the 824 PSTN must similarly signal the call's higher priority. A secure link 825 between the gateways may be set up using IPSec or SIP security 826 functionality. If the endpoint is an IP device on the carrier's 827 network, the link may be set up securely from the ingress gateway to 828 the end device. 830 As flows traverse more than one IP network, domains whose peering 831 agreements include IEPS support must have means to securely signal a 832 given flow's IEPS status. They may choose to use physical link 833 security and/or IPSec authentication, combined with traffic 834 conditioning measures to limit the amount of IEPS traffic that may 835 pass between the two domains. The inter-domain agreement may require 836 the originating network to take responsibility for ensuring only 837 authorized traffic is marked with IEPS priority; the downstream 838 domain may still perform redundant conditioning to prevent the 839 propagation of theft and denial of service attacks. Security may be 840 provided between ingress and egress gateways or IP endpoints using 841 IPSec or SIP security functions. 843 When a call originates from an IP device, the ingress network may 844 authorize IEPS traffic over that link as part of its user 845 authentication procedures without necessarily communicating with a 846 central IEPS authentication center as happens with POTS-originated 847 calls. These authentication procedures may occur at the link or 848 network layers, but are entirely at the discretion of the ingress 849 network. That network must decide how often it should update its list 850 of authorized IEPS users based on the bounds it is prepared to accept 851 on traffic from recently-revoked users. 853 5. Key Scenarios 855 There are various scenarios in which IP telephony can be realized, 856 each of which can infer a unique set of functional requirements that 857 may include just a subset of those listed above. We acknowledge that 858 a scenario may exist whose functional requirements are not listed 859 above. Our intention is not to consider every possible scenario by 860 which support for emergency related IP telephony can be realized. 861 Rather, we narrow our scope using a single guideline; we assume there 862 is a signaling & data interaction between the PSTN and the IP network 863 with respect to supporting emergency-related telephony traffic. We 864 stress that this does not preclude an IP-only end-to-end model, but 865 rather the inclusion of the PSTN expands the problem space and 866 includes the current dominant form of voice communication. 868 There are two scenarios that we use as a model for determining our 869 objectives and subsequent functional requirements. These are: 871 Single IP Administrative Domain 872 ------------------------------- 874 This scenario is a direct reflection of the evolution of the PSTN. 875 Specifically, we refer to the case in which data networks have 876 emerged in various degrees as a backbone infrastructure connecting 877 PSTN switches at its edges. This represents a single isolated IP 878 administrative domain that has no directly adjacent IP domains 879 connected to it. We show an example of this scenario below in Figure 880 1. In this example, we show two types of carriers. One is the 881 legacy carrier, whose infrastructure retains the classic switching 882 architecture attributed to the PSTN. The other is the next 883 generation carrier, which uses a data network (e.g., IP) as its core 884 infrastructure, and Signaling Gateways at its edges. These gateways 885 "speak" SS7 externally with peering carriers, and another protocol 886 (e.g., SIP) internally, which rides on top of the IP infrastructure. 888 Legacy Next Generation Next Generation 889 Carrier Carrier Carrier 890 ******* *************** ************** 891 * * * * ISUP * * 892 SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG 893 * * (SS7) * (SIP) * (SS7) * (SIP) * 894 ******* *************** ************** 896 SW - Telco Switch 897 SG - Signaling Gateway 899 Figure 1 901 The significant aspect of this scenario is that all the resources of 902 each IP "island" fall within a given administrative authority. 903 Hence, there is no problem of retaining toll quality Grade of Service 904 as the voice traffic (data and signaling) exits the IP network 905 because of the existing SS7 provisioned service between carriers. 906 Thus, the need for support of mechanisms like diff-serv, and an 907 expansion of the defined set of Per-Hop Behaviors is reduced (if not 908 eliminated) under this scenario. 910 Another function that has little or no importance within the closed 911 IP environment of Figure 1 is that of IP security. The fact that 912 each administrative domain peers with each other as part of the PSTN, 913 means that existing security, in the form of Personal Identification 914 Number (PIN) authentication (under the context of telephony 915 infrastructure protection), is the default scope of security. We do 916 not claim that the reliance on a PIN based security system is highly 917 secure or even desirable. But, we use this system as a default 918 mechanism in order to avoid placing additional requirements on 919 existing authorized emergency telephony systems. 921 Multiple IP Administrative Domains 922 ---------------------------------- 924 We view the scenario of multiple IP administrative domains as a 925 superset of the previous scenario. Specifically, we retain the 926 notion that the IP telephony system peers with the existing PSTN. In 927 addition, segments (i.e., portions of the Internet) may exchange 928 signaling with other IP administrative domains via non-PSTN signaling 929 protocols like SIP. 931 Legacy Next Generation Next Generation 932 Carrier Carrier Carrier 933 ******* *************** ************** 934 * * * * * * 935 SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG 936 * * (SS7) * (SIP) * (SIP) * (SIP) * 937 ******* *************** ************** 939 SW - Telco Switch 940 SG - Signaling Gateway 942 Figure 2 944 Given multiple IP domains, and the presumption that SLAs relating to 945 IEPS traffic may exist between them, the need for something like 946 diff-serv grows with respect to being able to distinguish the 947 emergency related traffic from other types of traffic. In addition, 948 IP security becomes more important between domains in order to ensure 949 that the act of distinguishing IEPS-type traffic is indeed valid for 950 the given source. 952 8. Security Considerations 954 Information on this topic is presented in sections 2 and 4. 956 9. References 958 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 959 9, RFC 2026, October 1996. 961 2 Braden, R., et. al., "Integrated Services in the Internet 962 Architecture: An Overview", Informational, RFC 1633, June 1994. 964 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) _ 965 Version 1, Functional Specification", Proposed Standard, RFC 966 2205, Sept. 1997. 968 4 Shenker, S., et. al., "Specification of Guaranteed Quality of 969 Service", Proposed Standard, RFC 2212, Sept 1997. 971 5 Wroclawski, J., "Specification for Controlled-Load Network 972 Service Element", Proposed Standard, RFC 2211, Sept 1997. 974 6 Gai, S., et. al., "RSVP Proxy", Internet Draft, Work in 975 Progress, July 2000. 977 7 Wang, L, et. al., "RSVP Refresh Overhead Reduction by State 978 Compression", Internet Draft, Work In Progress, March 2000. 980 8 Blake, S., et. al., "An Architecture for Differentiated 981 Service", Proposed Standard, RFC 2475, Dec. 1998. 983 9 Kankkunen, A., et. al., "VoIP over MPLS Framework", Internet 984 Draft, Work In Progress, July 2000. 986 10 Sharma, V., et. al., "Framework for MPLS-based Recovery", 987 Internet Draft, Work In Progress, September 2000. 989 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 990 August 1982. 992 12 Handley, M., et. al., "SIP: Session Initiation Protocol", 993 Proposed Standard, RFC 2543, March 1999. 995 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 996 Completion (HPC) Network Capability_, ANSI T1.631, 1993. 998 14 Reliable Audio Tool (RAT): 999 http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 1001 15 Polk, J., "SIP Extension for MLPP", Internet Draft, Work In 1002 Progress, March, 2001. 1004 16 Nichols, K., et. al.,"Definition of the Differentiated Services 1005 Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed 1006 Standard, RFC 2474, December 1998. 1008 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 1009 Proposed Standard, RFC 2748, Jan 2000. 1011 18 ITU, "International Emergency Preparedness Scheme", ITU 1012 Recommendation, E.106, March 2000. 1014 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 1015 Over IP", Informational, RFC 2871, June 2000 1017 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 1018 Standard, RFC 2597, June 1999 1020 21 Farrel, A, et. al, "Fault Tolerance for LDP and CR-LDP", Internet 1021 Draft, Work In Progress, February 2001. 1023 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Internet 1024 Draft, Work In Progress, April 2001. 1026 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 1027 Track, RFC 3015, November 2000 1029 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 1030 Standards Track, RFC 2198, September, 1997 1032 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 1033 Generic Forward Error Correction", Standards Track, RFC 2733, 1034 December, 1999. 1036 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 1037 2000. 1039 27 Brown, I., "Securing IEPS over IP", White Paper, 1040 http://iepscheme.net/docs/secure_IEPS.doc 1042 28 Folts, H., "Description of an International Emergency Preference 1043 Scheme (IEPS) ITU-T Recommendation E.106 (Formerly CCITT 1044 Recomendation), Internet Draft, Work In Progress, February 2001 1046 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 1047 Draft, Work In Progress, October 2001. 1049 10. Acknowledgments 1051 The authors would like to acknowledge the helpful comments, opinions, 1052 and clarifications of Stu Goldman and James Polk, as well as those 1053 comments received from the IEPS mailing list. 1055 11. Author's Addresses 1057 Ken Carlberg 1058 University College London 1059 Department of Computer Science 1060 Gower Street 1061 London, WC1E 6BT 1062 United Kingdom 1064 Ian Brown 1065 University College London 1066 Department of Computer Science 1067 Gower Street 1068 London, WC1E 6BT 1069 United Kingdom 1071 Full Copyright Statement 1073 "Copyright (C) The Internet Society (date). All Rights Reserved. 1074 This document and translations of it may be copied and furnished to 1075 others, and derivative works that comment on or otherwise explain it 1076 or assist in its implementation may be prepared, copied, published 1077 and distributed, in whole or in part, without restriction of any 1078 kind, provided that the above copyright notice and this paragraph are 1079 included on all such copies and derivative works. However, this 1080 document itself may not be modified in any way, such as by removing 1081 the copyright notice or references to the Internet Society or other 1082 Internet organizations, except as needed for the purpose of 1083 developing Internet standards in which case the procedures for 1084 copyrights defined in the Internet Standards process must be 1085 followed, or as required to translate it into languages other than 1086 English. 1088 The limited permissions granted above are perpetual and will not be 1089 revoked by the Internet Society or its successors or assigns. 1091 This document and the information contained herein is provided as an 1092 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1093 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1094 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1095 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 1096 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.