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