idnits 2.17.1 draft-ietf-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 25 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 26 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. 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 13 looks like a reference -- Missing reference section? '2' on line 83 looks like a reference -- Missing reference section? '3' on line 60 looks like a reference -- Missing reference section? '4' on line 62 looks like a reference -- Missing reference section? '5' on line 62 looks like a reference -- Missing reference section? '6' on line 72 looks like a reference -- Missing reference section? '7' on line 73 looks like a reference -- Missing reference section? '8' on line 80 looks like a reference -- Missing reference section? '9' on line 106 looks like a reference -- Missing reference section? '10' on line 467 looks like a reference -- Missing reference section? '11' on line 119 looks like a reference -- Missing reference section? '12' on line 119 looks like a reference -- Missing reference section? '30' on line 136 looks like a reference -- Missing reference section? '13' on line 162 looks like a reference -- Missing reference section? '18' on line 201 looks like a reference -- Missing reference section? '28' on line 203 looks like a reference -- Missing reference section? '14' on line 547 looks like a reference -- Missing reference section? '31' on line 234 looks like a reference -- Missing reference section? '32' on line 239 looks like a reference -- Missing reference section? '26' on line 356 looks like a reference -- Missing reference section? '15' on line 630 looks like a reference -- Missing reference section? '19' on line 476 looks like a reference -- Missing reference section? '22' on line 478 looks like a reference -- Missing reference section? '24' on line 545 looks like a reference -- Missing reference section? '25' on line 545 looks like a reference -- Missing reference section? '21' on line 605 looks like a reference -- Missing reference section? '34' on line 619 looks like a reference -- Missing reference section? '23' on line 774 looks like a reference -- Missing reference section? '16' on line 636 looks like a reference -- Missing reference section? '20' on line 698 looks like a reference -- Missing reference section? '29' on line 757 looks like a reference -- Missing reference section? '27' on line 764 looks like a reference -- Missing reference section? '17' on line 812 looks like a reference -- Missing reference section? '33' on line 833 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 36 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 February 21, 2002 UCL 6 Framework for Supporting IEPS 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 International 36 Emergency Preparedness Scheme (IEPS), should be realized within 37 today's IP architecture and service models. From these objectives, 38 we present a corresponding set of functional requirements, 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 1. Introduction 47 The Internet has become the primary target for worldwide communica- 48 tions. This is in terms of recreation, business, and various ima- 49 ginative reasons for information distribution. A constant fixture in 50 the evolution of the Internet has been the support of Best Effort as 51 the default service model. Best Effort, in general terms, infers 52 that the network will attempt to forward traffic to the destination 53 as best as it can with no guarantees being made, nor any resources 54 reserved, to support specific measures of Quality of Service (QoS). 55 An underlying goal is to be "fair" to all the traffic in terms of the 56 resources used to forward it to the destination. 58 In an attempt to go beyond best effort service, [2] presented an 59 overview of Integrated Services (int-serv) and its inclusion into the 60 Internet architecture. This was followed by [3], which specified the 61 RSVP signaling protocol used to convey QoS requirements. With the 62 addition of [4] and [5], specifying control load (bandwidth bounds) 63 and guaranteed service (bandwidth & delay bounds) respectively, a 64 design existed to achieve specific measures of QoS for an end-to-end 65 flow of traffic traversing an IP network. In this case, our refer- 66 ence to a flow is one that is granular in definition and applying to 67 specific application sessions. 69 From a deployment perspective (as of the date of this document), 70 int-serv has been predominantly constrained to stub intra-domain 71 paths, at best resembling isolated "island" reservations for specific 72 types of traffic (e.g., audio and video) by stub domains. [6] and 73 [7] will probably contribute to additional deployment of int-serv to 74 Internet Service Providers (ISP) and possibly some inter-domain 75 paths, but it seems unlikely that the original vision of end-to-end 76 int-serv between hosts in source and destination stub domains will 77 become a reality in the near future (the mid- to far-term is a sub- 78 ject for others to contemplate). 80 In 1998, the IETF produced [8], which presented an architecture for 81 Differentiated Services (diff-serv). This effort focused on a more 82 aggregated perspective and classification of packets than that of 83 [2]. This is accomplished with the recent specification of the 84 diff-serv field in the IP header (in the case of IPv4, it replaced 85 the old ToS field). This new field is used for code points esta- 86 blished by IANA, or set aside as experimental. It can be expected 87 that sets of microflows, a granular identification of a set of pack- 88 ets, will correspond to a given code point, thereby achieving an 89 aggregated treatment of data. 91 One constant in the introduction of new service models has been the 92 designation of Best Effort as the default service model. If traffic 93 is not, or cannot be, associated as diff-serv or int-serv, then it is 94 treated as Best Effort and uses what resources are made available to 95 it. 97 Beyond the introduction of new services, the continued pace of addi- 98 tional traffic load experienced by ISPs over the years has continued 99 to place a high importance for intra-domain traffic engineering. The 100 explosion of IETF contributions, in the form of drafts and RFCs pro- 101 duced in the area of Multi Protocol Label Switching (MPLS), exempli- 102 fies the interest in versatile and manageable mechanisms for intra- 103 domain traffic engineering. One interesting observation is the work 104 involved in supporting QoS related. Specifically, we refer to the 105 work in progress discussion of Proposed MPLS/DiffServ Traffic 106 Engineering Class Types [9], and the inclusion of fault tolerance 107 [10]. This latter item can be viewed as being similar to "crank- 108 back", a term used to describe the means by which the Public Switched 109 Telephone Network (PSTN) routes around congested switches. 111 1.1. Emergency Related Data 113 The evolution of the IP service model architecture has traditionally 114 centered on the type of application protocols used over a network. 115 By this we mean that the distinction, and possible bounds on QoS, 116 usually centers on the type of application (e.g., audio video tools) 117 that is being referred to. 119 While protocols like SMTP [11] and SIP [12] have embedded fields 120 denoting "priority", there has not been a previous IETF standards 121 based effort to state or define what this distinction means with 122 respect to the underlying network and how it should be supported. 123 Given the emergence of IP telephony, a natural inclusion of it as 124 part of a telco carriers backbone network, or into the Internet as a 125 whole, implies the ability to support existing emergency related ser- 126 vices. Typically, one associates emergency calls with "911" tele- 127 phone service in the U.S., or "999" in the U.K. -- both of which are 128 attributed to national boundaries and accessible by the general pub- 129 lic. Outside of this exists emergency telephone services that 130 involved authorized usage, as described in the following subsection. 132 1.1.1. Government Emergency Telecommunications Service (GETS) 134 GETS is an emergency telecommunications service available in the U.S. 135 and overseen by the National Communications System (NCS) -- an office 136 established by the White House under an executive order [30]. Unlike 137 "911", it is only accessible by authorized individuals. The majority 138 of these individuals are from various government agencies like the 139 Department of Transportation, NASA, the Department of Defense, and 140 the Federal Emergency Management Agency (to name but a few). In 141 addition, a select set of individuals from private industry (telecom- 142 munications companies, utilities, etc.) that are involved in criti- 143 cial infrastructure recovery operations are also provided access to 144 GETS. 146 The purpose of GETS is to increase the probability that phone service 147 will be available to selected government agency personnel in times of 148 emergencies, such as hurricanes, earthquakes, and other disasters 149 that may produce a burden in the form of call blocking (i.e., conges- 150 tion) on the U.S. Public Switched Telephone Network by the general 151 public. 153 The key aspect is that GETS only supports a probabilistic approach to 154 call completion, as opposed to call preemption. This distinction is 155 important because emergency systems like GETS are not allowed to ter- 156 minate existing calls in order to allow a GETS call to be esta- 157 blished. Thus, the mechanisms and specifications that comprise GETS 158 only focus on increasing the chances that a particular telephone call 159 will be established. 161 GETS is supported by Signaling System 7 (SS7) via the T1.631 protocol 162 on High Probability of Completion (HPC) network capability [13]. 163 This document describes the specification of a National Security and 164 Emergency Preparedness (NS/EP) Calling Party Category (CPC) code 165 point used for SS7 ISDN User Part (ISUP) Initial Address Message 166 (IAM). In the presense of this code point, Local Exchange Carriers 167 (LEC) will attempt (if necessary and if the option is supported) to 168 route the call through alternate inter-exchange carriers (IXC) if it 169 cannot complete the 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 ori- 179 ginated) attempts to establish the call through an IXC. This is done 180 even if the destination number is within the LEC itself. If the IXC 181 cannot forward the call to the destination LEC, then the source LEC 182 attempts to route the call through an alternate IXC. If alternate 183 IXCs cannot help establish the call, then a busy signal is finally 184 returned to the user. Otherwise, the call is completed and retains 185 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 (SLA) established 191 between the U.S. Government and various telco carriers to support 192 GETS. Thus, the default end-to-end service for establishing a GETS 193 call can be roughly viewed as best effort and associated with the 194 same priority as calls from the general public. 196 It should be noted from the above description that GETS is separate 197 and unrelated to other emergency services like "911". 199 1.1.2. International Emergency Preparedness Scheme (IEPS) 201 [18] is a recent ITU standard that describes emergency related com- 202 munications over international telephone service (Note, this document 203 has also been published as a draft-RFC in [28]). While systems like 204 GETS are national in scope, IEPS acts as an extension to local or 205 national authorized emergency call establishment and provides a 206 building block for a global service. 208 As in the case of GETS, IEPS promotes mechanisms like extended queu- 209 ing, alternate routing, and exemption from restrictive management 210 controls in order to increase the probability that international 211 emergency calls will be established. The specifics of how this is to 212 be accomplished are to be defined in future ITU document(s). 214 1.2. Scope of this Document 216 The scope of this document centers on the near and mid-term support 217 of IEPS within the context of IP telephony, though not necessarily 218 Voice over IP. We make a distinction between these two by treating 219 IP telephony as a subset of VoIP, where in the former case we assume 220 some form of application layer signaling is used to explicitly estab- 221 lish and maintain voice data traffic. This explicit signaling capa- 222 bility provides the hooks from which VoIP traffic can be bridged to 223 the PSTN. 225 An example of this distinction is when the Redundant Audio Tool (RAT) 226 [14] begins sending VoIP packets to a unicast (or multicast) destina- 227 tion. RAT does not use explicit signaling like SIP to establish an 228 end-to-end call between two users. It simply sends data packets to 229 the target destination. On the other hand, "SIP phones" are host 230 devices that use a signaling protocol to establish a call signal 231 before sending data towards the destination. 233 One other aspect we should probably assume exists with IP Telephony 234 is an association of a target level of QoS per session or flow. [31] 235 makes an arguement that there is a maximum packet loss and delay for 236 VoIP traffic, and both are interdependent. For delays of ~200ms, a 237 corresponding drop rate of 5% is deemed acceptable. When delay is 238 lower, a 15-20% drop rate can be experienced and still considered 239 acceptable. [32] discusses the same topic and makes an arguement 240 that packet size plays a significant role in what users tolerate as 241 "intelligible" VoIP. The larger the packet, correlating to longer 242 sampling rate, the lower the acceptable rate of loss. 244 Regardless of a definitive drop rate, it would seem that interactive 245 voice has a lower threshold of loss than other elastic applications. 246 This places a harder burden on the problem space of supporting VoIP 247 over the Internet. This problem is also further compounded when 248 toll-quality service is expected because it assumes a default service 249 model that is better than best effort. This in turn can increase the 250 probability that a form of call-blocking can occur with VoIP or IP 251 telephony traffic. 253 Beyond this, part of our motivation in writing this document is to 254 provide a framework for ISPs and carriers so that they have an under- 255 standing of objectives and accompanying functional requirements used 256 to support IEPS related IP telephony traffic. In addition, we also 257 wish to provide a reference point for potential customers (users of 258 IEPS) in order to constrain their expectations. In particular, we 259 wish to avoid any temptation of trying to replicate the exact capa- 260 bilities of existing emergency voice service currently available in 261 the PSTN to that of IP and the Internet. If nothing else, intrinsic 262 differences between the two communications architectures precludes 263 this from happening. Note, this does not prevent us from borrowing 264 design concepts or objectives from existing systems. 266 Section 2 presents several primary objectives that articulate what is 267 considered important in supporting IEPS related IP telephony traffic. 268 These objectives represent a generic set of goals and capabilities 269 attributed to supporting IEPS based IP telephony. Section 3 presents 270 additional value added objectives. These are capabilities that are 271 viewed as useful, but not critical in support of IEPS. Section 4 272 presents a series of functional requirements that stem from the 273 objectives articulated in section 2. Finally, Section 5 presents two 274 scenarios in IEPS that currently exist or are being deployed in the 275 near term over IP networks. These are not all-inclusive scenarios, 276 nor are they the only ones that can be articulated. However, they do 277 show cases where some of the functional requirements apply, and where 278 some do not. 280 Finally, we need to state that this document focuses its attention on 281 the IP layer and above. Specific operational procedures pertaining 282 to Network Operation Centers (NOC) or Network Information Centers 283 (NIC) are outside the scope of this document. This includes the 284 "bits" below IP, other specific technologies, and service level 285 agreements between ISPs and carriers with regard to dedicated links. 287 2. Objective 289 The support of IEPS within IP telephony can be realized in the form 290 of several primary objectives. These objectives define the generic 291 functions or capabilities associated with IEPS, and the scope of the 292 support needed to achieve these capabilities. From this generic set 293 of objectives, we present specific functional requirements of exist- 294 ing IP protocols (presented below in section 3). 296 There are two underlying goals in the selection of these objectives. 297 One goal is to produce a design that maximizes the use of existing IP 298 protocols and minimizes the set of additional specifications needed 299 to support IP-telephony based IEPS. Thus, with the inclusion of 300 these minimal augmentations, the bulk of the work in achieving IEPS 301 over an IP network that is connected or unconnected to the Internet 302 involves operational issues. Examples of this would be the estab- 303 lishment of Service Level Agreements (SLA) with ISPs, and/or the pro- 304 visioning of traffic engineered paths for IEPS-related telephony 305 traffic. 307 A second underlying goal in selecting the following objectives is to 308 take into account experiences from an existing emergency-type commun- 309 ication system (as described in section 1.1.1) as well as the exist- 310 ing restrictions and constraints placed by some countries. In the 311 former case, we do not attempt to mimic the system, but rather 312 extract information as a reference model. With respect to con- 313 straints based on laws or agency regulations, this would normally be 314 considered outside of the scope of any IETF document. However, these 315 constraints act as a means of determining the lowest common denomina- 316 tor in specifying technical functional requirements. If such con- 317 straints do not exist, then additional functions can be added to the 318 baseline set of functions. This last item will be expanded upon in 319 the description of Objective #3 below. 321 The following list of objectives are termed primary because they per- 322 tain to that which defines the underlying goals of IEPS. However, 323 the primary objectives are not meant to dictate major overhauls of 324 existing IP protocols, nor do they require completely new protocols 325 to be developed. 327 Primary Objectives in support of authorized emergency calls: 329 1) High Probability of Call Completion 330 2) Interaction with PSTN 331 3) Distinction of IEPS data traffic 332 4) Non-preemptive action 333 5) Non-ubiquitous support 334 6) Authenticated service 336 The first objective is the crux of our work because it defines our 337 expectations for both data and call signaling for IP telephony. As 338 stated, our objective is achieving a high probability that emergency 339 related calls (both data and signaling) will be forwarded through an 340 IP network. Specifically, we envision the relevance of this objec- 341 tive during times of congestion, the context of which we describe 342 further below in this section. The critical word in this objective 343 is "probability", as opposed to assurance or guarantee -- the latter 344 two placing a higher burden on the network. It stands to reason, 345 though, that the word "probability" is a less tangible description 346 that cannot be easily quantified. It is relative in relation to 347 other traffic transiting the same network. Objectives 4 and 5 listed 348 above help us to qualify the term probability in the context of other 349 objectives. 351 The second objective involves the interaction of IP telephony signal- 352 ing with existing PSTN support for emergency related voice communica- 353 tions. As mentioned above in Section 1.2, standard T1.631 [26] 354 specifies emergency code points for SS7. Specifically, the National 355 Security and Emergency Preparedness (NS/EP) Calling Party Category 356 code point is defined for ISUP IAM messages used by SS7 [26]. Hence, 357 our objective in the interaction between the PSTN and IP telephony 358 with respect to IEPS (and national indicators) is a direct mapping 359 between related code points. 361 The third objective focuses on the ability to distinguish IEPS data 362 packets from other types of VoIP packets. With such an ability, 363 transit providers can more easily ensure that service level agree- 364 ments relating to IEPS are adhered to. Note that we do not assume 365 that the actions taken to distinguish IEPS type packets is easy. 366 Nor, in this section, do we state the form of this distinction. We 367 simply present the objective of identifying flows that relate to IEPS 368 versus others that traverse a transit network. 370 At an abstract level, the forth objective pertains to the actions 371 taken when an IP telephony call, via a signaling protocol such as 372 SIP, cannot be forwarded because the network is experiencing a form 373 of congestion. We state this in general terms because of two rea- 374 sons: a) there may exist applications other than SIP, like H.248, 375 used for call establishment, and b) congestion may come in several 376 forms. For example, congestion may exist at the IP packet layer with 377 respect to queues being filled to their configured limit. Congestion 378 may also arise from resource allocation (i.e., QoS) attributed per 379 call or aggregated sets of calls. In this latter case, while there 380 may exist resources to forward the packets, a signaling server may 381 have reached its limit as to how many telephony calls it will support 382 while retaining toll-quality service per call. Typically, one terms 383 this form of congestion as call blocking. Note that we do not 384 address the case when congestion occurs at the bit level below that 385 of IP, due to the position that it is outside the scope of IP and the 386 IETF. 388 So, given the existence of congestion in its various forms, our 389 objective is to support IEPS-related IP telephony call signaling and 390 data traffic via non-preemptive actions taken by the network. More 391 specifically, we associate this objective in the context of IP 392 telephony acting as part of the Public Telephone Network (PTN). 393 This, as opposed to the use of IP telephony within a private or stub 394 network. In section 5 below, we expand on this through the descrip- 395 tion of two distinct scenarios of IP telephony and its operation with 396 IEPS and the PSTN. 398 It is important to mention that this is a default objective influ- 399 enced by existing laws & regulations. Those countries not bound by 400 these restrictions can remove this objective and make provisions to 401 enforce preemptive action. In this case, it would probably be advan- 402 tageous to deploy a signaling system similar to that proposed in 403 [15], wherein multiple levels of priority are defined and preemption 404 via admission control from SIP servers is enforced. 406 The fifth objective stipulates that we do not advocate the need or 407 expectation for ubiquitous support of IEPS across all administrative 408 domains of the Internet. While it would be desirable to have ubiqui- 409 tous support, we feel the reliance of such a requirement would doom 410 even the contemplation of supporting IEPS by the IETF and the 411 expected entities (e.g., ISPs and vendors) involved in its deploy- 412 ment. 414 We use the existing GETS service in the U.S. as an existing example 415 in which emergency related communications does not need to be ubiqui- 416 tous. As mentioned previously, the measure and amount of support 417 provided by the U.S. PSTN for GETS does bot exist for all U.S. IXCs 418 nor LECs. Given the fact that GETS still works within this context, 419 it is our objective to follow this deployment model such that we can 420 accomplish the first objective listed above -- a higher probability 421 of call completion than that of normal IP telephony call traffic. 423 Our final objective is that only authorized users may use the ser- 424 vices outlined in this framework. GETS users are authenticated using 425 a PIN provided to the telecommunications carrier, which signals 426 approval back to the user's local exchange over SS7. In an IP net- 427 work, the authentication center will need to securely signal back to 428 the IP ingress point that a given user is authorized to send IEPS 429 related flows. Similarly, transit networks with IEPS SLAs must 430 securely interchange authorized IEPS traffic. In both cases, IPSec 431 authentication transforms may be used to protect this traffic. This 432 is entirely separate from end-to-end IPSec protection of user 433 traffic, which will be configured by users. IP-PSTN gateways must 434 also be able to securely signal IEPS authorization for a given flow. 435 As these gateways are likely to act as SIP servers, we further con- 436 sider the use of SIP's security functions to aid this objective. 438 3. Value Added Objective 440 This objective is viewed as being helpful in achieving a high proba- 441 bility of call completion. Its realization within an IP network 442 would be in the form of new protocols or enhancements to existing 443 ones. Thus, objectives listed in this section are treated as value 444 added -- an expectation that their existence would be beneficial, and 445 yet not viewed as critical to support IEPS related IP telephony 446 traffic. 448 3.1. Alternate Path Routing 450 This objective involves the ability to discover and use a different 451 path to route IP telephony traffic around congestion points and thus 452 avoid them. Ideally, the discovery process would be accomplished in 453 an expedient manner (possibly even a priori to the need of its 454 existence). At this level, we make no requirements as to how the 455 alternate path is accomplished, or even at which layer it is achieved 456 -- e.g., the network versus the application layer. But this kind of 457 capability, at least in a minimal form, would help contribute to 458 increasing the probability of call completion of IEPS traffic by mak- 459 ing use of noncongested alternate paths. We use the term "minimal 460 form" to concede the fact that care must be taken in how the system 461 provides alternate paths so it does not significantly contribute to 462 the congestion that is to be avoided (e.g., via excess 463 control/discovery messages). 465 At the time that this document was written, we can identify two 466 work-in-progress areas in the IETF that can be helpful in providing 467 alternate paths for call signaling. The first is [10], which is 468 focused on network layer routing and describes enhancements to the 469 LDP specification of MPLS to help achieve fault tolerance. This in 470 itself does not provide alternate path routing, but rather helps 471 minimize loss in intradomain connectivity when MPLS is used within a 472 domain. 474 The second effort comes from the IP Telephony working group and 475 involves Telephony Routing over IP (TRIP). To date, a framework 476 document [19] has been published as an RFC which describes the 477 discovery and exchange of IP telephony gateway routing tables between 478 providers. The TRIP protocol [22], a supplemental work in progress, 479 specifies application level telephony routing regardless of the sig- 480 naling protocol being used (e.g., SIP or H.323). TRIP is modeled 481 after BGP-4 and advertises reachability and attributes of destina- 482 tions. In its current form, several attributes have already been 483 defined, such as LocalPreference and MultiExitDisc. Upon standardi- 484 zation of TRIP, additional attributes can be registered with IANA. 485 Initially, we would recommend two additional attributes that would 486 relate to emergency related flows. These being: 488 EmergencyMultiExitDisc 490 The EmergencyMultiExitDisc attribute is similar to the 491 MultiExitDisc in that it is an inter-domain attribute used 492 to express a preference of one or more links over others 493 between domains. Unlike the MultiExitDisc, this attribute 494 specifically identifies links that are preferred for emergency 495 related calls that span domains. 497 EmergencyLocalPreference 499 The EmergencyLocalPreference attribute is similar to the 500 LocalPreference in that it is an intra-domain attribute used 501 to inform other LSs of the local LSs preference for a given 502 route. The difference between the two types attributes is 503 that the preferred route specifically relates to emergency-type 504 calls (e.g., 911). This attribute has no significance between 505 domains. Local policy determines if there is an association 506 between the EmergencyLocalPreference and the 507 EmergencyMultiExitDisc attribute. 509 3.2. End-to-End Fault Tolerance 511 This topic involves the work that has been done in trying to compen- 512 sate for lossy networks providing best effort service. In particu- 513 lar, we focus on the use of a) Forward Error Correction (FEC), and b) 514 redundant transmissions that can be used to compensate for lost data 515 packets. (Note that our aim is fault tolerance, as opposed to an 516 expectation of always achieving it). 518 In the former case, additional FEC data packets are constructed from 519 a set of original data packets and inserted into the end-to-end 520 stream. Depending on the algorithm used, these FEC packets can 521 reconstruct one or more of the original set that were lost by the 522 network. An example may be in the form of a 10:3 ratio, in which 10 523 original packets are used to generate three additional FEC packets. 524 Thus, if the network loses 30% or less number of packets, then the 525 FEC scheme will be able to compensate for that loss. The drawback to 526 this approach is that to compensate for the loss, a steady state 527 increase in offered load has been injected into the network. This 528 makes an arguement that the act of protection against loss has con- 529 tributed to additional pressures leading to congestion, which in turn 530 helps trigger packet loss. In addition, in using a ratio of 10:3, 531 the source (or some proxy) must "hold" all 10 packets in order to 532 construct the three FEC packets. This contributes to the end-to-end 533 delay of the packets as well as minor bursts of load in addition to 534 changes in jitter. 536 The other form of fault tolerance we discuss involves the use of 537 redundant transmissions. By this we mean the case in which an origi- 538 nal data packet is followed by one or more redundant packets. At 539 first glance, this would appear to be even less friendly to the net- 540 work than that of adding FEC packets. However, the encodings of the 541 redundant packets can be of a different type (or even transcoded into 542 a lower quality) that produce redundant data packets that are signi- 543 ficantly smaller than the original packet. 545 Two RFCs [24, 25] have been produced that define RTP payloads for FEC 546 and redundant audio data. An implementation example of a redundant 547 audio application can be found in [14]. We note that both FEC and 548 redundant transmissions can be viewed as rather specific and to a 549 degree tangential solutions regarding packet loss and emergency com- 550 munications. Hence, these topics are placed under the category of 551 value added objectives. 553 4. Functional Requirements 555 In this section, we take the objectives presented above and specify a 556 corresponding set of functional requirements to achieve them. Given 557 that the objectives are predominantly atomic in nature, the 558 corresponding functional requirements are to be viewed separately 559 with no specific dependency upon each other as a whole. They may be 560 complimentary with each other, but there is no need for all to exist 561 given different scenarios of operation, and that IEPS support is not 562 viewed as a ubiquitously available service. We divide the functional 563 requirements into 4 areas: 565 1) Signaling 566 2) Policy 567 3) Traffic Engineering 568 4) Security 570 4.1. Signaling 572 Signaling is used to convey various information to either intermedi- 573 ate nodes or end nodes. It can be out-of-band of a data flow, and 574 thus in a separate flow of its own, such as SIP messages. It can be 575 in-band and part of the datagram containing the voice data. This 576 latter example could be realized in the form of diff-serv code points 577 in the IP packet, and/or in an extension to the RTP header denoting 578 an additional classification of the payload -- the latter predom- 579 inantly being used on an end-to-end basis. 581 In the following subsections, we discuss augmentations to three 582 specific types of signaling to help support the distinction of emer- 583 gency related communications in general, and IEPS specifically. We 584 also discuss Media Gateway Control (MEGACO). 586 4.1.1. SIP 588 With respect to application level signaling for IP telephony, we 589 focus our attention to the Session Initiation Protocol (SIP). 590 Currently, SIP has an existing "priority" field in the Request- 591 Header-Field that distinguishes different types of sessions. The 592 five currently defined values are: "emergency", "urgent", "normal", 593 "non-urgent", "other-priority". These values are meant to convey 594 importance to the end-user and have no additional sematics associated 595 with them. 597 [15] is a work in progress that defines a new header field for SIP 598 known as the Resource Priority Header. This new header field is 599 meant to provide an additional measure of distinction that can influ- 600 ence the behavior of gateways and SIP proxies. The structure of the 601 field is in the form of a NameSpace.Priority. The "NameSpace" pro- 602 vides a reference point by which the "Priority" values correspond to. 603 In the example of the Defence Switched Network (DSN) namespace, six 604 ordered priority values correlating to Multi-Level Priority & Prefer- 605 ence (MLPP) [21] are defined. Each of the defined values for the DSN 606 NameSpace have a specific relation or priority to each other. How- 607 ever, the specific actions enacted on the value, and their relation- 608 ship to other NameSpaces are subject to policies and SLAs. We expand 609 on the subject of policies below in section 4.2. 611 Additional namespaces and value(s) would be registered with IANA. It 612 would be our intention to follow the approach taken in [15] and 613 register a new namespace attributed to IEPS. Unlike [15], we would 614 define a single value (e.g., "authorized-emergency") that would 615 correspond to the NS/EP code point of SS7. This will help facilitate 616 a seamless interaction between the PSTN and the an IP network acting 617 as either an internal backbone or as a peering ISP. 619 Author's Note #1: The work put forth by Polk in [34], which describes 620 an architecture for MLPP, is similar to the subject of IEPS in the 621 sense that both aim at distinguishing certain VoIP flows from others. 622 However, MLPP and IEPS are not the same efforts. One critical 623 difference is that MLPP involves the use of preemption, while the 624 default model for IEPS is simply an increase in the probability of 625 call completion. 627 Author's Note #2: The term "Priority" has been a subject of strong 628 debate. In this document, we reference the term based on the termi- 629 nology inherited from other drafts and documents, such as can be 630 found in [15], and the Megaco RFC [23]. However, our focus is aimed 631 at using the "priority" value as simply a label by which we distin- 632 guish one set of flows from another. 634 4.1.2. Diff-Serv 636 In accordance with [16], the differentiated services code point 637 (DSCP) field is divided into three sets of values. The first set is 638 assigned by IANA. Within this set, there are currently, three types 639 of Per Hop Behaviors that have been specified: Default (correlating 640 to best effort forwarding), Assured Forwarding, and Expedited For- 641 warding. The second set of DSCP values are set aside for local or 642 experimental use. The third set of DSCP values are also set aside 643 for local or experimental use, but may later be reassigned to IANA in 644 case the first set has been completely assigned. 646 One candidate recomendation involves the specification of a new type 647 of Per-Hop Behavior (PHB) we term Emergency Related Forwarding (ERF). 648 This would provide a specific means of distinguishing emergency 649 related traffic (signaling and user data) from other traffic. The 650 existence of this PHB then provides a baseline by which specific code 651 points may be defined related to various emergency related traffic: 652 authorized emergency sessions (e.g., IEPS), general public emergency 653 calls (e.g., "911"), MLPP. Aggregates would still exist with respect 654 to the bundling of applications per code point. Further, one would 655 associate a forwarding paradigm aimed at a low loss rate reflective 656 of the code point selected. Hence, SIP or H.323 messages marked with 657 "authorized-emergency" or "emergency" may be assigned a code point 658 reflecting a lower loss rate than other type of traffic (even the 659 emergency-related data flow itself). The jitter associated with 660 application layer signaling of IP telephony would be inversely impor- 661 tant with respect to loss rate, and thus would be reflective of the 662 code points defined for the proposed PHB. 664 A potential issue that could be addressed by a new PHB involves merge 665 points of flows within a diff-serv domain. With EF, one can expect 666 admission control being performed at the edges of the domain. 667 Presumably, careful traffic engineering would be applied to avoid 668 congestion of EF queues at internal/core merge points steming from 669 flows originating from different ingress nodes of the diff-serv 670 domain. However, traffic engineering may not be able to compensate 671 for congestion of EF-type traffic at the domain's core routers. 672 Hence, a new PHB that has more than one code point to identify EF- 673 type traffic may address congestion by associating a drop precedence 674 for certain types of EF-type datagrams. Note that local policy and 675 SLAs would define which EF-type of traffic, if any, would be associ- 676 ated with a specific drop precedence. 678 Another candidate recomendation would be to define a new or fifth 679 class for the existing AF PHB. Unlike the other currently defined 680 classes, this new one would be based on five levels of drop pre- 681 cedence. This increase in the number of levels would conveniently 682 correlate to the worst case scenario posed by MLPP, which has five 683 types of priorities. In addition, it would provide a higher level of 684 variance that could be used to supercede the existing 3 levels used 685 in the other classes. Hence, if other non-emergency aggregate 686 traffic where assigned to the class, the highest drop precedence they 687 are assigned to is (3) -- corresponding to the other four currently 688 defined classes. Emergency traffic would be set to (4) or (5), 689 depending on the SLA tht has been defined. 691 It is important to note that as of the time that this document was 692 written, the IETF is taking a conservative approach in specifying new 693 PHBs. This is because the number of code points that can be defined 694 is relatively small, and thus understandably considered a scarce 695 resource. Therefore, the possibility of a new PHB being defined for 696 emergency related traffic is at best a long term project that may or 697 may not be accepted by the IETF. In the near term, we would ini- 698 tially recommend using the Assured Forwarding (AF) PHB [20] for dis- 699 tinguishing emergency traffic from other types of flows. At a 700 minimum, AF would be used for the different SIP call signaling mes- 701 sages. If EF was also supported by the domain, then it would be used 702 for IP telephony data packets. Otherwise, another AF class would be 703 used for those data flows. 705 It is critical to note that one cannot specify an exact code point 706 used for emergency related data flows because the relevance of a code 707 point is local to the given diff-serv domain (i.e., they are not glo- 708 bally unique per micro-flow or aggregate of flows). In addition, we 709 can expect that the existence of a codepoint for emergency related 710 flows is based on the service level agreements established with a 711 given diff-serv domain. 713 4.1.3. RTP 715 The Real-Time Transport Protocol (RTP) provides end-to-end delivery 716 services for data with real-time characteristics. The type of data 717 is generally in the form of audio or video type applications, and are 718 frequently interactive in nature. RTP is typically run over UDP and 719 has been designed with a fixed header that identifies a specific type 720 of payload -- typically representing a specific form of application 721 media. The designers of RTP also assumed an underlying network pro- 722 viding best effort service. As such, RTP does not provide any 723 mechanism to ensure timely delivery or provide other QoS guarantees. 724 However, the emergence of applications like IP telephony, as well as 725 new service models, presents new environments where RTP traffic may 726 be forwarded over networks that support better than best effort ser- 727 vice. Hence, the original scope and target environment for RTP has 728 expanded to include networks providing services other than best 729 effort. 731 In 4.1.2, we discussed one means of marking a data packet for emer- 732 gencies under the context of the diff-serv architecture. However, we 733 also pointed out that diff-serv markings for specific PHBs are not 734 globally unique, and may be arbitrarily removed or even changed by 735 intermediary nodes or domains. Hence, with respect to emergency 736 related data packets, we are still missing an in-band marking in a 737 data packet that stays constant on an end-to-end basis. 739 We have three choices in defining a persistent marking of data pack- 740 ets and thus avoid the transitory marking of diff-serv code points. 741 We can propose a new PHB dedicated for emergency type traffic as dis- 742 cussed in 4.1.2. We can propose a specification of a new shim layer 743 protocol at some location above IP. Or, we can add a new specifica- 744 tion to an existing upper layer protocol. The first two cases are 745 probably the "cleanest" architecturally, but they are long term 746 efforts that will take time to support in terms of design and imple- 747 mentation. It also may be argued that yet another shim layer will 748 make the IP stack too large. The third case, placing a marking in an 749 application layer packet, has the potential to be more appealing 750 depending on where the augmentation is targeted. 752 An approach in realizing this third case involves an augmentation to 753 RTP so that it can carry a marking that distinguishes emergency- 754 related traffic from that which is not. Specifically, one would 755 define a new extention that contains a "classifier" field indicating 756 the condition associated with the packet (e.g., authorized-emergency, 757 emergency, normal) [29]. 759 An issue in defining a new extension to RTP is that its presence may 760 adversely affect header compression for those implementations that 761 are not expecting added optional octets in RTP packets. In addition, 762 the issue of security and authentication of such a marking remains an 763 important issue and is subject to the constraints discussed below in 764 section 4.4, and in more detail in [27]. 766 4.1.4. MEGACO/H.248 768 The Media Gateway Control protocol (MEGACO) [23] defines the interac- 769 tion between a media gateway and a media gateway controller. [23] is 770 viewed as common text with ITU-T Recommendation H.248 and is a result 771 of applying the changes of RFC 2886 (Megaco Errata) to the text of 772 RFC 2885 (Megaco Protocol version 0.8). 774 In [23], the protocol specifies a Priority and Emergency field for a 775 context attribute and descriptor. The Emergency is an optional 776 boolean (True or False) condition. The Priority value, which ranges 777 from 0 through 15, specifies the precedence handling for a context. 779 The protocol does not specify individual values for priority. We 780 also do not recommend the definition of a well known value for the 781 MEGAGO priority. Any values set should be a function of any SLAs 782 that have been established regarding the handling of emergency 783 traffic. In addition, given that priority values denote precedence 784 (according to the Megaco protocol), then by default the IEPS data 785 flows should probably receive the same priority as other non- 786 emergency calls. This approach follows the objective of not relying 787 on preemption as the default treatment of emergency-related. 789 4.2. Policy 791 One of the objectives listed in section 3 above is to treat IEPS- 792 signaling, and related data traffic, as non-preemptive in nature. 793 Further, that this treatment is to be the default mode of operation 794 or service. This is in recognition that existing regulations or laws 795 of certain countries governing the establishment of SLAs may not 796 allow preemptive actions (e.g., dropping existing telephony flows). 797 On the other hand, the laws and regulations of other countries 798 influencing the specification of SLA(s) may allow preemption, or even 799 require its existence. Given this disparity, we rely on local policy 800 to determine the degree by which emergency related traffic affects 801 existing traffic load of a given network or ISP. Important note: we 802 reiterate our earlier comment that laws and regulations are generally 803 outside the scope of the IETF and its specification of designs and 804 protocols. However, these constraints can be used as a guide in pro- 805 ducing a baseline function to be supported; in our case, a default 806 policy for non-preemptive call establishment of IEPS signaling and 807 data. 809 Policy can be in the form of static information embedded in various 810 components (e.g., SIP servers or bandwidth brokers), or it can be 811 realized and supported via COPS with respect to allocation of a 812 domain's resources [17]. There is no requirement as to how policy is 813 accomplished. Instead, if a domain follows actions outside of the 814 default non-preemptive action of IEPS-related communication, then we 815 stipulate a functional requirement that some type of policy mechanism 816 is in place to satisfy the local policies of an SLA established for 817 IEPS type traffic. 819 4.3. Traffic Engineering 821 In those cases where a network operates under the constraints of 822 SLAs, one or more of which pertains to IEPS based traffic, it can be 823 expected that some form of traffic engineering is applied to the 824 operation of the network. We make no requirements as to which type 825 of traffic engineering mechanism is used, but that such a system 826 exists and can distinguish and support IEPS signaling and data 827 traffic. 829 MPLS is generally the first protocol that comes to mind when the sub- 830 ject of traffic engineering is brought up. This notion is hightened 831 concerning the subject of IP telephony because of MPLS's ability to 832 to permit a quasi circuit switching capability to be superimposed on 833 the current Internet routing model [33]. 835 However, having cited MPLS, we need to stress that it is an intra- 836 domain protocol, and so may or may not exist within a given ISP. 837 Other forms of traffic engineering, such as weighted OSPF, may be the 838 mechanism of choice by an ISP. 840 Note: As a point of reference, existing SLAs established by the NCS 841 for GETS service tend to focus on a maximum allocation of (e.g., 1%) 842 of calls allowed to be established through a given LEC using HPC. 843 Once this limit is reached, all other GETS calls experience the same 844 probably of call completion as the general public. It is expected, 845 and encouraged, that IEPS related SLAs will have a limit with respect 846 to the amount of traffic distinguished as being emergency related, 847 and initiated by an authorized user. 849 4.4. Security 851 As IEPS support moves from intra-domain PSTN and IP networks to dif- 852 fuse inter-domain pure IP, authenticated service becomes more complex 853 to provide. Where an IEPS call is carried from PSTN to PSTN via one 854 carrier's backbone IP network, very little IP-specific security sup- 855 port is required. The user authenticates herself as usual to the 856 network using a PIN. The gateway from her PSTN connection into the 857 backbone IP network must be able to signal that the flow has IEPS 858 priority. Conversely, the gateway back into the PSTN must similarly 859 signal the call's higher priority. A secure link between the gateways 860 may be set up using IPSec or SIP security functionality. If the end- 861 point is an IP device on the carrier's network, the link may be set 862 up securely from the ingress gateway to the end device. 864 As flows traverse more than one IP network, domains whose peering 865 agreements include IEPS support must have means to securely signal a 866 given flow's IEPS status. They may choose to use physical link secu- 867 rity and/or IPSec authentication, combined with traffic conditioning 868 measures to limit the amount of IEPS traffic that may pass between 869 the two domains. The inter-domain agreement may require the originat- 870 ing network to take responsibility for ensuring only authorized 871 traffic is marked with IEPS priority; the downstream domain may still 872 perform redundant conditioning to prevent the propagation of theft 873 and denial of service attacks. Security may be provided between 874 ingress and egress gateways or IP endpoints using IPSec or SIP secu- 875 rity functions. 877 When a call originates from an IP device, the ingress network may 878 authorize IEPS traffic over that link as part of its user authentica- 879 tion procedures without necessarily communicating with a central IEPS 880 authentication center as happens with POTS-originated calls. These 881 authentication procedures may occur at the link or network layers, 882 but are entirely at the discretion of the ingress network. That net- 883 work must decide how often it should update its list of authorized 884 IEPS users based on the bounds it is prepared to accept on traffic 885 from recently-revoked users. 887 5. Key Scenarios 889 There are various scenarios in which IP telephony can be realized, 890 each of which can infer a unique set of functional requirements that 891 may include just a subset of those listed above. We acknowledge that 892 a scenario may exist whose functional requirements are not listed 893 above. Our intention is not to consider every possible scenario by 894 which support for emergency related IP telephony can be realized. 895 Rather, we narrow our scope using a single guideline; we assume there 896 is a signaling & data interaction between the PSTN and the IP network 897 with respect to supporting emergency-related telephony traffic. We 898 stress that this does not preclude an IP-only end-to-end model, but 899 rather the inclusion of the PSTN expands the problem space and 900 includes the current dominant form of voice communication. 902 There are two scenarios that we use as a model for determining our 903 objectives and subsequent functional requirements. These are: 905 Single IP Administrative Domain 906 ------------------------------- 908 This scenario is a direct reflection of the evolution of the PSTN. 909 Specifically, we refer to the case in which data networks have 910 emerged in various degrees as a backbone infrastructure connecting 911 PSTN switches at its edges. This represents a single isolated IP 912 administrative domain that has no directly adjacent IP domains con- 913 nected to it. We show an example of this scenario below in Figure 1. 914 In this example, we show two types of carriers. One is the legacy 915 carrier, whose infrastructure retains the classic switching architec- 916 ture attributed to the PSTN. The other is the next generation car- 917 rier, which uses a data network (e.g., IP) as its core infrastruc- 918 ture, and Signaling Gateways at its edges. These gateways "speak" 919 SS7 externally with peering carriers, and another protocol (e.g., 920 SIP) internally, which rides on top of the IP infrastructure. 922 Legacy Next Generation Next Generation 923 Carrier Carrier Carrier 924 ******* *************** ************** 925 * * * * ISUP * * 926 SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG 927 * * (SS7) * (SIP) * (SS7) * (SIP) * 928 ******* *************** ************** 930 SW - Telco Switch 931 SG - Signaling Gateway 933 Figure 1 935 The significant aspect of this scenario is that all the resources of 936 each IP "island" fall within a given administrative authority. 937 Hence, there is not a problem of retaining toll quality Grade of Ser- 938 vice as the voice traffic (data and signaling) exits the IP network 939 because of the existing SS7 provisioned service between carriers. 940 Thus, the need for support of mechanisms like diff-serv, and an 941 expansion of the defined set of Per-Hop Behaviors is reduced (if not 942 eliminated) under this scenario. 944 Another function that has little or no importance within the closed 945 IP environment of Figure 1 is that of IP security. The fact that 946 each administrative domain peers with each other as part of the PSTN, 947 means that existing security, in the form of Personal Identification 948 Number (PIN) authentication (under the context of telephony infras- 949 tructure protection), is the default scope of security. We do not 950 claim that the reliance on a PIN based security system is highly 951 secure or even desirable. But, we use this system as a default 952 mechanism in order to avoid placing additional requirements on exist- 953 ing authorized emergency telephony systems. 955 Multiple IP Administrative Domains 956 ---------------------------------- 958 We view the scenario of multiple IP administrative domains as a 959 superset of the previous scenario. Specifically, we retain the 960 notion that the IP telephony system peers with the existing PSTN. In 961 addition, segments (i.e., portions of the Internet) may exchange sig- 962 naling with other IP administrative domains via non-PSTN signaling 963 protocols like SIP. 965 Legacy Next Generation Next Generation 966 Carrier Carrier Carrier 967 ******* *************** ************** 968 * * * * * * 969 SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG 970 * * (SS7) * (SIP) * (SIP) * (SIP) * 971 ******* *************** ************** 973 SW - Telco Switch 974 SG - Signaling Gateway 976 Figure 2 978 Given multiple IP domains, and the presumption that SLAs relating to 979 IEPS traffic may exist between them, the need for something like 980 diff-serv grows with respect to being able to distinguish the emer- 981 gency related traffic from other types of traffic. In addition, IP 982 security becomes more important between domains in order to ensure 983 that the act of distinguishing IEPS-type traffic is indeed valid for 984 the given source. 986 6. Security Considerations 988 Information on this topic is presented in sections 2 and 4. 990 7. References 992 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 993 9, RFC 2026, October 1996. 995 2 Braden, R., et. al., "Integrated Services in the Internet 996 Architecture: An Overview", Informational, RFC 1633, June 1994. 998 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 999 Version 1, Functional Specification", Proposed Standard, RFC 1000 2205, Sept. 1997. 1002 4 Shenker, S., et. al., "Specification of Guaranteed Quality of 1003 Service", Proposed Standard, RFC 2212, Sept 1997. 1005 5 Wroclawski, J., "Specification for Controlled-Load Network 1006 Service Element", Proposed Standard, RFC 2211, Sept 1997. 1008 6 Gai, S., et. al., "RSVP Proxy", Internet Draft, Work in 1009 Progress, July 2001. 1011 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 1012 Proposed Standard, RFC 2961, April, 2001. 1014 8 Blake, S., et. al., "An Architecture for Differentiated 1015 Service", Proposed Standard, RFC 2475, Dec. 1998. 1017 9 Ash, J., et. al., "Proposed MPLS/DiffServ TE Class Types", Inter- 1018 net 1019 Draft, Work In Progress, Nov 2001. 1021 10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP", 1022 Internet Draft, Work In Progress, October 2001. 1024 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 1025 August 1982. 1027 12 Handley, M., et. al., "SIP: Session Initiation Protocol", 1028 Proposed Standard, RFC 2543, March 1999. 1030 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 1031 Completion (HPC) Network Capability_, ANSI T1.631, 1993. 1033 14 Reliable Audio Tool (RAT): 1034 http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 1036 15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority 1037 Header", Internet Draft, Work In Progress, December, 2001. 1039 16 Nichols, K., et. al.,"Definition of the Differentiated Services 1040 Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed 1041 Standard, RFC 2474, December 1998. 1043 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 1044 Proposed Standard, RFC 2748, Jan 2000. 1046 18 ITU, "International Emergency Preparedness Scheme", ITU 1047 Recommendation, E.106, March 2000. 1049 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 1050 Over IP", Informational, RFC 2871, June 2000 1052 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 1053 Standard, RFC 2597, June 1999 1055 21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 1056 Recomendation, I.255.3, July, 1990. 1058 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Internet 1059 Draft, Work In Progress, April 2001. 1061 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 1062 Track, RFC 3015, November 2000 1064 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 1065 Standards Track, RFC 2198, September, 1997 1067 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 1068 Generic Forward Error Correction", Standards Track, RFC 2733, 1069 December, 1999. 1071 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 1072 2000. 1074 27 Brown, I., "Securing IEPS over IP", White Paper, 1075 http://iepscheme.net/docs/secure_IEPS.doc 1077 28 Folts, H., "Description of an International Emergency Preference 1078 Scheme (IEPS) ITU-T Recommendation E.106 (Formerly CCITT 1079 Recomendation), Internet Draft, Work In Progress, February 2001 1081 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 1082 Draft, Work In Progress, October 2001. 1084 30 National Communications System: http://www.ncs.gov 1086 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 1087 http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, 1088 IETF Presentation: IPPM-Voiceip, Aug, 1997 1090 32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 1091 Proceedings, INET'95, Aug, 1995. 1093 33 Awduche, D, et al, "Requirements for Traffic Engineering Over 1094 MPLS", Informational, RFC 2702, September, 1999. 1096 34 Polk, J., "An Architecture for Multi-Level Precedence and 1097 Preemption over IP", Internet Draft, Work In Progress, 1098 November, 2001. 1100 8. Acknowledgments 1102 The authors would like to acknowledge the helpful comments, opinions, 1103 and clarifications of Stu Goldman and James Polk, as well as those 1104 comments received from the IEPS mailing list. 1106 9. Author's Addresses 1108 Ken Carlberg Ian Brown 1109 University College London University College London 1110 Department of Computer Science Department of Computer Science 1111 Gower Street Gower Street 1112 London, WC1E 6BT London, WC1E 6BT 1113 United Kingdom United Kingdom 1114 Table of Contents 1116 1. Introduction ................................................... 2 1117 1.1 Emergency Related Data ....................................... 3 1118 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3 1119 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 5 1120 1.2 Scope of this Document ....................................... 5 1121 2. Objective ..................................................... 7 1122 3. Value Added Objective ......................................... 10 1123 3.1 Alternate Path Routing ....................................... 10 1124 3.2 End-to-End Fault Tolerance ................................... 11 1125 4. Functional Requirements ....................................... 12 1126 4.1 Signaling .................................................... 13 1127 4.1.1 SIP ........................................................ 13 1128 4.1.2 Diff-Serv .................................................. 14 1129 4.1.3 RTP ........................................................ 16 1130 4.1.4 MEGACO/H.248 ............................................... 17 1131 4.2 Policy ....................................................... 17 1132 4.3 Traffic Engineering .......................................... 18 1133 4.4 Security ..................................................... 19 1134 5. Key Scenarios ................................................. 19 1135 6. Security Considerations ....................................... 22 1136 7. References .................................................... 22 1137 8. Acknowledgments ............................................... 24 1138 9. Author's Addresses ............................................ 24 1140 Full Copyright Statement 1142 "Copyright (C) The Internet Society (date). All Rights Reserved. 1143 This document and translations of it may be copied and furnished to 1144 others, and derivative works that comment on or otherwise explain it 1145 or assist in its implementation may be prepared, copied, published 1146 and distributed, in whole or in part, without restriction of any 1147 kind, provided that the above copyright notice and this paragraph are 1148 included on all such copies and derivative works. However, this 1149 document itself may not be modified in any way, such as by removing 1150 the copyright notice or references to the Internet Society or other 1151 Internet organizations, except as needed for the purpose of develop- 1152 ing Internet standards in which case the procedures for copyrights 1153 defined in the Internet Standards process must be followed, or as 1154 required to translate it into languages other than English. 1156 The limited permissions granted above are perpetual and will not be 1157 revoked by the Internet Society or its successors or assigns. 1159 This document and the information contained herein is provided as an 1160 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1161 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1162 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1163 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- 1164 CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.