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