idnits 2.17.1 draft-ietf-ieprep-framework-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 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 1133: '...xtension INTEGER (0..255) OPTIONAL,...' RFC 2119 keyword, line 1134: '...SEQUENCE OF ClearToken OPTIONAL,...' RFC 2119 keyword, line 1135: '... SEQUENCE OF CryptoToken OPTIONAL,...' RFC 2119 keyword, line 1142: '... } OPTIONAL, -- Only used...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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? '2' on line 90 looks like a reference -- Missing reference section? '3' on line 67 looks like a reference -- Missing reference section? '4' on line 69 looks like a reference -- Missing reference section? '5' on line 69 looks like a reference -- Missing reference section? '6' on line 79 looks like a reference -- Missing reference section? '7' on line 79 looks like a reference -- Missing reference section? '8' on line 87 looks like a reference -- Missing reference section? '9' on line 112 looks like a reference -- Missing reference section? '10' on line 710 looks like a reference -- Missing reference section? '11' on line 124 looks like a reference -- Missing reference section? '12' on line 125 looks like a reference -- Missing reference section? '30' on line 142 looks like a reference -- Missing reference section? '13' on line 160 looks like a reference -- Missing reference section? '18' on line 164 looks like a reference -- Missing reference section? '14' on line 774 looks like a reference -- Missing reference section? '31' on line 204 looks like a reference -- Missing reference section? '32' on line 204 looks like a reference -- Missing reference section? '38' on line 241 looks like a reference -- Missing reference section? '39' on line 293 looks like a reference -- Missing reference section? '40' on line 293 looks like a reference -- Missing reference section? '15' on line 1099 looks like a reference -- Missing reference section? '16' on line 346 looks like a reference -- Missing reference section? '20' on line 383 looks like a reference -- Missing reference section? '44' on line 385 looks like a reference -- Missing reference section? '29' on line 466 looks like a reference -- Missing reference section? '23' on line 486 looks like a reference -- Missing reference section? '17' on line 520 looks like a reference -- Missing reference section? '36' on line 795 looks like a reference -- Missing reference section? '33' on line 542 looks like a reference -- Missing reference section? '41' on line 550 looks like a reference -- Missing reference section? '43' on line 677 looks like a reference -- Missing reference section? '19' on line 719 looks like a reference -- Missing reference section? '22' on line 721 looks like a reference -- Missing reference section? '42' on line 734 looks like a reference -- Missing reference section? '24' on line 772 looks like a reference -- Missing reference section? '25' on line 772 looks like a reference -- Missing reference section? '37' on line 887 looks like a reference -- Missing reference section? '35' on line 1094 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 41 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Ken Carlberg 2 INTERNET DRAFT G11 3 Oct 19, 2004 Ian Brown 4 UCL 5 Cory Beard 6 UMKC 8 Framework for Supporting Emergency Telecommunications Service 9 (ETS) in IP Telephony 10 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document presents a framework for supporting authorized 40 emergency related communication within the context of IP telephony. 41 We present a series of objectives that reflect a general view of how 42 authorized emergency service, in line with the Emergency 43 Telecommunications Service (ETS), should be realized within today's 44 IP architecture and service models. From these objectives, we 45 present a corresponding set of protocols and capabilities, which 46 provide a more specific set of recommendations regarding existing 47 IETF protocols. Finally, we present two scenarios that act as 48 guiding models for the objectives and functions listed in this 49 document. These, models, coupled with an example of an existing 50 service in the PSTN, contribute to a constrained solution space. 52 1. Introduction 54 The Internet has become the primary target for worldwide communica- 55 tions. This is in terms of recreation, business, and various ima- 56 ginative reasons for information distribution. A constant fixture in 57 the evolution of the Internet has been the support of Best Effort as 58 the default service model. Best Effort, in general terms, implies 59 that the network will attempt to forward traffic to the destination 60 as best as it can with no guarantees being made, nor any resources 61 reserved, to support specific measures of Quality of Service (QoS). 62 An underlying goal is to be "fair" to all the traffic in terms of the 63 resources used to forward it to the destination. 65 In an attempt to go beyond best effort service, [2] presented an 66 overview of Integrated Services (int-serv) and its inclusion into the 67 Internet architecture. This was followed by [3], which specified the 68 RSVP signaling protocol used to convey QoS requirements. With the 69 addition of [4] and [5], specifying controlled load (bandwidth 70 bounds) and guaranteed service (bandwidth & delay bounds) respec- 71 tively, a design existed to achieve specific measures of QoS for an 72 end-to-end flow of traffic traversing an IP network. In this case, 73 our reference to a flow is one that is granular in definition and 74 applying to specific application sessions. 76 From a deployment perspective (as of the date of this document), 77 int-serv has been predominantly constrained to intra-domain paths, at 78 best resembling isolated "island" reservations for specific types of 79 traffic (e.g., audio and video) by stub domains. [6] and [7] will 80 probably contribute to additional deployment of int-serv to Internet 81 Service Providers (ISP) and possibly some inter-domain paths, but it 82 seems unlikely that the original vision of end-to-end int-serv 83 between hosts in source and destination stub domains will become a 84 reality in the near future (the mid- to far-term is a subject for 85 others to contemplate). 87 In 1998, the IETF produced [8], which presented an architecture for 88 Differentiated Services (diff-serv). This effort focused on a more 89 aggregated perspective and classification of packets than that of 90 [2]. This is accomplished with the recent specification of the 91 diff-serv field in the IP header (in the case of IPv4, it replaced 92 the old ToS field). This new field is used for code points 93 established by IANA, or set aside as experimental. It can be 94 expected that sets of microflows, a granular identification of a set 95 of packets, will correspond to a given code point, thereby achieving 96 an aggregated treatment of data. 98 One constant in the introduction of new service models has been the 99 designation of Best Effort as the default service model. If traffic 100 is not, or cannot be, associated as diff-serv or int-serv, then it is 101 treated as Best Effort and uses what resources are made available to 102 it. 104 Beyond the introduction of new services, the continued pace of addi- 105 tional traffic load experienced by ISPs over the years has continued 106 to place a high importance for intra-domain traffic engineering. The 107 explosion of IETF contributions, in the form of drafts and RFCs pro- 108 duced in the area of Multi Protocol Label Switching (MPLS), exempli- 109 fies the interest in versatile and manageable mechanisms for intra- 110 domain traffic engineering. One interesting observation is the work 111 involved in supporting QoS related traffic engineering. Specifically, 112 we refer to MPLS support of differentiated services [9], and the on- 113 going work in the inclusion of fast bandwidth recovery of routing 114 failures for MPLS [10]. 116 1.1. Emergency Related Data 118 The evolution of the IP service model architecture has traditionally 119 centered on the type of application protocols used over a network. 120 By this we mean that the distinction, and possible bounds on QoS, 121 usually centers on the type of application (e.g., audio video tools) 122 that is being referred to. 124 [11] has defined a priority field for SMTP, but it is only for map- 125 ping with X.400 and is not meant for general usage. SIP [12] has an 126 embedded field denoting "priority", but it is only targeted towards 127 the end-user and is not meant not provide indication to the underly- 128 ing network or end-to-end applications. 130 Given the emergence of IP telephony, a natural inclusion of its ser- 131 vice is an ability to support existing emergency related services. 132 Typically, one associates emergency calls with "911" telephone ser- 133 vice in the U.S., or "999" in the U.K. -- both of which are attri- 134 buted to national boundaries and accessible by the general public. 135 Outside of this exists emergency telephone services that involved 136 authorized usage, as described in the following subsection. 138 1.1.1. Government Emergency Telecommunications Service (GETS) 140 GETS is an emergency telecommunications service available in the U.S. 141 and overseen by the National Communications System (NCS) -- an office 142 established by the White House under an executive order [30] and now 143 a part of the Department of Homeland Security . Unlike "911", it is 144 only accessible by authorized individuals. The majority of these 145 individuals are from various government agencies like the Department 146 of Transportation, NASA, the Department of Defense, and the Federal 147 Emergency Management Agency (to name but a few). In addition, a 148 select set of individuals from private industry (telecommunications 149 companies, utilities, etc.) that are involved in criticial infras- 150 tructure recovery operations are also provided access to GETS. 152 The purpose of GETS is to achieve a high probability that phone ser- 153 vice will be available to selected authorized personnel in times of 154 emergencies, such as hurricanes, earthquakes, and other disasters 155 that may produce a burden in the form of call blocking (i.e., conges- 156 tion) on the U.S. Public Switched Telephone Network by the general 157 public. 159 GETS is based in part on the ANSI T1.631 standard, specifying a High 160 Probability of Completion (HPC) for SS7 signaling [13]. 162 1.1.2. International Emergency Preparedness Scheme (IEPS) 164 [18] is a recent ITU standard that describes emergency related com- 165 munications over international telephone service. While systems like 166 GETS are national in scope, IEPS acts as an extension to local or 167 national authorized emergency call establishment and provides a 168 building block for a global service. 170 As in the case of GETS, IEPS promotes mechanisms like extended queu- 171 ing, alternate routing, and exemption from restrictive management 172 controls in order to increase the probability that international 173 emergency calls will be established. The specifics of how this is to 174 be accomplished are to be defined in future ITU document(s). 176 1.2. Scope of this Document 178 The scope of this document centers on the near and mid-term support 179 of ETS within the context of IP telephony versus simply Voice over 180 IP. We make a distinction between these two by treating IP telephony 181 as a subset of VoIP, where in the former case we assume some form of 182 application layer signaling is used to explicitly establish and main- 183 tain voice data traffic. This explicit signaling capability provides 184 the hooks from which VoIP traffic can be bridged to the PSTN. 186 An example of this distinction is when the Robust Audio Tool (RAT) 187 [14] begins sending VoIP packets to a unicast (or multicast) destina- 188 tion. RAT does not use explicit signaling like SIP to establish an 189 end-to-end call between two users. It simply sends data packets to 190 the target destination. On the other hand, "SIP phones" are host 191 devices that use a signaling protocol to establish a call before 192 sending data towards the destination. 194 One other aspect we should probably assume exists with IP Telephony 195 is an association of a target level of QoS per session or flow. [31] 196 makes an argument that there is a maximum packet loss and delay for 197 VoIP traffic, and both are interdependent. For delays of ~200ms, a 198 corresponding drop rate of 5% is deemed acceptable. When delay is 199 lower, a 15-20% drop rate can be experienced and still considered 200 acceptable. [32] discusses the same topic and makes an arguement 201 that packet size plays a significant role in what users tolerate as 202 "intelligible" VoIP. The larger the packet, correlating to longer 203 sampling rate, the lower the acceptable rate of loss. Note that 204 [31,32] provide only two of several perspectives in examining VoIP. 205 A more indepth discussion on this topic is outside the scope of this 206 document, though it should be noted that the choice of codec can sig- 207 nificantly alter the above results. 209 Regardless of a single and definitive characteristic for stressed 210 conditions, it would seem that interactive voice has a lower thres- 211 hold of some combinations of loss/delay/jitter than elastic applica- 212 tions such as email or web browsers. This places a higher burden on 213 the problem space of supporting VoIP over the Internet. This problem 214 is further compounded when toll-quality service is expected because 215 it assumes a default service model that is better than best effort. 216 This in turn can increase the probability that a form of call- 217 blocking can occur with VoIP or IP telephony traffic. 219 Beyond this, part of our motivation in writing this document is to 220 provide a framework for ISPs and telephony carriers so that they have 221 an understanding of objectives used to support ETS related IP 222 telephony traffic. In addition, we also wish to provide a reference 223 point for potential customers in order to constrain their expecta- 224 tions. In particular, we wish to avoid any temptation of trying to 225 replicate the exact capabilities of existing emergency voice service 226 currently available in the PSTN to that of IP and the Internet. If 227 nothing else, intrinsic differences between the two communications 228 architectures precludes this from happening. Note, this does not 229 prevent us from borrowing design concepts or objectives from existing 230 systems. 232 Section 2 presents several primary objectives that articulate what is 233 considered important in supporting ETS related IP telephony traffic. 234 These objectives represent a generic set of goals and desired capa- 235 bilities. Section 3 presents additional value added objectives, 236 which are viewed as useful, but not critical. Section 4 presents 237 protocols and capabilities that relate or can play a role in support 238 of the objectives articulated in section 2. Finally, Section 5 239 presents two scenarios that currently exist or are being deployed in 240 the near term over IP networks. These are not all-inclusive 241 scenarios, nor are they the only ones that can be articulated ([38] 242 provides a more extensive discussion on the topology scenarios 243 related to IP telephony). However, these scenarios do show cases 244 where some of the protocols discussed in section 4 apply, and where 245 some do not. 247 Finally, we need to state that this document focuses its attention on 248 the IP layer and above. Specific operational procedures pertaining 249 to Network Operation Centers (NOC) or Network Information Centers 250 (NIC) are outside the scope of this document. This includes the 251 "bits" below IP, other specific technologies, and service level 252 agreements between ISPs and telephony carriers with regard to dedi- 253 cated links. 255 2. Objective 257 The objective of this document is to present a framework that 258 describes how various protocols and capabilities (or mechanisms) can 259 be used to facilitate and support the traffic from ETS users. In 260 several cases, we provide a bit of background in each area so that 261 the reader is given some context and more indepth understanding. We 262 also provide some discussion on aspects about a given protocol or 263 capability that could be explored and potentially advanced to support 264 ETS. This exploration is not to be confused with specific solutions 265 since we do not articulate exactly what must be done (e.g., a new 266 header field, or a new code point). 268 3. Considerations 270 When producing a solution, or examining existing protocols and 271 mechanisms, there are some things that should be considered. One is 272 that inter-domain ETS communications should not rely on ubiquitous or 273 even wide-spread support along the path between the end points. 274 Potentially, at the network layer there may exist islands of support 275 realized in the form of overlay networks. There may also be cases 276 where solutions may be constrained on an end-to-end basis (i.e., at 277 the transport or application layer). It is this diversity and 278 possibly partial support that need to be taken into account by those 279 designing and deploying ETS related solutions. 281 Another aspect to consider is that there are existing architectures 282 and protocols from other standards bodies that support emergency 283 related communications. The effort in interoperating with these sys- 284 tems, presumably through gateways or similar type nodes with IETF 285 protocols, would foster a need to distinguish ETS flows from other 286 flows. One reason would be the scenario of triggering ETS service 287 from an IP network. 289 Finally, we take into consideration the requirements of [39, 40] in 290 discussing the protocols and mechanisms below in Section 4. In doing 291 this, we do not make a one-to-one mapping of protocol discussion with 292 requirement. Rather, we make sure the discussion of Section 4 does 293 not violet any of the requirements in [39,40]. 295 4. Protocols and Capabilities 297 In this section, we take the objectives presented above and present a 298 set of protocols and capabilities that can be used to achieve them. 299 Given that the objectives are predominantly atomic in nature, the 300 measures used to address them are to be viewed separately with no 301 specific dependency upon each other as a whole. Various protocols 302 and capabilities may be complimentary to each other, but there is no 303 need for all to exist given different scenarios of operation, and 304 that ETS support is not expected to be a ubiquitously available ser- 305 vice. We divide this section into 5 areas: 307 1) Signaling 308 2) Policy 309 3) Traffic Engineering 310 4) Security 311 5) Routing 313 4.1. Signaling & State Information 315 Signaling is used to convey various information to either intermedi- 316 ate nodes or end nodes. It can be out-of-band of a data flow, and 317 thus in a separate flow of its own, such as SIP messages. It can be 318 in-band and part of the state information in a datagram containing 319 the voice data. This latter example could be realized in the form of 320 diff-serv code points in the IP packet. 322 In the following subsections, we discuss the current state of some 323 protocols and their use in providing support for ETS. We also 324 discuss potential augmentations to different types of signaling and 325 state information to help support the distinction of emergency 326 related communications in general. 328 4.1.1. SIP 330 With respect to application level signaling for IP telephony, we 331 focus our attention to the Session Initiation Protocol (SIP). 332 Currently, SIP has an existing "priority" field in the Request- 333 Header-Field that distinguishes different types of sessions. The 334 five currently defined values are: "emergency", "urgent", "normal", 335 "non-urgent", "other-priority". These values are meant to convey 336 importance to the end-user and have no additional sematics associated 337 with them. 339 [15] is an RFC that defines the requirements for a new header field 340 for SIP in reference to resource priority. The requirements are 341 meant to lead to a means of providing an additional measure of dis- 342 tinction that can influence the behavior of gateways and SIP proxies. 344 4.1.2. Diff-Serv 346 In accordance with [16], the differentiated services code point 347 (DSCP) field is divided into three sets of values. The first set is 348 assigned by IANA. Within this set, there are currently, three types 349 of Per Hop Behaviors that have been specified: Default (correlating 350 to best effort forwarding), Assured Forwarding, and Expedited For- 351 warding. The second set of DSCP values are set aside for local or 352 experimental use. The third set of DSCP values are also set aside 353 for local or experimental use, but may later be reassigned to IANA in 354 case the first set has been completely assigned. 356 One approach discussed on the IEPREP mailing list is the specifica- 357 tion of a new Per-Hop Behaviour (PHB) for emergency related flows. 358 The rationale behind this idea is that it would provide a baseline by 359 which specific code points may be defined for various emergency 360 related traffic: authorized emergency sessions (e.g., ETS), general 361 public emergency calls (e.g., "911"), Multi-Level Precedence and 362 Preemption (MLPP), etc. However, in order to define a new set of 363 code points, a forwarding characteristic must also be defined. In 364 other words, one cannot simply identify a set of bits without defin- 365 ing their intended meaning (e.g.,the drop precedence approach of 366 Assured Forwarding). The one caveat to this statement are the set of 367 DSCP bits set aside for experimental purposes. But as the name 368 implies, experimental is for internal examination and use and not for 369 standardization. 371 Comments 372 -------- 374 It is important to note that as of the time that this document was 375 written, the IETF has been taking a conservative approach in specify- 376 ing new PHBs. This is because the number of code points that can be 377 defined is relatively small and understandably considered a scarce 378 resource. Therefore, the possibility of a new PHB being defined for 379 emergency related traffic is at best a long term project that may or 380 may not be accepted by the IETF. 382 In the near term, we would initially suggest using the Assured For- 383 warding (AF) PHB [20] for distinguishing emergency traffic from other 384 types of flows. At a minimum, AF could be used for the different SIP 385 call signaling messages. If the Expedited Forwarding (EF) PHB [44] 386 was also supported by the domain, then it would be used for IP 387 telephony data packets. Otherwise, another AF class would be used 388 for those data flows. 390 4.1.3. Variations Related to Diff-Serv and Queuing 392 Scheduling mechanisms like Weighted Fair Queueing and Class Based 393 Queueing are used to designate a percentage of the output link 394 bandwidth that would be used for each class if all queues were back- 395 logged. Its purpose, therefore, it to manage the rates and delays 396 experienced by each class. But emergency traffic may not necessarily 397 require QoS any better or different than non-emergency traffic. It 398 may just need higher probability of being forwarded to the next hop, 399 which could be accomplished simply through drop precedences within a 400 class. 402 To implement preferential dropping between classes of traffic, one of 403 which being emergency traffic, one would probably need to use a more 404 advanced form of Active Queue Management (AQM). Current implementa- 405 tions use an overall queue fill measurement to make decisions; this 406 might cause emergency classified packets to be dropped. One new from 407 of AQM could be a Multiple Average-Multiple Threshold approach, 408 instead of the Single Average-Multiple Threshold approach used today. 409 This allows creation of drop probabilities based on counting the 410 number of packets in the queue for each drop precedence individually. 412 So, it could be possible to use the current set of AF PHBs if each 413 class where reasonably homogenous in the traffic mix. But one might 414 still have a need to be able to differentiate three drop precedences 415 just within non-emergency traffic. If so, more drop precedences 416 could be implemented. Also, if one wanted discrimination within 417 emergency traffic, as with MLPPs five levels of precedence, more drop 418 precedences might also be considered. The five levels would also 419 correlate to a recent effort in the Study Group 11 of the ITU to 420 define 5 levels for Emergency Telecommunications Service. 422 4.1.4. RTP 424 The Real-Time Transport Protocol (RTP) provides end-to-end delivery 425 services for data with real-time characteristics. The type of data 426 is generally in the form of audio or video type applications, and are 427 frequently interactive in nature. RTP is typically run over UDP and 428 has been designed with a fixed header that identifies a specific type 429 of payload representing a specific form of application media. The 430 designers of RTP also assumed an underlying network providing best 431 effort service. As such, RTP does not provide any mechanism to 432 ensure timely delivery or provide other QoS guarantees. However, the 433 emergence of applications like IP telephony, as well as new service 434 models, presents new environments where RTP traffic may be forwarded 435 over networks that support better than best effort service. Hence, 436 the original scope and target environment for RTP has expanded to 437 include networks providing services other than best effort. 439 In 4.1.2, we discussed one means of marking a data packet for emer- 440 gencies under the context of the diff-serv architecture. However, we 441 also pointed out that diff-serv markings for specific PHBs are not 442 globally unique, and may be arbitrarily removed or even changed by 443 intermediary nodes or domains. Hence, with respect to emergency 444 related data packets, we are still missing an in-band marking in a 445 data packet that stays constant on an end-to-end basis. 447 There are three choices in defining a persistent marking of data 448 packets and thus avoiding the transitory marking of diff-serv code 449 points. One can propose a new PHB dedicated for emergency type 450 traffic as discussed in 4.1.2. One can propose a specification of a 451 new shim layer protocol at some location above IP. Or, one can add a 452 new specification to an existing application layer protocol. The 453 first two cases are probably the "cleanest" architecturally, but they 454 are long term efforts that may not come to pass because of a limited 455 amount of diff-serv code points and the contention that yet another 456 shim layer will make the IP stack too large. The third case, placing 457 a marking in an application layer packet, also has drawbacks; the key 458 weakness being the specification of a marking on a per-application 459 basis. 461 Discussions have been held in the Audio/Visual Transport (AVT) work- 462 ing group of augmenting RTP so that it can carry a marking that dis- 463 tinguishes emergency-related traffic from that which is not. Specif- 464 ically, these discussions centered on defining a new extention that 465 contains a "classifier" field indicating the condition associated 466 with the packet (e.g., authorized-emergency, emergency, normal) [29]. 467 The rationale behind this idea was that focusing on RTP would allow 468 one to rely on a point of aggregation that would apply to all pay- 469 loads that it encapsulates. However, the AVT group has expressed a 470 rough consensus that placing additional classifier state in the RTP 471 header to denote the importance of one flow over another is not an 472 approach that they wish to advance. Objections ranging from relying 473 on SIP to convey importance of a flow, as well as the possibility of 474 adversely affecting header compression, were expressed. There was 475 also the general feeling that the extension header for RTP that acts 476 as a signal should not be used. 478 4.1.5. GCP/H.248 480 The Gateway Control Protocol (GCP) [23] defines the interaction 481 between a media gateway and a media gateway controller. [23] is 482 viewed as an updated version of common text with ITU-T Recommendation 483 H.248 and is a result of applying the changes of RFC 2886 (Megaco 484 Errata) to the text of RFC 2885 (Megaco Protocol version 0.8). 486 In [23], the protocol specifies a Priority and Emergency field for a 487 context attribute and descriptor. The Emergency is an optional 488 boolean (True or False) condition. The Priority value, which ranges 489 from 0 through 15, specifies the precedence handling for a context. 491 The protocol does not specify individual values for priority. We 492 also do not recommend the definition of a well known value for the 493 GCP priority -- that is out of scope of this document. Any values 494 set should be a function of any SLAs that have been established 495 regarding the handling of emergency traffic. 497 4.2. Policy 499 One of the objectives listed in section 3 above is to treat ETS- sig- 500 naling, and related data traffic, as non-preemptive in nature. 501 Further, that this treatment is to be the default mode of operation 502 or service. This is in recognition that existing regulations or laws 503 of certain countries governing the establishment of SLAs may not 504 allow preemptive actions (e.g., dropping existing telephony flows). 505 On the other hand, the laws and regulations of other countries 506 influencing the specification of SLA(s) may allow preemption, or even 507 require its existence. Given this disparity, we rely on local policy 508 to determine the degree by which emergency related traffic affects 509 existing traffic load of a given network or ISP. Important note: we 510 reiterate our earlier comment that laws and regulations are generally 511 outside the scope of the IETF and its specification of designs and 512 protocols. However, these constraints can be used as a guide in pro- 513 ducing a baseline capability to be supported; in our case, a default 514 policy for non-preemptive call establishment of ETS signaling and 515 data. 517 Policy can be in the form of static information embedded in various 518 components (e.g., SIP servers or bandwidth brokers), or it can be 519 realized and supported via COPS with respect to allocation of a 520 domain's resources [17]. There is no requirement as to how policy is 521 accomplished. Instead, if a domain follows actions outside of the 522 default non-preemptive action of ETS related communication, then we 523 stipulate that some type of policy mechanism is in place to satisfy 524 the local policies of an SLA established for ETS type traffic. 526 4.3. Traffic Engineering 528 In those cases where a network operates under the constraints of 529 SLAs, one or more of which pertains to ETS based traffic, it can be 530 expected that some form of traffic engineering is applied to the 531 operation of the network. We make no recommendations as to which 532 type of traffic engineering mechanism is used, but that such a system 533 exists in some form and can distinguish and support ETS signaling 534 and/or data traffic. We recommend a review of [36] by clients and 535 prospective providers of ETS service, which gives an overview and a 536 set of principles of Internet traffic engineering. 538 MPLS is generally the first protocol that comes to mind when the sub- 539 ject of traffic engineering is brought up. This notion is heightened 540 concerning the subject of IP telephony because of MPLS's ability to 541 permit a quasi-circuit switching capability to be superimposed on the 542 current Internet routing model [33]. 544 However, having cited MPLS, we need to stress that it is an intra- 545 domain protocol, and so may or may not exist within a given ISP. 546 Other forms of traffic engineering, such as weighted OSPF, may be the 547 mechanism of choice by an ISP. 549 As a counter example of using a specific protocol to achieve traffic 550 engineering, [41] presents an example by one ISP relying on a high 551 amount of overprovisioning within its core to satisfy potentially 552 dramatic spikes or bursts of traffic load. In this approach, any 553 configuring of queues for specific customers (neighbors) to support 554 target QoS is done on the egress edge of the transit network. 556 Note: As a point of reference, existing SLAs established by the NCS 557 for GETS service tend to focus on a loosely defined maximum 558 allocation of (e.g., 1% to 10%) of calls allowed to be established 559 through a given LEC using HPC. It is expected, and encouraged, that 560 ETS related SLAs of ISPs will have a limit with respect to the amount 561 of traffic distinguished as being emergency related, and initiated by 562 an authorized user. 564 4.4. Security 566 This section provides a brief overview of the security issues raised 567 by ETS support. 569 4.4.1. Denial of Service 571 Any network mechanism that enables a higher level of priority for a 572 specific set of flows could be abused to enhance the effectiveness of 573 denial of service attacks. Priority would magnify the effects of 574 attack traffic on bandwidth availability in lower-capacity links, and 575 increase the likelihood of it reaching its target(s). An attack could 576 also tie up resources such as circuits in a PSTN gateway. 578 Any provider deploying a priority mechanism (such as the QoS systems 579 described in section 4.1) must therefore carefully apply the associ- 580 ated access controls and security mechanisms. For example, the prior- 581 ity level for traffic originating from an unauthorized part of a net- 582 work or ingress point should be reset to normal. Users must also be 583 authenticated before being allowed to use a priority service (see 584 section 4.4.2). However, this authentication process should be light- 585 weight to minimise opportunities for denial of service attacks on the 586 authentication service itself, and ideally should include its own 587 anti-DoS mechanisms. Other security mechanisms may impose an overhead 588 that should be carefully considered to avoid creating other opportun- 589 ities for DoS attacks. 591 As mentioned in section 4.3, SLAs for ETS facilities often contain 592 maximum limits on the level of ETS traffic that should be prioritised 593 in a particular network (say 1% of the maximum network capacity). 594 This should also be the case in IP networks to again reduce the level 595 of resources that a denial of service attack can consume. 597 As of this writing, a typical inter-provider IP link uses 1 Gbps Eth- 598 ernet, OC-48 SONET/SDH, or some similar or faster technology. Also 599 as of this writing, it is not practical to deploy per-IP packet cryp- 600 tographic authentication on such inter-provider links, although such 601 authentication might well be needed to provide assurance of IP-layer 602 label integrity in the inter-provider scenario. 604 While Moore's Law will speed up cryptographic authentication, it is 605 unclear whether that is helpful because the speed of the typical 606 inter-domain link is also increasing rapidly. 608 4.4.2. User authorization 610 To prevent theft of service and reduce the opportunities for denial 611 of service attacks, it is essential that service providers properly 612 verify the authorization of a specific traffic flow before providing 613 it with ETS facilities. 615 Where an ETS call is carried from PSTN to PSTN via one telephony 616 carrier's backbone IP network, very little IP-specific user authori- 617 zation support is required. The user authenticates themself as usual 618 to the PSTN -- for example, using a PIN in the US GETS. The gateway 619 from the PSTN connection into the backbone IP network must be able to 620 signal that the flow has an ETS label. Conversely, the gateway back 621 into the PSTN must similarly signal the call's label. A secure link 622 between the gateways may be set up using IPSec or SIP security func- 623 tionality to protect the integrity of the signalling information 624 against attackers who have gained access to the backbone network, and 625 prevent such attackers placing ETS calls using the egress PSTN gate- 626 way. If the destination of a call is an IP device, the signalling 627 should be protected directly between the IP ingress gateway and the 628 end device. 630 When ETS priority is being provided to a flow within one domain, that 631 network must use the security features of the priority mechanism 632 being deployed to ensure the flow has originated from an authorized 633 user or process. 635 The access network may authorize ETS traffic over a link as part of 636 its user authentication procedures. These procedures may occur at the 637 link, network or higher layers, but are at the discretion of a single 638 domain network. That network must decide how often it should update 639 its list of authorized ETS users based on the bounds it is prepared 640 to accept on traffic from recently-revoked users. 642 If ETS support moves from intra-domain PSTN and IP networks to 643 inter-domain end-to-end IP, verifying the authorization of a given 644 flow becomes more complex. The user's access network must verify a 645 user's ETS authorization if network-layer priority is to be provided 646 at that point. 648 Administrative domains that agree to exchange ETS traffic must have 649 the means to securely signal to each other a given flow's ETS status. 650 They may use physical link security combined with traffic 651 conditioning measures to limit the amount of ETS traffic that may 652 pass between the two domains. This agreement must require the ori- 653 ginating network to take responsibility for ensuring that only 654 authorized traffic is marked with ETS priority, but the recipient 655 network cannot rely on this happening with 100% reliability. Both 656 domains should perform conditioning to prevent the propagation of 657 theft and denial of service attacks. Note that administrative 658 domains that agree to exchange ETS traffic must deploy facilities 659 that perform these conditioning and security services at every point 660 at which they interconnect with one another. 662 Processes using application-layer protocols such as SIP should use 663 the security functionality in those protocols to verify the authori- 664 zation of a session before allowing it to use ETS mechanisms. 666 4.4.3. Confidentiality and integrity 668 When ETS communications are being used to respond to a deliberate 669 attack, it is important that they cannot be altered or intercepted to 670 worsen the situation -- for example, by changing the orders to first 671 responders such as firefighters or by using knowledge of the emer- 672 gency response to cause further damage. 674 The integrity and confidentiality of such communications should 675 therefore be protected as far as possible using end-to-end security 676 protocols such as IPSec or the security functionality in SIP and SRTP 677 [43]. Where communications involve other types of network such as the 678 PSTN, the IP side should be protected and any security functionality 679 available in the other network should be used. 681 4.5. Alternate Path Routing 683 This subject involves the ability to discover and use a different 684 path to route IP telephony traffic around congestion points and thus 685 avoid them. Ideally, the discovery process would be accomplished in 686 an expedient manner (possibly even a priori to the need of its 687 existence). At this level, we make no assumptions as to how the 688 alternate path is accomplished, or even at which layer it is achieved 689 -- e.g., the network versus the application layer. But this kind of 690 capability, at least in a minimal form, would help contribute to 691 increasing the probability of ETS call completion by making use of 692 noncongested alternate paths. We use the term "minimal form" to 693 emphasize the fact that care must be taken in how the system provides 694 alternate paths so it does not significantly contribute to the 695 congestion that is to be avoided (e.g., via excess control/discovery 696 messages). 698 Routing protocols at the IP network layer, such as BGP and OSPF, 699 contain mechanisms for determining link failure between routing 700 peers. The discovery of this failure automatically causes informa- 701 tion to be propagated to other routers. The form of this informa- 702 tion, the extent of its propagation, and the convergence time in 703 determining new routes is dependent on the routing protocol in use. 704 In the example of OSPF's Equal Cost Multiple Path (ECMP), the impact 705 of link failure is minimized because of pre-existing alternate paths 706 to a destination. 708 At the time that this document was written, we can identify two addi- 709 tional areas in the IETF that can be helpful in providing alternate 710 paths for the specific case of call signaling. The first is [10], 711 which is focused on network layer routing and describes a framework 712 for enhancements to the LDP specification of MPLS to help achieve 713 fault tolerance. This in itself does not provide alternate path 714 routing, but rather helps minimize loss in intradomain connectivity 715 when MPLS is used within a domain. 717 The second effort comes from the IP Telephony working group and 718 involves Telephony Routing over IP (TRIP). To date, a framework 719 document [19] has been published as an RFC which describes the 720 discovery and exchange of IP telephony gateway routing tables between 721 providers. The TRIP protocol [22] specifies application level 722 telephony routing regardless of the signaling protocol being used 723 (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises 724 reachability and attributes of destinations. In its current form, 725 several attributes have already been defined, such as LocalPreference 726 and MultiExitDisc. Additional attributes can be registered with 727 IANA. 729 Inter-domain routing is not an area that should be considered in 730 terms of additional alternate path routing support for ETS. The 731 Border Gateway Protocol is currently strained in meeting its existing 732 requirements, and thus adding additional features that would generate 733 an increase in advertised routes will not be well received by the 734 IETF. Refer to [42] for a commentary on Inter-Domain routing. 736 4.6. End-to-End Fault Tolerance 738 This topic involves the work that has been done in trying to compen- 739 sate for lossy networks providing best effort service. In particu- 740 lar, we focus on the use of a) Forward Error Correction (FEC), and b) 741 redundant transmissions that can be used to compensate for lost data 742 packets. (Note that our aim is fault tolerance, as opposed to an 743 expectation of always achieving it). 745 In the former case, additional FEC data packets are constructed from 746 a set of original data packets and inserted into the end-to-end 747 stream. Depending on the algorithm used, these FEC packets can 748 reconstruct one or more of the original set that were lost by the 749 network. An example may be in the form of a 10:3 ratio, in which 10 750 original packets are used to generate three additional FEC packets. 751 Thus, if the network loses 30% or less number of packets, then the 752 FEC scheme will be able to compensate for that loss. The drawback to 753 this approach is that to compensate for the loss, a steady state 754 increase in offered load has been injected into the network. This 755 makes an arguement that the act of protection against loss has con- 756 tributed to additional pressures leading to congestion, which in turn 757 helps trigger packet loss. In addition, in using a ratio of 10:3, 758 the source (or some proxy) must "hold" all 10 packets in order to 759 construct the three FEC packets. This contributes to the end-to-end 760 delay of the packets as well as minor bursts of load in addition to 761 changes in jitter. 763 The other form of fault tolerance we discuss involves the use of 764 redundant transmissions. By this we mean the case in which an origi- 765 nal data packet is followed by one or more redundant packets. At 766 first glance, this would appear to be even less friendly to the net- 767 work than that of adding FEC packets. However, the encodings of the 768 redundant packets can be of a different type (or even transcoded into 769 a lower quality) that produce redundant data packets that are signi- 770 ficantly smaller than the original packet. 772 Two RFCs [24, 25] have been produced that define RTP payloads for FEC 773 and redundant audio data. An implementation example of a redundant 774 audio application can be found in [14]. We note that both FEC and 775 redundant transmissions can be viewed as rather specific and to a 776 degree tangential solutions regarding packet loss and emergency com- 777 munications. Hence, these topics are placed under the category of 778 value added objectives. 780 5. Key Scenarios 782 There are various scenarios in which IP telephony can be realized, 783 each of which can imply a unique set of functional requirements that 784 may include just a subset of those listed above. We acknowledge that 785 a scenario may exist whose functional requirements are not listed 786 above. Our intention is not to consider every possible scenario by 787 which support for emergency related IP telephony can be realized. 788 Rather, we narrow our scope using a single guideline; we assume there 789 is a signaling & data interaction between the PSTN and the IP network 790 with respect to supporting emergency-related telephony traffic. We 791 stress that this does not preclude an IP-only end-to-end model, but 792 rather the inclusion of the PSTN expands the problem space and 793 includes the current dominant form of voice communication. 795 Note: as stated in section 1.2, [36] provides a more extensive set of 796 scenarios in which IP telephony can be deployed. Our selected set 797 below is only meant to provide an couple of examples of how the pro- 798 tocols and capabilities presented in Section 3 can play a role. 800 Single IP Administrative Domain 801 ------------------------------- 803 This scenario is a direct reflection of the evolution of the PSTN. 804 Specifically, we refer to the case in which data networks have 805 emerged in various degrees as a backbone infrastructure connecting 806 PSTN switches at its edges. This scenario represents a single iso- 807 lated IP administrative domain that has no directly adjacent IP 808 domains connected to it. We show an example of this scenario below 809 in Figure 1. In this example, we show two types of telephony car- 810 riers. One is the legacy carrier, whose infrastructure retains the 811 classic switching architecture attributed to the PSTN. The other is 812 the next generation carrier, which uses a data network (e.g., IP) as 813 its core infrastructure, and Signaling Gateways at its edges. These 814 gateways "speak" SS7 externally with peering carriers, and another 815 protocol (e.g., SIP) internally, which rides on top of the IP infras- 816 tructure. 818 Legacy Next Generation Next Generation 819 Carrier Carrier Carrier 820 ******* *************** ************** 821 * * * * ISUP * * 822 SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG 823 * * (SS7) * (SIP) * (SS7) * (SIP) * 824 ******* *************** ************** 826 SW - Telco Switch, SG - Signaling Gateway 828 Figure 1 830 The significant aspect of this scenario is that all the resources of 831 each IP "island" fall within a given administrative authority. 832 Hence, there is not a problem of retaining toll quality Quality of 833 Service as the voice traffic (data and signaling) exits the IP net- 834 work because of the existing SS7 provisioned service between 835 telephony carriers. Thus, the need for support of mechanisms like 836 diff-serv in the presence of overprovisioning, and an expansion of 837 the defined set of Per-Hop Behaviors, is reduced under this scenario. 839 Another function that has little or no importance within the closed 840 IP environment of Figure 1 is that of IP security. The fact that 841 each administrative domain peers with each other as part of the PSTN, 842 means that existing security, in the form of Personal Identification 843 Number (PIN) authentication (under the context of telephony infras- 844 tructure protection), is the default scope of security. We do not 845 claim that the reliance on a PIN based security system is highly 846 secure or even desirable. But, we use this system as a default 847 mechanism in order to avoid placing additional requirements on exist- 848 ing authorized emergency telephony systems. 850 Multiple IP Administrative Domains 851 ---------------------------------- 853 We view the scenario of multiple IP administrative domains as a 854 superset of the previous scenario. Specifically, we retain the 855 notion that the IP telephony system peers with the existing PSTN. In 856 addition, segments 858 (i.e., portions of the Internet) may exchange signaling with other IP 859 administrative domains via non-PSTN signaling protocols like SIP. 861 Legacy Next Generation Next Generation 862 Carrier Carrier Carrier 863 ******* *************** ************** 864 * * * * * * 865 SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG 866 * * (SS7) * (SIP) * (SIP) * (SIP) * 867 ******* *************** ************** 869 SW - Telco Switch 870 SG - Signaling Gateway 872 Figure 2 874 Given multiple IP domains, and the presumption that SLAs relating to 875 ETS traffic may exist between them, the need for something like 876 diff-serv grows with respect to being able to distinguish the emer- 877 gency related traffic from other types of traffic. In addition, IP 878 security becomes more important between domains in order to ensure 879 that the act of distinguishing ETS-type traffic is indeed valid for 880 the given source. 882 We conclude this section by mentioning a complimentary work in pro- 883 gress in providing ISUP transparency across SS7-SIP interworking 884 [37]. The objective of this effort is to access services in the SIP 885 network and yet maintain transparency of end-to-end PSTN services. 887 Not all services are mapped (as per the design goals of [37]), so we 888 anticipate the need for an additional document to specify the mapping 889 between new SIP labels and existing PSTN code points like NS/EP and 890 MLPP. 892 6. Security Considerations 894 Information on this topic is presented in sections 2 and 4. 896 7. References 898 This is an informational document. The following are Informative 899 References, and there are no Normative References. 901 1 Bradner, S., "Intellectual Property Rights in IETF Technology", 902 BCP 79, RFC 3668, February 2004 904 2 Braden, R., et. al., "Integrated Services in the Internet 905 Architecture: An Overview", Informational, RFC 1633, June 1994. 907 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 908 Version 1, Functional Specification", Proposed Standard, RFC 909 2205, Sept. 1997. 911 4 Shenker, S., et. al., "Specification of Guaranteed Quality of 912 Service", Proposed Standard, RFC 2212, Sept 1997. 914 5 Wroclawski, J., "Specification for Controlled-Load Network 915 Service Element", Proposed Standard, RFC 2211, Sept 1997. 917 6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 918 Reservations", Proposed Standard, RFC 3175, September 2001. 920 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 921 Proposed Standard, RFC 2961, April, 2001. 923 8 Blake, S., et. al., "An Architecture for Differentiated 924 Service", Proposed Standard, RFC 2475, Dec. 1998. 926 9 Faucheur, F., et. al., "MPLS Support of Differentiated Services", 927 Standards Track, RFC 3270, May 2002. 929 10 Sharma, V., Hellstrand, F., "Framework for MPLS-Based Recovery", 930 Informational, RFC 3469, February 2003 932 11 Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 933 between X.400 and RFC 822/MIME", Proposed Standard, RFC 2156, 934 January 1998. 936 12 Rosenberg, J., et. al., "SIP: Session Initiation Protocol", 937 Proposed Standard, RFC 3261, June 2002. 939 13 ANSI, "Signaling System No. 7(SS7), High Probability of 940 Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999). 942 14 Robust Audio Tool (RAT): 943 http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 945 15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for 946 the Session Initiation Protocol", Informational, RFC 3487, 947 February 2003 949 16 Nichols, K., et. al.,"Definition of the Differentiated Services 950 Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed 951 Standard, RFC 2474, December 1998. 953 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 954 Proposed Standard, RFC 2748, Jan 2000. 956 18 ITU, "International Emergency Preparedness Scheme", ITU 957 Recommendation, E.106, March 2000. 959 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 960 Over IP", Informational, RFC 2871, June 2000 962 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 963 Standard, RFC 2597, June 1999 965 21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 966 Recomendation, I.255.3, July, 1990. 968 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", 969 Standards Track, RFC 3219, January 2002. 971 23 Cuervo, F., et. al, "Gateway Control Protocol Version 1", 972 Standards Track, RFC 3525, June 2003 974 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 975 Standards Track, RFC 2198, September, 1997 977 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 978 Generic Forward Error Correction", Standards Track, RFC 2733, 979 December, 1999. 981 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 982 2000. 984 27 Brown, I., "Securing IEPS over IP", White Paper, 985 http://iepscheme.net/docs/secure_IEPS.doc 987 28 "Description of an International Emergency Preference 988 Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002 990 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 991 Draft, Work In Progress, October 2001. 993 30 National Communications System: http://www.ncs.gov 995 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 996 http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, 997 IETF Presentation: IPPM-Voiceip, Aug, 1997 999 32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 1000 Proceedings, INET'95, Aug, 1995. 1002 33 Awduche, D, et al, "Requirements for Traffic Engineering Over 1003 MPLS", Informational, RFC 2702, September, 1999. 1005 34 Polk, J., "An Architecture for Multi-Level Precedence and 1006 Preemption over IP", Internet Draft, Work In Progress, 1007 November, 2001. 1009 35 "Service Class Designations for H.323 Calls", ITU 1010 Recommendation H.460.4, November, 2002 1012 36 Awduche, D., et. al., "Overview and Principles of Internet Traffic 1013 Engineering", Informational, RFC 3272, May 2002. 1015 37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and 1016 Architectures", Best Current Practice, RFC 3372, September 2002 1018 38 Polk, J., "IEPREP Telephony Topology Terminology", Informational, 1019 RFC 3523, April 2003 1021 39 Carlberg, K., Atkinson, R., "General Requirements for Emergency 1022 Telecommunications Service", Informational, RFC 3689, Feb 2004 1024 40 Carlberg, K., Atkinson, R., "IP Telephony Requirements for 1025 Emergency Telecommunications Service", Informational, RFC 3690 1026 Feb 2004 1028 41 Meyers, D., "Some Thoughts on CoS and Backbone Networks" 1029 http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf 1030 IETF Presentation: IEPREP, Dec, 2002 1032 42 Huston, G., "Commentary on Inter-Domain Routing In the Internet", 1033 Informational, RFC 3221, December 2001. 1035 43 Baugher, M, et. al., "The Secure Real-Time Transport Protocol 1036 (SRTP)", Proposed Standard, RFC 3711, March, 2004. 1038 44 Davie, B., et. al., "An Expedited Forwarding PHB (Per-Hop 1039 Behavior)", Proposed Standard, RFC 3246, March, 2002. 1041 8. Appendix A: Government Telephone Preference Scheme (GTPS) 1043 This framework document uses the T1.631 and ITU IEPS standard as a 1044 target model for defining a framework for supporting authorized emer- 1045 gency related communication within the context of IP telephony. We 1046 also use GETS as a helpful model to draw experience from. We take 1047 this position because of the various areas that must be considered; 1048 from the application layer to the (inter)network layer, in addition 1049 to policy, security (authorized access), and traffic engineering. 1051 The U.K. has a different type of authorized use of telephony services 1052 referred to as the Government Telephone Preference Scheme (GTPS). At 1053 present, GTPS only applies to a subset of the local loop lines of 1054 within the UK. The lines are divided into Categories 1, 2, and 3. 1055 The first two categories involve authorized personnel involved in 1056 emergencies such as natural disasters. Category 3 identifies the 1057 general public. Priority marks, via C7/NUP, are used to bypass 1058 call-gaping for a given Category. The authority to activate GTPS has 1059 been extended to either a central or delegated authority. 1061 8.1. GTPS and the Framework Document 1063 The design of the current GTPS, with its designation of preference 1064 based on physical static devices, precludes the need for several 1065 aspects presented in this document. However, one component that can 1066 have a direct correlation is the labeling capability of the proposed 1067 Resource Priority extension to SIP. A new label mechanism for SIP 1068 could allow a transparent interoperation between IP telephony and the 1069 U.K. PSTN that supports GTPS. 1071 9. Appendix B: Related Standards Work 1073 The process of defining various labels to distinguish calls has been, 1074 and continues to be, pursued in other standards groups. As mentioned 1075 in section 1.1.1, the ANSI T1S1 group has previously defined a label 1076 SS7 ISUP Initial Address Message. This single label or value is 1077 referred to as the National Security and Emergency Preparedness 1078 (NS/EP) indicator and is part of the T1.631 standard. The following 1079 subsections presents a snap shot of parallel on-going efforts in 1080 various standards groups. 1082 It is important to note that the recent activity in other groups have 1083 gravitated to defining 5 labels or levels of priority. The impact of 1084 this approach is minimal in relation to this ETS framework document 1085 because it simply generates a need to define a set of corresponding 1086 labels for the resource priority header of SIP. 1088 9.1. Study Group 16 (ITU) 1090 Study Group 16 (SG16) of the ITU is responsible for studies relating 1091 to multimedia service definition and multimedia systems, including 1092 protocols and signal processing. 1094 A contribution [35] has been accepted by this group that adds a 1095 Priority Class parameter to the call establishment messages of H.323. 1096 This class is further divided into two parts; one for Priority Value 1097 and the other is a Priority Extension for indicating subclasses. It 1098 is this former part that roughly corresponds to the labels tran- 1099 sported via the Resource Priority field for SIP [15]. 1101 The draft recommendation advocates defining PriorityClass information 1102 that would be carried in the GenericData parameter in the H323-UU-PDU 1103 or RAS messages. The GenericData parameter contains Priori- 1104 tyClassGenericData. The PriorityClassInfo of the PriorityClassGener- 1105 icData contains the Priority and Priority Extension fields. 1107 At present, 4 levels have been defined for the Priority Value part of 1108 the Priority Class parameter: Normal, High, Emergency-Public, 1109 Emergency-Authorized. An additional 8-bit priority extension has been 1110 defined to provide for subclasses of service at each priority. 1112 The suggested ASN.1 definition of the service class is the following: 1114 CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)} 1115 DEFINITIONS AUTOMATIC TAGS::= 1116 BEGIN 1117 IMPORTS 1118 ClearToken, 1119 CryptoToken 1120 FROM H235-SECURITY-MESSAGES; 1122 CallPriorityInfo::= SEQUENCE 1123 { 1124 priorityValue CHOICE 1125 { 1126 emergencyAuthorized NULL, 1127 emergencyPublic NULL, 1128 high NULL, 1129 normal NULL, 1130 ... 1131 }, 1133 priorityExtension INTEGER (0..255) OPTIONAL, 1134 tokens SEQUENCE OF ClearToken OPTIONAL, 1135 cryptoTokens SEQUENCE OF CryptoToken OPTIONAL, 1136 rejectReason CHOICE 1137 { 1138 priorityUnavailable NULL, 1139 priorityUnauthorized NULL, 1140 priorityValueUnknown NULL, 1141 ... 1142 } OPTIONAL, -- Only used in CallPriorityConfirm 1143 ... 1144 } 1146 The advantage in using the GenericData parameter is that an existing 1147 parameter is used, as opposed to defining a new parameter and causing 1148 subsequent changes in existing H.323/H.225 documents. 1150 10. Acknowledgments 1152 The authors would like to acknowledge the helpful comments, opinions, 1153 and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran 1154 Atkinson as well as those comments received from the IEPS and IEPREP 1155 mailing lists. Additional thanks to Peter Walker of Oftel for 1156 private discussions on the operation of GTPS, and Gary Thom on cla- 1157 rifications of the SG16 draft contribution. 1159 11. Author's Addresses 1161 Ken Carlberg Ian Brown 1162 University College London University College London 1163 Department of Computer Science Department of Computer Science 1164 Gower Street Gower Street 1165 London, WC1E 6BT London, WC1E 6BT 1166 United Kingdom United Kingdom 1167 k.carlberg@cs.ucl.ac.uk I.Brown@cs.ucl.ac.uk 1169 Cory Beard 1170 University of Missouri-Kansas City 1171 Division of Computer Science 1172 Electrical Engineering 1173 5100 Rockhill Road 1174 Kansas City, MO 64110-2499 1175 USA 1176 BeardC@umkc.edu 1177 Table of Contents 1179 1. Introduction ................................................... 2 1180 1.1 Emergency Related Data ....................................... 3 1181 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 4 1182 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4 1183 1.2 Scope of this Document ....................................... 4 1184 2. Objective ..................................................... 6 1185 3. Considerations ................................................ 6 1186 4. Protocols and Capabilities .................................... 7 1187 4.1 Signaling & State Information ................................ 7 1188 4.1.1 SIP ........................................................ 8 1189 4.1.2 Diff-Serv .................................................. 8 1190 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9 1191 4.1.4 RTP ........................................................ 10 1192 4.1.5 GCP/H.248 .................................................. 11 1193 4.2 Policy ....................................................... 11 1194 4.3 Traffic Engineering .......................................... 12 1195 4.4 Security ..................................................... 13 1196 4.4.1 Denial of Service ........................................... 13 1197 4.4.2 User authorization .......................................... 14 1198 4.4.3 Confidentiality and integrity ............................... 15 1199 4.5 Alternate Path Routing ....................................... 15 1200 4.6 End-to-End Fault Tolerance ................................... 16 1201 5. Key Scenarios ................................................. 17 1202 6. Security Considerations ....................................... 20 1203 7. References .................................................... 20 1204 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23 1205 8.1 GTPS and the Framework Document .............................. 23 1206 9. Appendix B: Related Standards Work ............................ 24 1207 9.1 Study Group 16 (ITU) ......................................... 24 1208 10. Acknowledgments .............................................. 25 1209 11. Author's Addresses ........................................... 26 1211 Full Copyright Statement 1213 Copyright (C) The Internet Society (2004). This document is subject 1214 to the rights, licenses and restrictions contained in BCP 78, and 1215 except as set forth therein, the authors retain all their rights. 1217 Disclamer 1219 This document and the information contained herein is provided as an 1220 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1221 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1222 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1223 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- 1224 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.