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