idnits 2.17.1 draft-ietf-ieprep-framework-01.txt: -(160): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(173): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 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 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1246: '... requiredClass NULL OPTIONAL...' RFC 2119 keyword, line 1247: '... SEQUENCE OF ClearToken OPTIONAL...' RFC 2119 keyword, line 1248: '... SEQUENCE OF CryptoH323Token OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 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 475 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 165 looks like a reference -- Missing reference section? '18' on line 208 looks like a reference -- Missing reference section? '28' on line 210 looks like a reference -- Missing reference section? '14' on line 555 looks like a reference -- Missing reference section? '31' on line 242 looks like a reference -- Missing reference section? '32' on line 247 looks like a reference -- Missing reference section? '26' on line 364 looks like a reference -- Missing reference section? '15' on line 1220 looks like a reference -- Missing reference section? '19' on line 484 looks like a reference -- Missing reference section? '22' on line 486 looks like a reference -- Missing reference section? '24' on line 553 looks like a reference -- Missing reference section? '25' on line 553 looks like a reference -- Missing reference section? '21' on line 611 looks like a reference -- Missing reference section? '34' on line 625 looks like a reference -- Missing reference section? '23' on line 789 looks like a reference -- Missing reference section? '16' on line 642 looks like a reference -- Missing reference section? '20' on line 703 looks like a reference -- Missing reference section? '29' on line 763 looks like a reference -- Missing reference section? '17' on line 827 looks like a reference -- Missing reference section? '33' on line 848 looks like a reference -- Missing reference section? '35' on line 1215 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 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 May 14, 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 traffic engineering. Specifically, 105 we refer to the work in progress discussion of Proposed MPLS/DiffServ 106 Traffic Engineering Class Types [9], and the inclusion of fault 107 tolerance [10]. This latter item can be viewed as being similar to 108 "crank-back", a term used to describe the means by which the Public 109 Switched 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 carrier's 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 of GETS is that it supports a probabilistic approach 154 to call completion through priority, as opposed to guaranteed 155 approach through preemption. This distinction is important because 156 emergency services like GETS are not allowed to tear down existing 157 calls (i.e., seize resources) in order to establish a GETS call.� 158 Instead, GETS increases the probability of call completion by provid- 159 ing an additional label used in the contention for assignment of lim- 160 ited resources required for the call.� Thus, the GETS features focus 161 on increasing the probability that a particular telephone call will 162 be established, but cannot guarantee call completion. 164 GETS is supported by Signaling System 7 (SS7) via the T1.631 protocol 165 on High Probability of Completion (HPC) network capability [13]. 166 This document describes the specification of a National Security and 167 Emergency Preparedness (NS/EP) Calling Party Category (CPC) code 168 point used for SS7 ISDN User Part (ISUP) Initial Address Message 169 (IAM). In the presence of this code point, when a GETS call 170 encounters a restrictive network management control that has been 171 activated to reduce traffic overload to a congested route, the Local 172 Exchange Carriers (LECs) will provide the GETS call priority by 173 exempting the call from this restriction.� After receiving the exemp- 174 tion, if the GETS call finds all circuits busy in the route, the LEC 175 will provide further priority by queuing the call for the next avail- 176 able circuit.� 178 The procedure for a user (i.e., a person) establishing a GETS call is 179 as follows: 181 1) Dial a non-geographical area code number: 710-XXX-XXXX 182 2) Dial a PIN used to authenticate the call 183 3) Dial the actual destination number to be reached 185 In conjunction with the above, the source LEC (where the call ori- 186 ginated) attempts to establish the call through an IXC. This is done 187 even if the destination number is within the LEC itself. If the IXC 188 cannot forward the call to the destination LEC, then the source LEC 189 attempts to route the call through an alternate IXC. If alternate 190 IXCs cannot help establish the call, then a busy signal is finally 191 returned to the user. Otherwise, the call is completed and retains 192 the same quality of service as all other telephone calls. 194 The HPC component of GETS is not ubiquitously supported by the U.S. 195 PSTN. The only expectation is that the 710 area code is recognized 196 by all carriers. Additional support is conditional and dependent 197 upon the equivalent Service Level Agreements (SLA) established 198 between the U.S. Government and various telco carriers to support 199 GETS. Thus, the default end-to-end service for establishing a GETS 200 call can be roughly viewed as best effort and associated with the 201 same priority as calls from the general public. 203 It should be noted from the above description that GETS is separate 204 and unrelated to other emergency services like "911". 206 1.1.2. International Emergency Preparedness Scheme (IEPS) 208 [18] is a recent ITU standard that describes emergency related com- 209 munications over international telephone service (Note, this document 210 has also been published as a draft-RFC in [28]). While systems like 211 GETS are national in scope, IEPS acts as an extension to local or 212 national authorized emergency call establishment and provides a 213 building block for a global service. 215 As in the case of GETS, IEPS promotes mechanisms like extended queu- 216 ing, alternate routing, and exemption from restrictive management 217 controls in order to increase the probability that international 218 emergency calls will be established. The specifics of how this is to 219 be accomplished are to be defined in future ITU document(s). 221 1.2. Scope of this Document 223 The scope of this document centers on the near and mid-term support 224 of IEPS within the context of IP telephony, though not necessarily 225 Voice over IP. We make a distinction between these two by treating 226 IP telephony as a subset of VoIP, where in the former case we assume 227 some form of application layer signaling is used to explicitly estab- 228 lish and maintain voice data traffic. This explicit signaling capa- 229 bility provides the hooks from which VoIP traffic can be bridged to 230 the PSTN. 232 An example of this distinction is when the Redundant Audio Tool (RAT) 234 [14] begins sending VoIP packets to a unicast (or multicast) destina- 235 tion. RAT does not use explicit signaling like SIP to establish an 236 end-to-end call between two users. It simply sends data packets to 237 the target destination. On the other hand, "SIP phones" are host 238 devices that use a signaling protocol to establish a call signal 239 before sending data towards the destination. 241 One other aspect we should probably assume exists with IP Telephony 242 is an association of a target level of QoS per session or flow. [31] 243 makes an arguement that there is a maximum packet loss and delay for 244 VoIP traffic, and both are interdependent. For delays of ~200ms, a 245 corresponding drop rate of 5% is deemed acceptable. When delay is 246 lower, a 15-20% drop rate can be experienced and still considered 247 acceptable. [32] discusses the same topic and makes an arguement 248 that packet size plays a significant role in what users tolerate as 249 "intelligible" VoIP. The larger the packet, correlating to longer 250 sampling rate, the lower the acceptable rate of loss. 252 Regardless of a definitive drop rate, it would seem that interactive 253 voice has a lower threshold of loss than other elastic applications. 254 This places a higher burden on the problem space of supporting VoIP 255 over the Internet. This problem is further compounded when toll- 256 quality service is expected because it assumes a default service 257 model that is better than best effort. This in turn can increase the 258 probability that a form of call-blocking can occur with VoIP or IP 259 telephony traffic. 261 Beyond this, part of our motivation in writing this document is to 262 provide a framework for ISPs and carriers so that they have an under- 263 standing of objectives and accompanying functional requirements used 264 to support IEPS related IP telephony traffic. In addition, we also 265 wish to provide a reference point for potential customers (users of 266 IEPS) in order to constrain their expectations. In particular, we 267 wish to avoid any temptation of trying to replicate the exact capa- 268 bilities of existing emergency voice service currently available in 269 the PSTN to that of IP and the Internet. If nothing else, intrinsic 270 differences between the two communications architectures precludes 271 this from happening. Note, this does not prevent us from borrowing 272 design concepts or objectives from existing systems. 274 Section 2 presents several primary objectives that articulate what is 275 considered important in supporting IEPS related IP telephony traffic. 276 These objectives represent a generic set of goals and capabilities 277 attributed to supporting IEPS based IP telephony. Section 3 presents 278 additional value added objectives. These are capabilities that are 279 viewed as useful, but not critical in support of IEPS. Section 4 280 presents a series of functional requirements that stem from the 281 objectives articulated in section 2. Finally, Section 5 presents two 282 scenarios in IEPS that currently exist or are being deployed in the 283 near term over IP networks. These are not all-inclusive scenarios, 284 nor are they the only ones that can be articulated. However, they do 285 show cases where some of the functional requirements apply, and where 286 some do not. 288 Finally, we need to state that this document focuses its attention on 289 the IP layer and above. Specific operational procedures pertaining 290 to Network Operation Centers (NOC) or Network Information Centers 291 (NIC) are outside the scope of this document. This includes the 292 "bits" below IP, other specific technologies, and service level 293 agreements between ISPs and carriers with regard to dedicated links. 295 2. Objective 297 The support of IEPS within IP telephony can be realized in the form 298 of several primary objectives. These objectives define the generic 299 functions or capabilities associated with IEPS, and the scope of the 300 support needed to achieve these capabilities. From this generic set 301 of objectives, we present specific functional requirements of exist- 302 ing IP protocols (presented below in section 3). 304 There are two underlying goals in the selection of these objectives. 305 One goal is to produce a design that maximizes the use of existing IP 306 protocols and minimizes the set of additional specifications needed 307 to support IP-telephony based IEPS. Thus, with the inclusion of 308 these minimal augmentations, the bulk of the work in achieving IEPS 309 over an IP network that is connected or unconnected to the Internet 310 involves operational issues. Examples of this would be the estab- 311 lishment of Service Level Agreements (SLA) with ISPs, and/or the pro- 312 visioning of traffic engineered paths for IEPS-related telephony 313 traffic. 315 A second underlying goal in selecting the following objectives is to 316 take into account experiences from an existing emergency-type commun- 317 ication system (as described in section 1.1.1) as well as the exist- 318 ing restrictions and constraints placed by some countries. In the 319 former case, we do not attempt to mimic the system, but rather 320 extract information as a reference model. With respect to con- 321 straints based on laws or agency regulations, this would normally be 322 considered outside of the scope of any IETF document. However, these 323 constraints act as a means of determining the lowest common denomina- 324 tor in specifying technical functional requirements. If such con- 325 straints do not exist, then additional functions can be added to the 326 baseline set of functions. This last item will be expanded upon in 327 the description of Objective #3 below. 329 The following list of objectives are termed primary because they per- 330 tain to that which defines the underlying goals of IEPS. However, 331 the primary objectives are not meant to dictate major overhauls of 332 existing IP protocols, nor do they require completely new protocols 333 to be developed. 335 Primary Objectives in support of authorized emergency calls: 337 1) High Probability of Call Completion 338 2) Interaction with PSTN 339 3) Distinction of IEPS data traffic 340 4) Non-preemptive action 341 5) Non-ubiquitous support 342 6) Authenticated service 344 The first objective is the crux of our work because it defines our 345 expectations for both data and call signaling for IP telephony. As 346 stated, our objective is achieving a high probability that emergency 347 related calls (both data and signaling) will be forwarded through an 348 IP network. Specifically, we envision the relevance of this objec- 349 tive during times of congestion, the context of which we describe 350 further below in this section. The critical word in this objective 351 is "probability", as opposed to assurance or guarantee -- the latter 352 two placing a higher burden on the network. It stands to reason, 353 though, that the word "probability" is a less tangible description 354 that cannot be easily quantified. It is relative in relation to 355 other traffic transiting the same network. Objectives 4 and 5 listed 356 above help us to qualify the term probability in the context of other 357 objectives. 359 The second objective involves the interaction of IP telephony signal- 360 ing with existing PSTN support for emergency related voice communica- 361 tions. As mentioned above in Section 1.2, standard T1.631 [26] 362 specifies emergency code points for SS7. Specifically, the National 363 Security and Emergency Preparedness (NS/EP) Calling Party Category 364 code point is defined for ISUP IAM messages used by SS7 [26]. Hence, 365 our objective in the interaction between the PSTN and IP telephony 366 with respect to IEPS (and national indicators) is a direct mapping 367 between related code points. 369 The third objective focuses on the ability to distinguish IEPS data 370 packets from other types of VoIP packets. With such an ability, 371 transit providers can more easily ensure that service level agree- 372 ments relating to IEPS are adhered to. Note that we do not assume 373 that the actions taken to distinguish IEPS type packets is easy. 374 Nor, in this section, do we state the form of this distinction. We 375 simply present the objective of identifying flows that relate to IEPS 376 versus others that traverse a transit network. 378 At an abstract level, the fourth objective pertains to the actions 379 taken when an IP telephony call, via a signaling protocol such as 380 SIP, cannot be forwarded because the network is experiencing a form 381 of congestion. We state this in general terms because of two rea- 382 sons: a) there may exist applications other than SIP, like H.248, 383 used for call establishment, and b) congestion may come in several 384 forms. For example, congestion may exist at the IP packet layer with 385 respect to queues being filled to their configured limit. Congestion 386 may also arise from resource allocation (i.e., QoS) attributed per 387 call or aggregated sets of calls. In this latter case, while there 388 may exist resources to forward the packets, a signaling server may 389 have reached its limit as to how many telephony calls it will support 390 while retaining toll-quality service per call. Typically, one terms 391 this form of congestion as call blocking. Note that we do not 392 address the case when congestion occurs at the bit level below that 393 of IP, due to the position that it is outside the scope of IP and the 394 IETF. 396 So, given the existence of congestion in its various forms, our 397 objective is to support IEPS-related IP telephony call signaling and 398 data traffic via non-preemptive actions taken by the network. More 399 specifically, we associate this objective in the context of IP 400 telephony acting as part of the Public Telephone Network (PTN). 401 This, as opposed to the use of IP telephony within a private or stub 402 network. In section 5 below, we expand on this through the descrip- 403 tion of two distinct scenarios of IP telephony and its operation with 404 IEPS and the PSTN. 406 It is important to mention that this is a default objective influ- 407 enced by existing laws & regulations. Those countries not bound by 408 these restrictions can remove this objective and make provisions to 409 enforce preemptive action. In this case, it would probably be advan- 410 tageous to deploy a signaling system similar to that proposed in 411 [15], wherein multiple levels of priority are defined and preemption 412 via admission control from SIP servers is enforced. 414 The fifth objective stipulates that we do not advocate the need or 415 expectation for ubiquitous support of IEPS across all administrative 416 domains of the Internet. While it would be desirable to have ubiqui- 417 tous support, we feel the reliance of such a requirement would doom 418 even the contemplation of supporting IEPS by the IETF and the 419 expected entities (e.g., ISPs and vendors) involved in its deploy- 420 ment. 422 We use the existing GETS service in the U.S. as an existing example 423 in which emergency related communications does not need to be ubiqui- 424 tous. As mentioned previously, the measure and amount of support 425 provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs 426 nor LECs. Given the fact that GETS still works within this context, 427 it is our objective to follow this deployment model such that we can 428 accomplish the first objective listed above -- a higher probability 429 of call completion than that of normal IP telephony call traffic. 431 Our final objective is that only authorized users may use the ser- 432 vices outlined in this framework. GETS users are authenticated using 433 a PIN provided to the telecommunications carrier, which signals 434 authentication to subsequent networks via the HPC class mark. In an 435 IP network, the authentication center will need to securely signal 436 back to the IP ingress point that a given user is authorized to send 437 IEPS related flows. Similarly, transit networks with IEPS SLAs must 438 securely interchange authorized IEPS traffic. In both cases, IPSec 439 authentication transforms may be used to protect this traffic. This 440 is entirely separate from end-to-end IPSec protection of user 441 traffic, which will be configured by users. IP-PSTN gateways must 442 also be able to securely signal IEPS authorization for a given flow. 443 As these gateways are likely to act as SIP servers, we further con- 444 sider the use of SIP's security functions to aid this objective. 446 3. Value Added Objective 448 This objective is viewed as being helpful in achieving a high proba- 449 bility of call completion. Its realization within an IP network 450 would be in the form of new protocols or enhancements to existing 451 ones. Thus, objectives listed in this section are treated as value 452 added -- an expectation that their existence would be beneficial, and 453 yet not viewed as critical to support IEPS related IP telephony 454 traffic. 456 3.1. Alternate Path Routing 458 This objective involves the ability to discover and use a different 459 path to route IP telephony traffic around congestion points and thus 460 avoid them. Ideally, the discovery process would be accomplished in 461 an expedient manner (possibly even a priori to the need of its 462 existence). At this level, we make no requirements as to how the 463 alternate path is accomplished, or even at which layer it is achieved 464 -- e.g., the network versus the application layer. But this kind of 465 capability, at least in a minimal form, would help contribute to 466 increasing the probability of call completion of IEPS traffic by mak- 467 ing use of noncongested alternate paths. We use the term "minimal 468 form" to emphasize the fact that care must be taken in how the system 469 provides alternate paths so it does not significantly contribute to 470 the congestion that is to be avoided (e.g., via excess 471 control/discovery messages). 473 At the time that this document was written, we can identify two 474 work-in-progress areas in the IETF that can be helpful in providing 475 alternate paths for call signaling. The first is [10], which is 476 focused on network layer routing and describes enhancements to the 477 LDP specification of MPLS to help achieve fault tolerance. This in 478 itself does not provide alternate path routing, but rather helps 479 minimize loss in intradomain connectivity when MPLS is used within a 480 domain. 482 The second effort comes from the IP Telephony working group and 483 involves Telephony Routing over IP (TRIP). To date, a framework 484 document [19] has been published as an RFC which describes the 485 discovery and exchange of IP telephony gateway routing tables between 486 providers. The TRIP protocol [22], a supplemental work in progress, 487 specifies application level telephony routing regardless of the sig- 488 naling protocol being used (e.g., SIP or H.323). TRIP is modeled 489 after BGP-4 and advertises reachability and attributes of destina- 490 tions. In its current form, several attributes have already been 491 defined, such as LocalPreference and MultiExitDisc. Upon standardi- 492 zation of TRIP, additional attributes can be registered with IANA. 493 Initially, we would recommend two additional attributes that would 494 relate to emergency related flows. These being: 496 EmergencyMultiExitDisc 498 The EmergencyMultiExitDisc attribute is similar to the 499 MultiExitDisc in that it is an inter-domain attribute used 500 to express a preference of one or more links over others 501 between domains. Unlike the MultiExitDisc, this attribute 502 specifically identifies links that are preferred for emergency 503 related calls that span domains. 505 EmergencyLocalPreference 507 The EmergencyLocalPreference attribute is similar to the 508 LocalPreference in that it is an intra-domain attribute used 509 to inform other LSs of the local LSs preference for a given 510 route. The difference between the two types attributes is 511 that the preferred route specifically relates to emergency-type 512 calls (e.g., 911). This attribute has no significance between 513 domains. Local policy determines if there is an association 514 between the EmergencyLocalPreference and the 515 EmergencyMultiExitDisc attribute. 517 3.2. End-to-End Fault Tolerance 519 This topic involves the work that has been done in trying to compen- 520 sate for lossy networks providing best effort service. In particu- 521 lar, we focus on the use of a) Forward Error Correction (FEC), and b) 522 redundant transmissions that can be used to compensate for lost data 523 packets. (Note that our aim is fault tolerance, as opposed to an 524 expectation of always achieving it). 526 In the former case, additional FEC data packets are constructed from 527 a set of original data packets and inserted into the end-to-end 528 stream. Depending on the algorithm used, these FEC packets can 529 reconstruct one or more of the original set that were lost by the 530 network. An example may be in the form of a 10:3 ratio, in which 10 531 original packets are used to generate three additional FEC packets. 532 Thus, if the network loses 30% or less number of packets, then the 533 FEC scheme will be able to compensate for that loss. The drawback to 534 this approach is that to compensate for the loss, a steady state 535 increase in offered load has been injected into the network. This 536 makes an arguement that the act of protection against loss has con- 537 tributed to additional pressures leading to congestion, which in turn 538 helps trigger packet loss. In addition, in using a ratio of 10:3, 539 the source (or some proxy) must "hold" all 10 packets in order to 540 construct the three FEC packets. This contributes to the end-to-end 541 delay of the packets as well as minor bursts of load in addition to 542 changes in jitter. 544 The other form of fault tolerance we discuss involves the use of 545 redundant transmissions. By this we mean the case in which an origi- 546 nal data packet is followed by one or more redundant packets. At 547 first glance, this would appear to be even less friendly to the net- 548 work than that of adding FEC packets. However, the encodings of the 549 redundant packets can be of a different type (or even transcoded into 550 a lower quality) that produce redundant data packets that are signi- 551 ficantly smaller than the original packet. 553 Two RFCs [24, 25] have been produced that define RTP payloads for FEC 554 and redundant audio data. An implementation example of a redundant 555 audio application can be found in [14]. We note that both FEC and 556 redundant transmissions can be viewed as rather specific and to a 557 degree tangential solutions regarding packet loss and emergency com- 558 munications. Hence, these topics are placed under the category of 559 value added objectives. 561 4. Functional Requirements 563 In this section, we take the objectives presented above and specify a 564 corresponding set of functional requirements to achieve them. Given 565 that the objectives are predominantly atomic in nature, the 566 corresponding functional requirements are to be viewed separately 567 with no specific dependency upon each other as a whole. They may be 568 complimentary with each other, but there is no need for all to exist 569 given different scenarios of operation, and that IEPS support is not 570 viewed as a ubiquitously available service. We divide the functional 571 requirements into 4 areas: 573 1) Signaling 574 2) Policy 575 3) Traffic Engineering 576 4) Security 578 4.1. Signaling 580 Signaling is used to convey various information to either intermedi- 581 ate nodes or end nodes. It can be out-of-band of a data flow, and 582 thus in a separate flow of its own, such as SIP messages. It can be 583 in-band and part of the state information in a datagram containing 584 the voice data. This latter example could be realized in the form of 585 diff-serv code points in the IP packet. 587 In the following subsections, we discuss potential augmentations to 588 different types of signaling and state information to help support 589 the distinction of emergency related communications in general, and 590 IEPS specifically. 592 4.1.1. SIP 594 With respect to application level signaling for IP telephony, we 595 focus our attention to the Session Initiation Protocol (SIP). 596 Currently, SIP has an existing "priority" field in the Request- 597 Header-Field that distinguishes different types of sessions. The 598 five currently defined values are: "emergency", "urgent", "normal", 599 "non-urgent", "other-priority". These values are meant to convey 600 importance to the end-user and have no additional sematics associated 601 with them. 603 [15] is a work in progress that defines a new header field for SIP 604 known as the Resource Priority Header. This new header field is 605 meant to provide an additional measure of distinction that can influ- 606 ence the behavior of gateways and SIP proxies. The structure of the 607 field is in the form of a NameSpace.Priority. The "NameSpace" pro- 608 vides a reference point by which the "Priority" values correspond to. 609 In the example of the Defence Switched Network (DSN) namespace, six 610 ordered priority values correlating to Multi-Level Priority & Prefer- 611 ence (MLPP) [21] are defined. Each of the defined values for the DSN 612 NameSpace have a specific relation or priority to each other. How- 613 ever, the specific actions enacted on the value, and their relation- 614 ship to other NameSpaces are subject to policies and SLAs. We expand 615 on the subject of policies below in section 4.2. 617 Additional namespaces and value(s) would be registered with IANA. It 618 would be our intention to follow the approach taken in [15] and 619 register a new namespace attributed to IEPS. Unlike [15], we would 620 define a single value (e.g., "authorized-emergency") that would 621 correspond to the NS/EP code point of SS7. This will help facilitate 622 a seamless interaction between the PSTN and the an IP network acting 623 as either an internal backbone or as a peering ISP. 625 Note #1: The work put forth by Polk in [34], which describes an 626 architecture for MLPP, is similar to the subject of IEPS in the sense 627 that both aim at distinguishing certain VoIP flows from others. How- 628 ever, MLPP and IEPS are not the same efforts. One critical differ- 629 ence is that MLPP involves the use of preemption, while the default 630 model for IEPS is simply an increase in the probability of call com- 631 pletion. 633 Note #2: The term "Priority" has been a subject of strong debate. In 634 this document, we reference the term based on the terminology inher- 635 ited from other drafts and documents, such as can be found in [15], 636 and the Megaco RFC [23]. However, our focus is aimed at using the 637 "priority" value as simply a label by which we distinguish one set of 638 flows from another. 640 4.1.2. Diff-Serv 642 In accordance with [16], the differentiated services code point 643 (DSCP) field is divided into three sets of values. The first set is 644 assigned by IANA. Within this set, there are currently, three types 645 of Per Hop Behaviors that have been specified: Default (correlating 646 to best effort forwarding), Assured Forwarding, and Expedited For- 647 warding. The second set of DSCP values are set aside for local or 648 experimental use. The third set of DSCP values are also set aside 649 for local or experimental use, but may later be reassigned to IANA in 650 case the first set has been completely assigned. 652 One candidate recomendation involves the specification of a new type 653 of Per-Hop Behavior (PHB). This would provide a specific means of 654 distinguishing emergency related traffic (signaling and user data) 655 from other traffic. The existence of this PHB then provides a base- 656 line by which specific code points may be defined related to various 657 emergency related traffic: authorized emergency sessions (e.g., 658 IEPS), general public emergency calls (e.g., "911"), MLPP. Aggre- 659 gates would still exist with respect to the bundling of applications 660 per code point. Further, one would associate a forwarding paradigm 661 aimed at a low loss rate reflective of the code point selected. The 662 new PHB could be in the form of a one or more code points that dupli- 663 cate EF-type traffic characteristics. Policies would determine IF a 664 measure of importance exists per EF-type code-point. 666 A potential issue that could be addressed by a new PHB involves merge 667 points of flows within a diff-serv domain. With EF, one can expect 668 admission control being performed at the edges of the domain. 669 Presumably, careful traffic engineering would be applied to avoid 670 congestion of EF queues at internal/core merge points stemming from 671 flows originating from different ingress nodes of the diff-serv 672 domain. However, traffic engineering may not be able to compensate 673 for congestion of EF-type traffic at the domain's core routers. 674 Hence, a new PHB that has more than one code point to identify EF- 675 type traffic may address congestion by associating a drop precedence 676 for certain types of EF-type datagrams. Note that local policy and 677 SLAs would define which EF-type of traffic, if any, would be associ- 678 ated with a specific drop precedence. 680 Another candidate recomendation would be to define a new or fifth 681 class for the existing AF PHB. Unlike the other currently defined 682 classes, this new one would be based on five levels of drop pre- 683 cedence. This increase in the number of levels would conveniently 684 correlate to the the levels of MLPP, which has five types of priori- 685 ties. The five levels would also correlate to a recent effort in the 686 Study Group 11 of the ITU to define 5 levels for Emergency Telecom- 687 munications Service (ETS). Beyond these other standardization 688 efforts, the 5 levels would provide a higher level of variance that 689 could be used to supercede the existing 3 levels used in the other 690 classes. Hence, if other non-emergency aggregate traffic were 691 assigned to the new class, the highest drop precedence they are 692 assigned to is (3) -- corresponding to the other four currently 693 defined classes. Emergency traffic would be set to (4) or (5), 694 depending on the SLA tht has been defined. 696 It is important to note that as of the time that this document was 697 written, the IETF is taking a conservative approach in specifying new 698 PHBs. This is because the number of code points that can be defined 699 is relatively small, and thus understandably considered a scarce 700 resource. Therefore, the possibility of a new PHB being defined for 701 emergency related traffic is at best a long term project that may or 702 may not be accepted by the IETF. In the near term, we would ini- 703 tially recommend using the Assured Forwarding (AF) PHB [20] for dis- 704 tinguishing emergency traffic from other types of flows. At a 705 minimum, AF would be used for the different SIP call signaling mes- 706 sages. If EF was also supported by the domain, then it would be used 707 for IP telephony data packets. Otherwise, another AF class would be 708 used for those data flows. 710 It is critical to note that one cannot specify an exact code point 711 used for emergency related data flows because the relevance of a code 712 point is local to the given diff-serv domain (i.e., they are not glo- 713 bally unique per micro-flow or aggregate of flows). In addition, we 714 can expect that the existence of a codepoint for emergency related 715 flows is based on the service level agreements established with a 716 given diff-serv domain. 718 4.1.3. RTP 720 The Real-Time Transport Protocol (RTP) provides end-to-end delivery 721 services for data with real-time characteristics. The type of data 722 is generally in the form of audio or video type applications, and are 723 frequently interactive in nature. RTP is typically run over UDP and 724 has been designed with a fixed header that identifies a specific type 725 of payload -- typically representing a specific form of application 726 media. The designers of RTP also assumed an underlying network pro- 727 viding best effort service. As such, RTP does not provide any 728 mechanism to ensure timely delivery or provide other QoS guarantees. 729 However, the emergence of applications like IP telephony, as well as 730 new service models, presents new environments where RTP traffic may 731 be forwarded over networks that support better than best effort ser- 732 vice. Hence, the original scope and target environment for RTP has 733 expanded to include networks providing services other than best 734 effort. 736 In 4.1.2, we discussed one means of marking a data packet for emer- 737 gencies under the context of the diff-serv architecture. However, we 738 also pointed out that diff-serv markings for specific PHBs are not 739 globally unique, and may be arbitrarily removed or even changed by 740 intermediary nodes or domains. Hence, with respect to emergency 741 related data packets, we are still missing an in-band marking in a 742 data packet that stays constant on an end-to-end basis. 744 There are have three choices in defining a persistent marking of data 745 packets and thus avoid the transitory marking of diff-serv code 746 points. We can propose a new PHB dedicated for emergency type 747 traffic as discussed in 4.1.2. We can propose a specification of a 748 new shim layer protocol at some location above IP. Or, we can add a 749 new specification to an existing application layer protocol. The 750 first two cases are probably the "cleanest" architecturally, but they 751 are long term efforts that may not come to pass because of a limited 752 amount of diff-serv code points and the contention that yet another 753 shim layer will make the IP stack too large. The third case, placing 754 a marking in an application layer packet, also has drawbacks; the key 755 weakness being the specification of a marking on a per-application 756 basis. 758 Discussions have been held in the Audio/Visual Transport (AVT) work- 759 ing group of augmenting RTP so that it can carry a marking that dis- 760 tinguishes emergency-related traffic from that which is not. Specif- 761 ically, one would define a new extention that contains a "classifier" 762 field indicating the condition associated with the packet (e.g., 763 authorized-emergency, emergency, normal) [29]. The rationale behind 764 this idea was that focusing on RTP would allow one to rely on a point 765 of aggregation that would apply to all payloads that it encapsulates. 766 However, the AVT group has expressed a rough consensus that placing 767 additional classifier state in the RTP header to denote the impor- 768 tance of one flow over another is not an approach that wish to 769 advance. Objections ranging from relying on SIP to convey importance 770 of a flow, as well as the possibility of adversely affecting header 771 compression, were expressed. There was also the general feeling that 772 the extension header for RTP should not be used for RTP packet of a 773 flow. 775 Author's note: There was some debate as to whether to keep the above 776 subsection concerning RTP in this document. We have decided to 777 retain it because it is felt that information concerning directions 778 that should NOT be taken to support IEPS is important to the commun- 779 ity at large. 781 4.1.4. MEGACO/H.248 783 The Media Gateway Control protocol (MEGACO) [23] defines the interac- 784 tion between a media gateway and a media gateway controller. [23] is 785 viewed as common text with ITU-T Recommendation H.248 and is a result 786 of applying the changes of RFC 2886 (Megaco Errata) to the text of 787 RFC 2885 (Megaco Protocol version 0.8). 789 In [23], the protocol specifies a Priority and Emergency field for a 790 context attribute and descriptor. The Emergency is an optional 791 boolean (True or False) condition. The Priority value, which ranges 792 from 0 through 15, specifies the precedence handling for a context. 794 The protocol does not specify individual values for priority. We 795 also do not recommend the definition of a well known value for the 796 MEGAGO priority. Any values set should be a function of any SLAs 797 that have been established regarding the handling of emergency 798 traffic. In addition, given that priority values denote precedence 799 (according to the Megaco protocol), then by default the IEPS data 800 flows should probably receive the same priority as other non- 801 emergency calls. This approach follows the objective of not relying 802 on preemption as the default treatment of emergency-related. 804 4.2. Policy 806 One of the objectives listed in section 3 above is to treat IEPS- 807 signaling, and related data traffic, as non-preemptive in nature. 808 Further, that this treatment is to be the default mode of operation 809 or service. This is in recognition that existing regulations or laws 810 of certain countries governing the establishment of SLAs may not 811 allow preemptive actions (e.g., dropping existing telephony flows). 812 On the other hand, the laws and regulations of other countries 813 influencing the specification of SLA(s) may allow preemption, or even 814 require its existence. Given this disparity, we rely on local policy 815 to determine the degree by which emergency related traffic affects 816 existing traffic load of a given network or ISP. Important note: we 817 reiterate our earlier comment that laws and regulations are generally 818 outside the scope of the IETF and its specification of designs and 819 protocols. However, these constraints can be used as a guide in pro- 820 ducing a baseline function to be supported; in our case, a default 821 policy for non-preemptive call establishment of IEPS signaling and 822 data. 824 Policy can be in the form of static information embedded in various 825 components (e.g., SIP servers or bandwidth brokers), or it can be 826 realized and supported via COPS with respect to allocation of a 827 domain's resources [17]. There is no requirement as to how policy is 828 accomplished. Instead, if a domain follows actions outside of the 829 default non-preemptive action of IEPS-related communication, then we 830 stipulate a functional requirement that some type of policy mechanism 831 is in place to satisfy the local policies of an SLA established for 832 IEPS type traffic. 834 4.3. Traffic Engineering 836 In those cases where a network operates under the constraints of 837 SLAs, one or more of which pertains to IEPS based traffic, it can be 838 expected that some form of traffic engineering is applied to the 839 operation of the network. We make no requirements as to which type 840 of traffic engineering mechanism is used, but that such a system 841 exists and can distinguish and support IEPS signaling and data 842 traffic. 844 MPLS is generally the first protocol that comes to mind when the sub- 845 ject of traffic engineering is brought up. This notion is hightened 846 concerning the subject of IP telephony because of MPLS's ability to 847 to permit a quasi circuit switching capability to be superimposed on 848 the current Internet routing model [33]. 850 However, having cited MPLS, we need to stress that it is an intra- 851 domain protocol, and so may or may not exist within a given ISP. 852 Other forms of traffic engineering, such as weighted OSPF, may be the 853 mechanism of choice by an ISP. 855 Note: As a point of reference, existing SLAs established by the NCS 856 for GETS service tend to focus on a maximum allocation of (e.g., 1%) 857 of calls allowed to be established through a given LEC using HPC. 858 Once this limit is reached, all other GETS calls experience the same 859 probably of call completion as the general public. It is expected, 860 and encouraged, that IEPS related SLAs will have a limit with respect 861 to the amount of traffic distinguished as being emergency related, 862 and initiated by an authorized user. 864 4.4. Security 866 As IEPS support moves from intra-domain PSTN and IP networks to dif- 867 fuse inter-domain pure IP, authenticated service becomes more complex 868 to provide. Where an IEPS call is carried from PSTN to PSTN via one 869 carrier's backbone IP network, very little IP-specific security sup- 870 port is required. The user authenticates herself as usual to the 871 network using a PIN. The gateway from her PSTN connection into the 872 backbone IP network must be able to signal that the flow has IEPS 873 priority. Conversely, the gateway back into the PSTN must similarly 874 signal the call's higher priority. A secure link between the gateways 875 may be set up using IPSec or SIP security functionality. If the end- 876 point is an IP device on the carrier's network, the link may be set 877 up securely from the ingress gateway to the end device. 879 As flows traverse more than one IP network, domains whose peering 880 agreements include IEPS support must have means to securely signal a 881 given flow's IEPS status. They may choose to use physical link secu- 882 rity and/or IPSec authentication, combined with traffic conditioning 883 measures to limit the amount of IEPS traffic that may pass between 884 the two domains. The inter-domain agreement may require the originat- 885 ing network to take responsibility for ensuring only authorized 886 traffic is marked with IEPS priority; the downstream domain may still 887 perform redundant conditioning to prevent the propagation of theft 888 and denial of service attacks. Security may be provided between 889 ingress and egress gateways or IP endpoints using IPSec or SIP secu- 890 rity functions. 892 When a call originates from an IP device, the ingress network may 893 authorize IEPS traffic over that link as part of its user authentica- 894 tion procedures without necessarily communicating with a central IEPS 895 authentication center as happens with POTS-originated calls. These 896 authentication procedures may occur at the link or network layers, 897 but are entirely at the discretion of the ingress network. That net- 898 work must decide how often it should update its list of authorized 899 IEPS users based on the bounds it is prepared to accept on traffic 900 from recently-revoked users. 902 5. Key Scenarios 904 There are various scenarios in which IP telephony can be realized, 905 each of which can infer a unique set of functional requirements that 906 may include just a subset of those listed above. We acknowledge that 907 a scenario may exist whose functional requirements are not listed 908 above. Our intention is not to consider every possible scenario by 909 which support for emergency related IP telephony can be realized. 910 Rather, we narrow our scope using a single guideline; we assume there 911 is a signaling & data interaction between the PSTN and the IP network 912 with respect to supporting emergency-related telephony traffic. We 913 stress that this does not preclude an IP-only end-to-end model, but 914 rather the inclusion of the PSTN expands the problem space and 915 includes the current dominant form of voice communication. 917 There are two scenarios that we use as a model for determining our 918 objectives and subsequent functional requirements. These are: 920 Single IP Administrative Domain 921 ------------------------------- 923 This scenario is a direct reflection of the evolution of the PSTN. 924 Specifically, we refer to the case in which data networks have 925 emerged in various degrees as a backbone infrastructure connecting 926 PSTN switches at its edges. This represents a single isolated IP 927 administrative domain that has no directly adjacent IP domains con- 928 nected to it. We show an example of this scenario below in Figure 1. 929 In this example, we show two types of carriers. One is the legacy 930 carrier, whose infrastructure retains the classic switching architec- 931 ture attributed to the PSTN. The other is the next generation car- 932 rier, which uses a data network (e.g., IP) as its core infrastruc- 933 ture, and Signaling Gateways at its edges. These gateways "speak" 934 SS7 externally with peering carriers, and another protocol (e.g., 935 SIP) internally, which rides on top of the IP infrastructure. 937 Legacy Next Generation Next Generation 938 Carrier Carrier Carrier 939 ******* *************** ************** 940 * * * * ISUP * * 941 SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG 942 * * (SS7) * (SIP) * (SS7) * (SIP) * 943 ******* *************** ************** 945 SW - Telco Switch 946 SG - Signaling Gateway 948 Figure 1 950 The significant aspect of this scenario is that all the resources of 951 each IP "island" fall within a given administrative authority. 952 Hence, there is not a problem of retaining toll quality Grade of Ser- 953 vice as the voice traffic (data and signaling) exits the IP network 954 because of the existing SS7 provisioned service between carriers. 955 Thus, the need for support of mechanisms like diff-serv, and an 956 expansion of the defined set of Per-Hop Behaviors is reduced (if not 957 eliminated) under this scenario. 959 Another function that has little or no importance within the closed 960 IP environment of Figure 1 is that of IP security. The fact that 961 each administrative domain peers with each other as part of the PSTN, 962 means that existing security, in the form of Personal Identification 963 Number (PIN) authentication (under the context of telephony infras- 964 tructure protection), is the default scope of security. We do not 965 claim that the reliance on a PIN based security system is highly 966 secure or even desirable. But, we use this system as a default 967 mechanism in order to avoid placing additional requirements on exist- 968 ing authorized emergency telephony systems. 970 Multiple IP Administrative Domains 971 ---------------------------------- 973 We view the scenario of multiple IP administrative domains as a 974 superset of the previous scenario. Specifically, we retain the 975 notion that the IP telephony system peers with the existing PSTN. In 976 addition, segments (i.e., portions of the Internet) may exchange sig- 977 naling with other IP administrative domains via non-PSTN signaling 978 protocols like SIP. 980 Legacy Next Generation Next Generation 981 Carrier Carrier Carrier 982 ******* *************** ************** 983 * * * * * * 984 SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG 985 * * (SS7) * (SIP) * (SIP) * (SIP) * 986 ******* *************** ************** 988 SW - Telco Switch 989 SG - Signaling Gateway 991 Figure 2 993 Given multiple IP domains, and the presumption that SLAs relating to 994 IEPS traffic may exist between them, the need for something like 995 diff-serv grows with respect to being able to distinguish the emer- 996 gency related traffic from other types of traffic. In addition, IP 997 security becomes more important between domains in order to ensure 998 that the act of distinguishing IEPS-type traffic is indeed valid for 999 the given source. 1001 6. Security Considerations 1003 Information on this topic is presented in sections 2 and 4. 1005 7. References 1007 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1008 9, RFC 2026, October 1996. 1010 2 Braden, R., et. al., "Integrated Services in the Internet 1011 Architecture: An Overview", Informational, RFC 1633, June 1994. 1013 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 1014 Version 1, Functional Specification", Proposed Standard, RFC 1015 2205, Sept. 1997. 1017 4 Shenker, S., et. al., "Specification of Guaranteed Quality of 1018 Service", Proposed Standard, RFC 2212, Sept 1997. 1020 5 Wroclawski, J., "Specification for Controlled-Load Network 1021 Service Element", Proposed Standard, RFC 2211, Sept 1997. 1023 6 Gai, S., et. al., "RSVP Proxy", Internet Draft, Work in 1024 Progress, July 2001. 1026 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 1027 Proposed Standard, RFC 2961, April, 2001. 1029 8 Blake, S., et. al., "An Architecture for Differentiated 1030 Service", Proposed Standard, RFC 2475, Dec. 1998. 1032 9 Ash, J., et. al., "Proposed MPLS/DiffServ TE Class Types", Inter- 1033 net 1034 Draft, Work In Progress, Nov 2001. 1036 10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP", 1037 Internet Draft, Work In Progress, October 2001. 1039 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 1040 August 1982. 1042 12 Handley, M., et. al., "SIP: Session Initiation Protocol", 1043 Proposed Standard, RFC 2543, March 1999. 1045 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 1046 Completion (HPC) Network Capability_, ANSI T1.631, 1993. 1048 14 Reliable Audio Tool (RAT): 1049 http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 1051 15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority 1052 Header", Internet Draft, Work In Progress, December, 2001. 1054 16 Nichols, K., et. al.,"Definition of the Differentiated Services 1055 Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed 1056 Standard, RFC 2474, December 1998. 1058 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 1059 Proposed Standard, RFC 2748, Jan 2000. 1061 18 ITU, "International Emergency Preparedness Scheme", ITU 1062 Recommendation, E.106, March 2000. 1064 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 1065 Over IP", Informational, RFC 2871, June 2000 1067 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 1068 Standard, RFC 2597, June 1999 1070 21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 1071 Recomendation, I.255.3, July, 1990. 1073 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Internet 1074 Draft, Work In Progress, April 2001. 1076 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 1077 Track, RFC 3015, November 2000 1079 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 1080 Standards Track, RFC 2198, September, 1997 1082 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 1083 Generic Forward Error Correction", Standards Track, RFC 2733, 1084 December, 1999. 1086 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 1087 2000. 1089 27 Brown, I., "Securing IEPS over IP", White Paper, 1090 http://iepscheme.net/docs/secure_IEPS.doc 1092 28 Folts, H., "Description of an International Emergency Preference 1093 Scheme (IEPS) ITU-T Recommendation E.106 (Formerly CCITT 1094 Recomendation), Internet Draft, Work In Progress, February 2001 1096 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 1097 Draft, Work In Progress, October 2001. 1099 30 National Communications System: http://www.ncs.gov 1101 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 1102 http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, 1103 IETF Presentation: IPPM-Voiceip, Aug, 1997 1105 32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 1106 Proceedings, INET'95, Aug, 1995. 1108 33 Awduche, D, et al, "Requirements for Traffic Engineering Over 1109 MPLS", Informational, RFC 2702, September, 1999. 1111 34 Polk, J., "An Architecture for Multi-Level Precedence and 1112 Preemption over IP", Internet Draft, Work In Progress, 1113 November, 2001. 1115 35 "Service Class Designations for H.323 Calls", ITU Draft 1116 Recommendation H.GEF.4, September, 2001 1118 8. Appendix A: Government Telephone Preference Scheme (GTPS) 1120 This framework document uses U.S. GETS as a target model for defining 1121 a framework for supporting authorized emergency related communication 1122 within the context of IP telephony. We take this position because of 1123 the various areas that must be considered; from the application layer 1124 to the (inter)network layer, in addition to policy, security (author- 1125 ized access), and traffic engineering. 1127 The U.K. has a different type of authorized use of telephony services 1128 referred to as the Government Telephone Preference Scheme (GTPS). 1129 This service was introduced in the 1950's at a time when loss of 1130 power to the PSTN due to war or natural disaster was of prime con- 1131 cern. If a loss of power did occur, it was felt that the critical 1132 issue was to take action to limit phone usage by the general public 1133 so that power would be conserved for use by critical personnel 1134 involved in an emergency. 1136 The design and implementation of GTPS focused on the ability of the 1137 U.K. PSTN to withdraw outgoing telephone service from the majority 1138 of the general public. Inbound calls can still be received, but the 1139 net effect of the action is that power for the phone line service is 1140 conserved. It can probably be argued that power loss is not as 1141 important an issue today as it was back in the 50's. And in fact 1142 Oftel, the U.K. regulatory authority, is planning an evolutionary 1143 change to GTPS so that it reflects current needs and requirements for 1144 supporting emergency communications through the U.K. PSTN -- such as 1145 congestion, and the ability to provide roaming authorized access like 1146 that of GETS. 1148 At present, all local exchange access points (ie, phones) are divided 1149 into three categories: 1151 1: Time of War: people that are involved in operations and planning 1152 of a war or war conditions 1153 2: Natural Disaster: individuals that are involved in recovery and 1154 operations associated with natural disasters. 1155 3: General Public: people that are not associated with categories 1156 1 and 2, which is essentially over 99% of the population. 1158 Unlike the roaming ability of GETS users, GTPS associates preference 1159 with an originating phone. This simplifies the process of determin- 1160 ing who is allowed outbound phone service, but it is also quite res- 1161 trictive in its usage. Hence, individuals that want preferential 1162 service must use the phone that has been designated as Category 1 or 1163 2. Note: for the general public, pay phones have been designated as 1164 Category 2 so that 999 (emergency calls to fire or police) can be 1165 made. 1167 In 1984, an updated version of GTPS was made available following the 1168 deregulation of the U.K. phone system. In this new scheme, local 1169 exchanges retained the three category system while inter-exchange 1170 calls use call-gaping. Priority marks, via C7/NUP, would bypass the 1171 call-gaping. The authority to activate GTPS was also extended to the 1172 46 Constables (i.e., local police chiefs) of the U.K. -- each being 1173 responsible for their own jurisdiction. 1175 8.1. GTPS and the Framework Document 1177 The design of the current GTPS, with its designation of preference 1178 based on physical static devices, precludes the need for several 1179 aspects presented in this document. However, one component that can 1180 have a direct correlation is the labeling capability of the proposed 1181 Resource Priority extension to SIP. In the case of GTPS, one simply 1182 needs to define a new NameSpace that will define values for each of 1183 its three Categories of users. These new labels will then allow a 1184 more transparant interoperation between IP telephony using SIP and 1185 the U.K. PSTN that supports GTPS. 1187 Restricting outbound call establishment within the context of IP 1188 telephony and SIP servers is a policy issue. Service Level Agree- 1189 ments, presumably under the guidance or direction of local laws and 1190 regulations would determine the characteristics of the policy. 1192 9. Appendix B: Related Standards Work 1194 The process of defining various labels to distinguish calls has been, 1195 and continues to be, pursued in other standards groups. As mentioned 1196 in section 1.1.1, the ANSI T1S1 group has previously defined a label 1197 SS7 ISUP Initial Address Message. This single label or value is 1198 referred to as the National Security and Emergency Preparedness 1199 (NS/EP) indicator and is part of the T1.631 standard. The following 1200 subsections presents a snap shot of parallel on-going efforts in 1201 various standards groups. 1203 It is important to note that the recent activity in other groups have 1204 gravitated to defining 5 labels or levels of priority. The impact of 1205 this approach is minimal in relation to this IEPS framework document 1206 because it simply generates a requirement to define and register with 1207 IANA a new NameSpace in the Resource-Priority header of SIP. 1209 9.1. Study Group 16 (ITU) 1211 Study Group 16 (SG16) of the ITU is responsible for studies relating 1212 to multimedia service definition and multimedia systems, including 1213 protocols and signal processing. 1215 A draft contribution [35] has been introduced into this group that 1216 would add a Priority Class parameter to the call establishment mes- 1217 sages of H.323. This class is further divided into two parts; one 1218 for Priority Value and the other is a Priority Extension for indicat- 1219 ing subclasses. It is this former part that roughly corresponds to 1220 the labels transported via the Resource Priority field for SIP [15]. 1222 The draft recommendation advocates defining PriorityClass information 1223 that would be carried in the GenericData parameter in the H323-UU-PDU 1224 or RAS messages. The GenericData parameter contains Priori- 1225 tyClassGenericData. The PriorityClassInfo of the PriorityClassGener- 1226 icData contains the Priority and Priority Extension fields. 1228 At present, 5 levels have been defined for the Priority Value part of 1229 the Priority Class parameter: Low, Normal, High, Emergency-Public, 1230 Emergency-Authorized. An additional 8-bit priority extension has been 1231 defined to provide for subclasses of service at each priority. 1233 The suggested ASN.1 definition of the service class is the following: 1235 ServiceClassInfo ::= SEQUENCE 1236 { 1237 priority CHOICE 1238 { 1239 emergencyAuthorized NULL, 1240 emergencyPublic NULL, 1241 high NULL, 1242 normal NULL, 1243 low NULL 1244 } 1245 priorityExtension INTEGER (0..255) OPTIONAL; 1246 requiredClass NULL OPTIONAL 1247 tokens SEQUENCE OF ClearToken OPTIONAL 1248 cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL 1249 } 1251 The advantage in using the GenericData parameter is that an existing 1252 parameter is used, as opposed to defining a new parameter and causing 1253 subsequent changes in existing H.323/H.225 documents. 1255 9.2. Study Group 11 (ITU) 1257 To Be Done... 1259 9.3. T1S1 (ANSI) 1261 To Be Done... 1263 10. Acknowledgments 1265 The authors would like to acknowledge the helpful comments, opinions, 1266 and clarifications of Stu Goldman, James Polk, Dennis Berg, as well 1267 as those comments received from the IEPS and IEPREP mailing lists. 1268 Additional thanks to Peter Walker of Oftel for private discussions on 1269 the operation of GTPS, and Gary Thom on clarifications of the SG16 1270 draft contribution. 1272 11. Author's Addresses 1274 Ken Carlberg Ian Brown 1275 University College London University College London 1276 Department of Computer Science Department of Computer Science 1277 Gower Street Gower Street 1278 London, WC1E 6BT London, WC1E 6BT 1279 United Kingdom United Kingdom 1280 Table of Contents 1282 1. Introduction ................................................... 2 1283 1.1 Emergency Related Data ....................................... 3 1284 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3 1285 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 5 1286 1.2 Scope of this Document ....................................... 5 1287 2. Objective ..................................................... 7 1288 3. Value Added Objective ......................................... 10 1289 3.1 Alternate Path Routing ....................................... 10 1290 3.2 End-to-End Fault Tolerance ................................... 12 1291 4. Functional Requirements ....................................... 12 1292 4.1 Signaling & State Information ................................ 13 1293 4.1.1 SIP ........................................................ 13 1294 4.1.2 Diff-Serv .................................................. 14 1295 4.1.3 RTP ........................................................ 16 1296 4.1.4 MEGACO/H.248 ............................................... 17 1297 4.2 Policy ....................................................... 18 1298 4.3 Traffic Engineering .......................................... 18 1299 4.4 Security ..................................................... 19 1300 5. Key Scenarios ................................................. 20 1301 6. Security Considerations ....................................... 22 1302 7. References .................................................... 22 1303 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 25 1304 8.1 GTPS and the Framework Document .............................. 26 1305 9. Appendix B: Related Standards Work ............................ 26 1306 9.1 Study Group 16 (ITU) ......................................... 27 1307 9.2 Study Group 11 (ITU) ......................................... 28 1308 9.3 T1S1 (ANSI) .................................................. 28 1309 10. Acknowledgments .............................................. 28 1310 11. Author's Addresses ........................................... 28 1312 Full Copyright Statement 1314 "Copyright (C) The Internet Society (date). All Rights Reserved. 1315 This document and translations of it may be copied and furnished to 1316 others, and derivative works that comment on or otherwise explain it 1317 or assist in its implementation may be prepared, copied, published 1318 and distributed, in whole or in part, without restriction of any 1319 kind, provided that the above copyright notice and this paragraph are 1320 included on all such copies and derivative works. However, this 1321 document itself may not be modified in any way, such as by removing 1322 the copyright notice or references to the Internet Society or other 1323 Internet organizations, except as needed for the purpose of develop- 1324 ing Internet standards in which case the procedures for copyrights 1325 defined in the Internet Standards process must be followed, or as 1326 required to translate it into languages other than English. 1328 The limited permissions granted above are perpetual and will not be 1329 revoked by the Internet Society or its successors or assigns. 1331 This document and the information contained herein is provided as an 1332 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1333 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1334 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1335 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- 1336 CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.