Internet Engineering Task Force Ken Carlberg INTERNET DRAFT Ian Brown June 19, 2003 UCL Cory Beard UMKC Framework for Supporting ETS in IP Telephony Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing Carlberg & Brown & Beard Expires December 20, 2003 [Page 1] ^L Internet Draft IP Telephony Framework June 20, 2003 service in the PSTN, contribute to a constrained solution space. 1. Introduction The Internet has become the primary target for worldwide communica- tions. This is in terms of recreation, business, and various ima- ginative reasons for information distribution. A constant fixture in the evolution of the Internet has been the support of Best Effort as the default service model. Best Effort, in general terms, infers that the network will attempt to forward traffic to the destination as best as it can with no guarantees being made, nor any resources reserved, to support specific measures of Quality of Service (QoS). An underlying goal is to be "fair" to all the traffic in terms of the resources used to forward it to the destination. In an attempt to go beyond best effort service, [2] presented an overview of Integrated Services (int-serv) and its inclusion into the Internet architecture. This was followed by [3], which specified the RSVP signaling protocol used to convey QoS requirements. With the addition of [4] and [5], specifying controlled load (bandwidth bounds) and guaranteed service (bandwidth & delay bounds) respec- tively, a design existed to achieve specific measures of QoS for an end-to-end flow of traffic traversing an IP network. In this case, our reference to a flow is one that is granular in definition and applying to specific application sessions. From a deployment perspective (as of the date of this document), int-serv has been predominantly constrained to intra-domain paths, at best resembling isolated "island" reservations for specific types of traffic (e.g., audio and video) by stub domains. [6] and [7] will probably contribute to additional deployment of int-serv to Internet Service Providers (ISP) and possibly some inter-domain paths, but it seems unlikely that the original vision of end-to-end int-serv between hosts in source and destination stub domains will become a reality in the near future (the mid- to far-term is a subject for others to contemplate). In 1998, the IETF produced [8], which presented an architecture for Differentiated Services (diff-serv). This effort focused on a more aggregated perspective and classification of packets than that of [2]. This is accomplished with the recent specification of the diff-serv field in the IP header (in the case of IPv4, it replaced the old ToS field). This new field is used for code points esta- blished by IANA, or set aside as experimental. It can be expected Carlberg & Brown & Beard Expires December 20, 2003 [Page 2] ^L Internet Draft IP Telephony Framework June 20, 2003 that sets of microflows, a granular identification of a set of pack- ets, will correspond to a given code point, thereby achieving an aggregated treatment of data. One constant in the introduction of new service models has been the designation of Best Effort as the default service model. If traffic is not, or cannot be, associated as diff-serv or int-serv, then it is treated as Best Effort and uses what resources are made available to it. Beyond the introduction of new services, the continued pace of addi- tional traffic load experienced by ISPs over the years has continued to place a high importance for intra-domain traffic engineering. The explosion of IETF contributions, in the form of drafts and RFCs pro- duced in the area of Multi Protocol Label Switching (MPLS), exempli- fies the interest in versatile and manageable mechanisms for intra- domain traffic engineering. One interesting observation is the work involved in supporting QoS related traffic engineering. Specifically, we refer to MPLS support of differentiated services [9], and the on- going work in the inclusion of fast bandwidth recovery of routing failures for MPLS [10]. 1.1. Emergency Related Data The evolution of the IP service model architecture has traditionally centered on the type of application protocols used over a network. By this we mean that the distinction, and possible bounds on QoS, usually centers on the type of application (e.g., audio video tools) that is being referred to. While protocols like SMTP [11] and SIP [12] have embedded fields denoting "priority", there has not been a previous IETF standards based effort to state or define what this distinction means with respect to the underlying network or the end-to-end applications and how it should be supported at any layer. Given the emergence of IP telephony, a natural inclusion of it as part of a telephony carrier's backbone network, or into the Internet as a whole, implies the abil- ity to support existing emergency related services. Typically, one associates emergency calls with "911" telephone service in the U.S., or "999" in the U.K. -- both of which are attributed to national boundaries and accessible by the general public. Outside of this exists emergency telephone services that involved authorized usage, as described in the following subsection. Carlberg & Brown & Beard Expires December 20, 2003 [Page 3] ^L Internet Draft IP Telephony Framework June 20, 2003 1.1.1. Government Emergency Telecommunications Service (GETS) GETS is an emergency telecommunications service available in the U.S. and overseen by the National Communications System (NCS) -- an office established by the White House under an executive order [30] and now a part of the Department of Homeland Security . Unlike "911", it is only accessible by authorized individuals. The majority of these individuals are from various government agencies like the Department of Transportation, NASA, the Department of Defense, and the Federal Emergency Management Agency (to name but a few). In addition, a select set of individuals from private industry (telecommunications companies, utilities, etc.) that are involved in criticial infras- tructure recovery operations are also provided access to GETS. The purpose of GETS is to increase the probability that phone service will be available to selected authorized personnel in times of emer- gencies, such as hurricanes, earthquakes, and other disasters that may produce a burden in the form of call blocking (i.e., congestion) on the U.S. Public Switched Telephone Network by the general public. GETS is based in part on the ANSI T1.631 standard, specifying a High Probability of Completion (HPC) for SS7 signaling [13]. 1.1.2. International Emergency Preparedness Scheme (IEPS) [18] is a recent ITU standard that describes emergency related com- munications over international telephone service. While systems like GETS are national in scope, IEPS acts as an extension to local or national authorized emergency call establishment and provides a building block for a global service. As in the case of GETS, IEPS promotes mechanisms like extended queu- ing, alternate routing, and exemption from restrictive management controls in order to increase the probability that international emergency calls will be established. The specifics of how this is to be accomplished are to be defined in future ITU document(s). 1.2. Scope of this Document The scope of this document centers on the near and mid-term support of ETS within the context of IP telephony, though not necessarily Voice over IP. We make a distinction between these two by treating IP telephony as a subset of VoIP, where in the former case we assume some form of application layer signaling is used to explicitly estab- lish and maintain voice data traffic. This explicit signaling capa- bility provides the hooks from which VoIP traffic can be bridged to Carlberg & Brown & Beard Expires December 20, 2003 [Page 4] ^L Internet Draft IP Telephony Framework June 20, 2003 the PSTN. An example of this distinction is when the Robust Audio Tool (RAT) [14] begins sending VoIP packets to a unicast (or multicast) destina- tion. RAT does not use explicit signaling like SIP to establish an end-to-end call between two users. It simply sends data packets to the target destination. On the other hand, "SIP phones" are host devices that use a signaling protocol to establish a call signal before sending data towards the destination. One other aspect we should probably assume exists with IP Telephony is an association of a target level of QoS per session or flow. [31] makes an argument that there is a maximum packet loss and delay for VoIP traffic, and both are interdependent. For delays of ~200ms, a corresponding drop rate of 5% is deemed acceptable. When delay is lower, a 15-20% drop rate can be experienced and still considered acceptable. [32] discusses the same topic and makes an arguement that packet size plays a significant role in what users tolerate as "intelligible" VoIP. The larger the packet, correlating to longer sampling rate, the lower the acceptable rate of loss. Regardless of a definitive drop rate, it would seem that interactive voice has a lower threshold of loss than elastic applications such as email or web browsers. This places a higher burden on the problem space of supporting VoIP over the Internet. This problem is further compounded when toll-quality service is expected because it assumes a default service model that is better than best effort. This in turn can increase the probability that a form of call-blocking can occur with VoIP or IP telephony traffic. Beyond this, part of our motivation in writing this document is to provide a framework for ISPs and telephony carriers so that they have an understanding of objectives used to support ETS related IP telephony traffic. In addition, we also wish to provide a reference point for potential customers in order to constrain their expecta- tions. In particular, we wish to avoid any temptation of trying to replicate the exact capabilities of existing emergency voice service currently available in the PSTN to that of IP and the Internet. If nothing else, intrinsic differences between the two communications architectures precludes this from happening. Note, this does not prevent us from borrowing design concepts or objectives from existing systems. Section 2 presents several primary objectives that articulate what is considered important in supporting ETS related IP telephony traffic. These objectives represent a generic set of goals and desired capa- bilities. Section 3 presents additional value added objectives, which are viewed as useful, but not critical. Section 4 presents Carlberg & Brown & Beard Expires December 20, 2003 [Page 5] ^L Internet Draft IP Telephony Framework June 20, 2003 protocols and capabilities that relate or can play a role in support of the objectives articulated in section 2. Finally, Section 5 presents two scenarios that currently exist or are being deployed in the near term over IP networks. These are not all-inclusive scenarios, nor are they the only ones that can be articulated ([38] provides a more extensive discussion on the topology scenarios related to IP telephony). However, these scenarios do show cases where some of the protocols discussed in section 4 apply, and where some do not. Finally, we need to state that this document focuses its attention on the IP layer and above. Specific operational procedures pertaining to Network Operation Centers (NOC) or Network Information Centers (NIC) are outside the scope of this document. This includes the "bits" below IP, other specific technologies, and service level agreements between ISPs and telephony carriers with regard to dedi- cated links. 2. Objective The objective of this document is to present a framework that describes how various protocols and capabilities (or mechanisms) can be used to facilitate and support the traffic from ETS users. In several cases, we provide a bit of background in each area so that the reader is given some context and more indepth understanding. We also provide some discussion on aspects about a given protocol or capability that could be explored and potentially advanced to support ETS. This exploration is not to be confused with specific solutions since we do not articulate exactly what must be done (e.g., a new header field, or a new code point). 3. Considerations When producing a solution, or examining existing protocols and mechanisms, there are some things that should be considered. One is that inter-domain ETS communications should not rely on ubiquitous or even wide-spread support along the path between the end points. Potentially, at the network layer there may exist islands of support realized in the form of overlay networks. There may also be cases where solutions may be constrained on an end-to-end basis (i.e., at the transport or application layer). It is this diversity and possi- bly partial support that need to be taken into account by those designing and deploying ETS related solutions. Another aspect to consider is that there are existing architectures and protocols from other standards bodies that support emergency Carlberg & Brown & Beard Expires December 20, 2003 [Page 6] ^L Internet Draft IP Telephony Framework June 20, 2003 related communications. The effort in interoperating with these sys- tems, presumably through gateways or similar type nodes with IETF protocols, would foster a need to distinguish ETS flows from other flows. One reason would be the scenario of triggering ETS service from an IP network. Finally, we take into consideration the requirements of [39, 40] in discussing the protocols and mechanisms below in Secytion 4. In doing this, we do not make a one-to-one mapping of protocol discus- sion with requirement. Rather, we make sure the discussion of Sec- tion 4 does not violet any of the requirements in [39,40]. 4. Protocols and Capabilities In this section, we take the objectives presented above and present a set of protocols and capabilities that can be used to achieve them. Given that the objectives are predominantly atomic in nature, the measures used to address them are to be viewed separately with no specific dependency upon each other as a whole. Various protocols and capabilities may be complimentary to each other, but there is no need for all to exist given different scenarios of operation, and that ETS support is not viewed as a ubiquitously available service. We divide this section into 4 areas: 1) Signaling 2) Policy 3) Traffic Engineering 4) Security 5) Routing 4.1. Signaling & State Information Signaling is used to convey various information to either intermedi- ate nodes or end nodes. It can be out-of-band of a data flow, and thus in a separate flow of its own, such as SIP messages. It can be in-band and part of the state information in a datagram containing the voice data. This latter example could be realized in the form of diff-serv code points in the IP packet. In the following subsections, we discuss potential augmentations to different types of signaling and state information to help support the distinction of emergency related communications in general, and IEPS specifically. Carlberg & Brown & Beard Expires December 20, 2003 [Page 7] ^L Internet Draft IP Telephony Framework June 20, 2003 4.1.1. SIP With respect to application level signaling for IP telephony, we focus our attention to the Session Initiation Protocol (SIP). Currently, SIP has an existing "priority" field in the Request- Header-Field that distinguishes different types of sessions. The five currently defined values are: "emergency", "urgent", "normal", "non-urgent", "other-priority". These values are meant to convey importance to the end-user and have no additional sematics associated with them. [15] is a (soon to be) RFC that defines the requirements for a new header field for SIP in reference to resource priority. This new header field is meant to provide an additional measure of distinction that can influence the behavior of gateways and SIP proxies. 4.1.2. Diff-Serv In accordance with [16], the differentiated services code point (DSCP) field is divided into three sets of values. The first set is assigned by IANA. Within this set, there are currently, three types of Per Hop Behaviors that have been specified: Default (correlating to best effort forwarding), Assured Forwarding, and Expedited For- warding. The second set of DSCP values are set aside for local or experimental use. The third set of DSCP values are also set aside for local or experimental use, but may later be reassigned to IANA in case the first set has been completely assigned. One candidate approach to consider involves the specification of a new type of Per-Hop Behavior (PHB). This would provide a specific means of distinguishing emergency related traffic (signaling and user data) from other traffic. The existence of this PHB then provides a baseline by which specific code points may be defined related to various emergency related traffic: authorized emergency sessions (e.g., ETS), general public emergency calls (e.g., "911"), MLPP. Aggregates would still exist with respect to the bundling of applica- tions per code point. Further, one would associate a forwarding paradigm aimed at a low loss rate reflective of the code point selected. The new PHB could be in the form of a one or more code points that duplicate EF-type traffic characteristics. Policies would determine if a measure of importance exists per EF-type code- point. A potential issue that could be addressed by a new PHB involves merge points of flows within a diff-serv domain. With EF, one can expect admission control being performed at the edges of the domain. Presumably, careful traffic engineering would be applied to avoid Carlberg & Brown & Beard Expires December 20, 2003 [Page 8] ^L Internet Draft IP Telephony Framework June 20, 2003 congestion of EF queues at internal/core merge points stemming from flows originating from different ingress nodes of the diff-serv domain. However, traffic engineering may not be able to compensate for congestion of EF-type traffic at the domain's core routers. Hence, a new PHB that has more than one code point to identify EF- type traffic may address congestion by associating a drop precedence for certain types of EF-type datagrams. Note that local policy and SLAs would define which EF-type of traffic, if any, would be associ- ated with a specific drop precedence. 4.1.3. Variations Related to Diff-Serv and Queuing One variation to consider with respect to existing diff-serv work would be to define a new or fifth class for the existing AF PHB. Unlike the other currently defined classes of 3 levels, this new one would be based on five levels of drop precedence. This increase in the number of levels would conveniently correlate to the levels of MLPP, which has five types of priorities. The five levels would also correlate to a recent effort in the Study Group 11 of the ITU to define 5 levels for Emergency Telecommunications Service (ETS). Beyond these other standardization efforts, the 5 levels would pro- vide a higher level of variance that could be used to supercede the existing 3 levels used in the other classes. Hence, if other non- emergency aggregate traffic were assigned to the new class, the highest drop precedence they are assigned to is (3) -- corresponding to the other four currently defined classes. Emergency traffic would be set to (4) or (5), depending on the SLA that has been defined. Another variation to Another approach would be to make modifications or additions to the existing AF PHBs, with their four classes and three drop precedences per class. One could use the existing AF PHBs if one assumed that a relatively homogeneous set of packet flows were marked with the same AF class markings (i.e., have only TCP flows, or only UDP-voice flows, but not both, within a class). Then one could allocate the lowest drop precedence to the emergency traffic, and the other two drop precedences to the rest of the traffic. An original rationale for having three drop precedences was to be able to separate TCP flows from UDP flows by different drop pre- cedences, so UDP packets could be dropped more frequently than TCP packets. TCP flows would reduce their sending rates while UDP likely would not, so this could be used to prevent UDP from bullying the TCP traffic. But if the design does not create a mixing of TCP and UDP, then three drop precedences are not as necessary and one could be used for emergency traffic. To implement preferential dropping between classes of traffic, with Carlberg & Brown & Beard Expires December 20, 2003 [Page 9] ^L Internet Draft IP Telephony Framework June 20, 2003 one being emergency traffic, one would need to use a more advanced form of Active Queue Management (AQM). AQM would need to protect emergency traffic as much as possible until most, if not all, of the non-emergency traffic had been dropped. This would require creation of drop probabilities based on counting the number of packets in the queue for each drop precedence individually. Instead, current imple- mentations use an overall queue fill measurement to make decisions; this might cause emergency packets to be dropped. This new from of AQM would be a Multiple Average-Multiple Threshold approach, instead of the Single Average-Multiple Threshold approach used today. So, it could be possible to use the current set of AF PHBs if each class where reasonably homogenous in the traffic mix. But one might still have a need to be able to differentiate three drop precedences just within non-emergency traffic. If so, more drop precedences could be implemented. Also, if one wanted discrimination within emergency traffic, as with MLPPs five levels of precedence, more drop precedences might also be considered. The five levels would also correlate to a recent effort in the Study Group 11 of the ITU to define 5 levels for Emergency Telecommunications Service. The other question with AF PHBs would be whether one should create a new fifth class. This might be a useful approach, but, given the above discussion, a fifth class would only be needed if emergency traffic were considered a totally different type of traffic from a QoS perspective. Scheduling mechanisms like Weighted Fair Queueing and Class Based Queueing are used to designate a percentage of the output link bandwidth that would be used for each class if all queues were backlogged. Its purpose, therefore, it to manage the rates and delays experienced by each class. But emergency traffic does not necessarily require QoS any better or different than non-emergency traffic. It just needs higher probability of completion which could be accomplished simply through drop precedences within a class. Emergency requirements are primarily related to preferential packet dropping probabilities. Comments -------- It is important to note that as of the time that this document was written, the IETF is taking a conservative approach in specifying new PHBs. This is because the number of code points that can be defined is relatively small, and understandably considered a scarce resource. Therefore, the possibility of a new PHB being defined for emergency related traffic is at best a long term project that may or may not be accepted by the IETF. In the near term, we would initially recommend using the Assured Carlberg & Brown & Beard Expires December 20, 2003 [Page 10] ^L Internet Draft IP Telephony Framework June 20, 2003 Forwarding (AF) PHB [20] for distinguishing emergency traffic from other types of flows. At a minimum, AF could be used for the dif- ferent SIP call signaling messages. If EF was also supported by the domain, then it would be used for IP telephony data packets. Other- wise, another AF class would be used for those data flows. It is also critical to understand that one cannot specify an exact code point used exclusively for emergency related data flows. This is because the relevance of a code point is local to the given diff- serv domain (i.e., code points are not globally unique per micro-flow or aggregate of flows). 4.1.4. RTP The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for data with real-time characteristics. The type of data is generally in the form of audio or video type applications, and are frequently interactive in nature. RTP is typically run over UDP and has been designed with a fixed header that identifies a specific type of payload representing a specific form of application media. The designers of RTP also assumed an underlying network providing best effort service. As such, RTP does not provide any mechanism to ensure timely delivery or provide other QoS guarantees. However, the emergence of applications like IP telephony, as well as new service models, presents new environments where RTP traffic may be forwarded over networks that support better than best effort service. Hence, the original scope and target environment for RTP has expanded to include networks providing services other than best effort. In 4.1.2, we discussed one means of marking a data packet for emer- gencies under the context of the diff-serv architecture. However, we also pointed out that diff-serv markings for specific PHBs are not globally unique, and may be arbitrarily removed or even changed by intermediary nodes or domains. Hence, with respect to emergency related data packets, we are still missing an in-band marking in a data packet that stays constant on an end-to-end basis. There are three choices in defining a persistent marking of data packets and thus avoid the transitory marking of diff-serv code points. One can propose a new PHB dedicated for emergency type traffic as discussed in 4.1.2. One can propose a specification of a new shim layer protocol at some location above IP. Or, one can add a new specification to an existing application layer protocol. The first two cases are probably the "cleanest" architecturally, but they are long term efforts that may not come to pass because of a limited amount of diff-serv code points and the contention that yet another shim layer will make the IP stack too large. The third case, placing Carlberg & Brown & Beard Expires December 20, 2003 [Page 11] ^L Internet Draft IP Telephony Framework June 20, 2003 a marking in an application layer packet, also has drawbacks; the key weakness being the specification of a marking on a per-application basis. Discussions have been held in the Audio/Visual Transport (AVT) work- ing group of augmenting RTP so that it can carry a marking that dis- tinguishes emergency-related traffic from that which is not. Specif- ically, these discussions centered on defining a new extention that contains a "classifier" field indicating the condition associated with the packet (e.g., authorized-emergency, emergency, normal) [29]. The rationale behind this idea was that focusing on RTP would allow one to rely on a point of aggregation that would apply to all pay- loads that it encapsulates. However, the AVT group has expressed a rough consensus that placing additional classifier state in the RTP header to denote the importance of one flow over another is not an approach that they wish to advance. Objections ranging from relying on SIP to convey importance of a flow, as well as the possibility of adversely affecting header compression, were expressed. There was also the general feeling that the extension header for RTP that acts as a signal should not be used. 4.1.5. MEGACO/H.248 The Media Gateway Control protocol (MEGACO) [23] defines the interac- tion between a media gateway and a media gateway controller. [23] is viewed as common text with ITU-T Recommendation H.248 and is a result of applying the changes of RFC 2886 (Megaco Errata) to the text of RFC 2885 (Megaco Protocol version 0.8). In [23], the protocol specifies a Priority and Emergency field for a context attribute and descriptor. The Emergency is an optional boolean (True or False) condition. The Priority value, which ranges from 0 through 15, specifies the precedence handling for a context. The protocol does not specify individual values for priority. We also do not recommend the definition of a well known value for the MEGAGO priority. Any values set should be a function of any SLAs that have been established regarding the handling of emergency traffic. In addition, given that priority values denote precedence (according to the Megaco protocol), then by default the ETS telephony data flows should probably receive the same priority as other non- emergency calls. This approach follows the objective of not relying on preemption as the default treatment of emergency-related. Carlberg & Brown & Beard Expires December 20, 2003 [Page 12] ^L Internet Draft IP Telephony Framework June 20, 2003 4.2. Policy One of the objectives listed in section 3 above is to treat ETS- sig- naling, and related data traffic, as non-preemptive in nature. Further, that this treatment is to be the default mode of operation or service. This is in recognition that existing regulations or laws of certain countries governing the establishment of SLAs may not allow preemptive actions (e.g., dropping existing telephony flows). On the other hand, the laws and regulations of other countries influencing the specification of SLA(s) may allow preemption, or even require its existence. Given this disparity, we rely on local policy to determine the degree by which emergency related traffic affects existing traffic load of a given network or ISP. Important note: we reiterate our earlier comment that laws and regulations are generally outside the scope of the IETF and its specification of designs and protocols. However, these constraints can be used as a guide in pro- ducing a baseline capability to be supported; in our case, a default policy for non-preemptive call establishment of ETS signaling and data. Policy can be in the form of static information embedded in various components (e.g., SIP servers or bandwidth brokers), or it can be realized and supported via COPS with respect to allocation of a domain's resources [17]. There is no requirement as to how policy is accomplished. Instead, if a domain follows actions outside of the default non-preemptive action of ETS related communication, then we stipulate that some type of policy mechanism is in place to satisfy the local policies of an SLA established for ETS type traffic. 4.3. Traffic Engineering In those cases where a network operates under the constraints of SLAs, one or more of which pertains to ETS based traffic, it can be expected that some form of traffic engineering is applied to the operation of the network. We make no recommendations as to which type of traffic engineering mechanism is used, but that such a system exists in some form and can distinguish and support ETS signaling and/or data traffic. We recommend a review of [36] by clients and prospective providers of ETS service, which gives an overview and a set of principles of Internet traffic engineering. MPLS is generally the first protocol that comes to mind when the sub- ject of traffic engineering is brought up. This notion is heightened concerning the subject of IP telephony because of MPLS's ability to permit a quasi-circuit switching capability to be superimposed on the current Internet routing model [33]. Carlberg & Brown & Beard Expires December 20, 2003 [Page 13] ^L Internet Draft IP Telephony Framework June 20, 2003 However, having cited MPLS, we need to stress that it is an intra- domain protocol, and so may or may not exist within a given ISP. Other forms of traffic engineering, such as weighted OSPF, may be the mechanism of choice by an ISP. As a counter example of using a specific protocol to achieve traffic engineering, [41] presents an example by one ISP relying on a high amount of overprovisioning within its core to satisfy potentially dramatic spikes or bursts of traffic load. In this approach, any configuring of queues for specific customers (neighbors) to support target QoS is done on the egress edge of the transit network. Note: As a point of reference, existing SLAs established by the NCS for GETS service tend to focus on a maximum allocation of (e.g., 1%) of calls allowed to be established through a given LEC using HPC. Once this limit is reached, all other GETS calls experience the same probability of call completion as the general public. It is expected, and encouraged, that ETS related SLAs will have a limit with respect to the amount of traffic distinguished as being emer- gency related, and initiated by an authorized user. 4.4. Security If ETS support moves from intra-domain PSTN and IP networks to inter-domain end-to-end IP, authenticated service becomes more com- plex to provide. Where an ETS call is carried from PSTN to PSTN via one telephony carrier's backbone IP network, very little IP-specific security support is required. The user authenticates themself as usual to the network using a PIN. The gateway from the PSTN connec- tion into the backbone IP network must be able to signal that the flow has an ETS label. Conversely, the gateway back into the PSTN must similarly signal the call's label. A secure link between the gateways may be set up using IPSec or SIP security functionality. If the endpoint is an IP device, the link may be set up securely from the ingress gateway to the end device. As flows traverse more than one IP network, domains whose peering agreements include ETS support must have the means to securely signal a given flow's ETS status. They may choose to use physical link secu- rity and/or IPSec authentication, combined with traffic conditioning measures to limit the amount of ETS traffic that may pass between the two domains. The inter-domain agreement may require the originating network to take responsibility for ensuring only authorized traffic is marked with ETS priority; the downstream domain may still perform redundant conditioning to prevent the propagation of theft and denial of service attacks. Security may be provided between ingress and egress gateways or IP endpoints using IPSec or SIP security Carlberg & Brown & Beard Expires December 20, 2003 [Page 14] ^L Internet Draft IP Telephony Framework June 20, 2003 functions. When a call originates from an IP device, the ingress network may authorize IEPS traffic over that link as part of its user authentica- tion procedures. These authentication procedures may occur at the link or network layers, but are entirely at the discretion of the ingress network. That network must decide how often it should update its list of authorized ETS users based on the bounds it is prepared to accept on traffic from recently-revoked users. 4.5. Alternate Path Routing This subject involves the ability to discover and use a different path to route IP telephony traffic around congestion points and thus avoid them. Ideally, the discovery process would be accomplished in an expedient manner (possibly even a priori to the need of its existence). At this level, we make no assumptions as to how the alternate path is accomplished, or even at which layer it is achieved -- e.g., the network versus the application layer. But this kind of capability, at least in a minimal form, would help contribute to increasing the probability of ETS call completion by making use of noncongested alternate paths. We use the term "minimal form" to emphasize the fact that care must be taken in how the system provides alternate paths so it does not significantly contribute to the congestion that is to be avoided (e.g., via excess control/discovery messages). At the time that this document was written, we can identify two areas in the IETF that can be helpful in providing alternate paths for call signaling. The first is [10], which is focused on network layer routing and describes a framework for enhancements to the LDP specif- ication of MPLS to help achieve fault tolerance. This in itself does not provide alternate path routing, but rather helps minimize loss in intradomain connectivity when MPLS is used within a domain. The second effort comes from the IP Telephony working group and involves Telephony Routing over IP (TRIP). To date, a framework document [19] has been published as an RFC which describes the discovery and exchange of IP telephony gateway routing tables between providers. The TRIP protocol [22] specifies application level telephony routing regardless of the signaling protocol being used (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises reachability and attributes of destinations. In its current form, several attributes have already been defined, such as LocalPreference and MultiExitDisc. Additional attributes can be registered with IANA. Carlberg & Brown & Beard Expires December 20, 2003 [Page 15] ^L Internet Draft IP Telephony Framework June 20, 2003 Inter-domain routing is not an area that should be considered in terms of alternate path routing support for ETS. The Border Gateway Protocol is currently strained in meetings its existing requirements, and thus adding additional features that would generate an increase in advertised routes will not be well received by the IETF. Refer to [42] for a commentary on Inter-Domain routing. 4.6. End-to-End Fault Tolerance This topic involves the work that has been done in trying to compen- sate for lossy networks providing best effort service. In particu- lar, we focus on the use of a) Forward Error Correction (FEC), and b) redundant transmissions that can be used to compensate for lost data packets. (Note that our aim is fault tolerance, as opposed to an expectation of always achieving it). In the former case, additional FEC data packets are constructed from a set of original data packets and inserted into the end-to-end stream. Depending on the algorithm used, these FEC packets can reconstruct one or more of the original set that were lost by the network. An example may be in the form of a 10:3 ratio, in which 10 original packets are used to generate three additional FEC packets. Thus, if the network loses 30% or less number of packets, then the FEC scheme will be able to compensate for that loss. The drawback to this approach is that to compensate for the loss, a steady state increase in offered load has been injected into the network. This makes an arguement that the act of protection against loss has con- tributed to additional pressures leading to congestion, which in turn helps trigger packet loss. In addition, in using a ratio of 10:3, the source (or some proxy) must "hold" all 10 packets in order to construct the three FEC packets. This contributes to the end-to-end delay of the packets as well as minor bursts of load in addition to changes in jitter. The other form of fault tolerance we discuss involves the use of redundant transmissions. By this we mean the case in which an origi- nal data packet is followed by one or more redundant packets. At first glance, this would appear to be even less friendly to the net- work than that of adding FEC packets. However, the encodings of the redundant packets can be of a different type (or even transcoded into a lower quality) that produce redundant data packets that are signi- ficantly smaller than the original packet. Two RFCs [24, 25] have been produced that define RTP payloads for FEC and redundant audio data. An implementation example of a redundant audio application can be found in [14]. We note that both FEC and redundant transmissions can be viewed as rather specific and to a Carlberg & Brown & Beard Expires December 20, 2003 [Page 16] ^L Internet Draft IP Telephony Framework June 20, 2003 degree tangential solutions regarding packet loss and emergency com- munications. Hence, these topics are placed under the category of value added objectives. 5. Key Scenarios There are various scenarios in which IP telephony can be realized, each of which can imply a unique set of functional requirements that may include just a subset of those listed above. We acknowledge that a scenario may exist whose functional requirements are not listed above. Our intention is not to consider every possible scenario by which support for emergency related IP telephony can be realized. Rather, we narrow our scope using a single guideline; we assume there is a signaling & data interaction between the PSTN and the IP network with respect to supporting emergency-related telephony traffic. We stress that this does not preclude an IP-only end-to-end model, but rather the inclusion of the PSTN expands the problem space and includes the current dominant form of voice communication. Note: as stated in section 1.2, [36] provides a more extensive set of scenarios in which IP telephony can be deployed. Our selected set below is only meant to provide an couple of examples of how the pro- tocols and capabilities presented in Section 3 can play a role. Single IP Administrative Domain ------------------------------- This scenario is a direct reflection of the evolution of the PSTN. Specifically, we refer to the case in which data networks have emerged in various degrees as a backbone infrastructure connecting PSTN switches at its edges. This represents a single isolated IP administrative domain that has no directly adjacent IP domains con- nected to it. We show an example of this scenario below in Figure 1. In this example, we show two types of telephony carriers. One is the legacy carrier, whose infrastructure retains the classic switching architecture attributed to the PSTN. The other is the next genera- tion carrier, which uses a data network (e.g., IP) as its core infrastructure, and Signaling Gateways at its edges. These gateways "speak" SS7 externally with peering carriers, and another protocol (e.g., SIP) internally, which rides on top of the IP infrastructure. Carlberg & Brown & Beard Expires December 20, 2003 [Page 17] ^L Internet Draft IP Telephony Framework June 20, 2003 Legacy Next Generation Next Generation Carrier Carrier Carrier ******* *************** ************** * * * * ISUP * * SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG * * (SS7) * (SIP) * (SS7) * (SIP) * ******* *************** ************** SW - Telco Switch SG - Signaling Gateway Figure 1 The significant aspect of this scenario is that all the resources of each IP "island" fall within a given administrative authority. Hence, there is not a problem of retaining toll quality Grade of Ser- vice as the voice traffic (data and signaling) exits the IP network because of the existing SS7 provisioned service between telephony carriers. Thus, the need for support of mechanisms like diff-serv, and an expansion of the defined set of Per-Hop Behaviors is reduced (if not eliminated) under this scenario. Another function that has little or no importance within the closed IP environment of Figure 1 is that of IP security. The fact that each administrative domain peers with each other as part of the PSTN, means that existing security, in the form of Personal Identification Number (PIN) authentication (under the context of telephony infras- tructure protection), is the default scope of security. We do not claim that the reliance on a PIN based security system is highly secure or even desirable. But, we use this system as a default mechanism in order to avoid placing additional requirements on exist- ing authorized emergency telephony systems. Multiple IP Administrative Domains ---------------------------------- We view the scenario of multiple IP administrative domains as a superset of the previous scenario. Specifically, we retain the notion that the IP telephony system peers with the existing PSTN. In addition, segments (i.e., portions of the Internet) may exchange signaling with other IP administrative domains via non-PSTN signaling protocols like SIP. Carlberg & Brown & Beard Expires December 20, 2003 [Page 18] ^L Internet Draft IP Telephony Framework June 20, 2003 Legacy Next Generation Next Generation Carrier Carrier Carrier ******* *************** ************** * * * * * * SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG * * (SS7) * (SIP) * (SIP) * (SIP) * ******* *************** ************** SW - Telco Switch SG - Signaling Gateway Figure 2 Given multiple IP domains, and the presumption that SLAs relating to ETS traffic may exist between them, the need for something like diff-serv grows with respect to being able to distinguish the emer- gency related traffic from other types of traffic. In addition, IP security becomes more important between domains in order to ensure that the act of distinguishing ETS-type traffic is indeed valid for the given source. We conclude this section by mentioning a complimentary work in pro- gress in providing ISUP transparency across SS7-SIP interworking [37]. The objective of this effort is to access services in the SIP network and yet maintain transparency of end-to-end PSTN services. Not all services are mapped (as per the design goals of [37], so we anticipate the need for an additional document to specify the mapping between new SIP labels and existing PSTN code points like NS/EP and MLPP. 6. Security Considerations Information on this topic is presented in sections 2 and 4. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Braden, R., et. al., "Integrated Services in the Internet Architecture: An Overview", Informational, RFC 1633, June 1994. 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) Carlberg & Brown & Beard Expires December 20, 2003 [Page 19] ^L Internet Draft IP Telephony Framework June 20, 2003 Version 1, Functional Specification", Proposed Standard, RFC 2205, Sept. 1997. 4 Shenker, S., et. al., "Specification of Guaranteed Quality of Service", Proposed Standard, RFC 2212, Sept 1997. 5 Wroclawski, J., "Specification for Controlled-Load Network Service Element", Proposed Standard, RFC 2211, Sept 1997. 6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 Reservations", Proposed Standard, RFC 3175, September 2001. 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", Proposed Standard, RFC 2961, April, 2001. 8 Blake, S., et. al., "An Architecture for Differentiated Service", Proposed Standard, RFC 2475, Dec. 1998. 9 Faucheur, F., et. al., "MPLS Support of Differentiated Services", Standards Track, RFC 3270, May 2002. 10 Sharma, V., Hellstrand, F., "Framework for MPLS-Based Recovery", Informational, RFC 3469, February 2003 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, August 1982. 12 Handley, M., et. al., "SIP: Session Initiation Protocol", Proposed Standard, RFC 2543, March 1999. 13 ANSI, "Signaling System No. 7(SS7), High Probability of Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999). 14 Robust Audio Tool (RAT): http://www-mice.cs.ucl.ac.uk/multimedia/software/rat 15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol", Informational, RFC 3487, February 2003 16 Nichols, K., et. al.,"Definition of the Differentiated Services Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed Standard, RFC 2474, December 1998. 17 Durham, D., "The COPS (Common Open Policy Service) Protocol", Proposed Standard, RFC 2748, Jan 2000. 18 ITU, "International Emergency Preparedness Scheme", ITU Carlberg & Brown & Beard Expires December 20, 2003 [Page 20] ^L Internet Draft IP Telephony Framework June 20, 2003 Recommendation, E.106, March 2000. 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing Over IP", Informational, RFC 2871, June 2000 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed Standard, RFC 2597, June 1999 21 ITU, "Multi-Level Precedence and Preemption Service, ITU, Recomendation, I.255.3, July, 1990. 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Standards Track, RFC 3219, January 2002. 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards Track, RFC 3015, November 2000 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", Standards Track, RFC 2198, September, 1997 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for Generic Forward Error Correction", Standards Track, RFC 2733, December, 1999. 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 2000. 27 Brown, I., "Securing IEPS over IP", White Paper, http://iepscheme.net/docs/secure_IEPS.doc 28 "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet Draft, Work In Progress, October 2001. 30 National Communications System: http://www.ncs.gov 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997 32 Hardman, V., et al, "Reliable Audio for Use over the Internet", Proceedings, INET'95, Aug, 1995. 33 Awduche, D, et al, "Requirements for Traffic Engineering Over MPLS", Informational, RFC 2702, September, 1999. Carlberg & Brown & Beard Expires December 20, 2003 [Page 21] ^L Internet Draft IP Telephony Framework June 20, 2003 34 Polk, J., "An Architecture for Multi-Level Precedence and Preemption over IP", Internet Draft, Work In Progress, November, 2001. 35 "Service Class Designations for H.323 Calls", ITU Recommendation H.460.4, November, 2002 36 Awduche, D., et. al., "Overview and Principles of Internet Traffic Engineering", Informational, RFC 3272, May 2002. 37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and Architectures", Best Current Practice, RFC 3372, September 2002 38 Polk, J., "IEPREP Telephony Topology Terminology", Informational, RFC 3523, April 2003 39 Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", Work in Progress, Internet-Draft, January, 2003 40 Carlberg, K., Atkinson, R., "IP Telephony Requirements for Emergency Telecommunications Service", Work In Progress, Internet- Draft, January, 2003 41 Meyers, D., "Some Thoughts on CoS and Backbone Networks" http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF Presentation: IEPREP, Dec, 2002 42 Huston, G., "Commentary on Inter-Domain Routing In the Internet", Informational, RFC 3221, December 2001. 8. Appendix A: Government Telephone Preference Scheme (GTPS) This framework document uses the T1.631 and ITU IEPS standard as a target model for defining a framework for supporting authorized emer- gency related communication within the context of IP telephony. We also use GETS as a helpful model to draw experience from. We take this position because of the various areas that must be considered; from the application layer to the (inter)network layer, in addition to policy, security (authorized access), and traffic engineering. The U.K. has a different type of authorized use of telephony services referred to as the Government Telephone Preference Scheme (GTPS). At present, GTPS only applies to a subset of the local loop lines of within the UK. The lines are divided into Categories 1, 2, and 3. Carlberg & Brown & Beard Expires December 20, 2003 [Page 22] ^L Internet Draft IP Telephony Framework June 20, 2003 The first two categories involve authorized personnel involved in emergencies such as natural disasters. Category 3 identifies the general public. Priority marks, via C7/NUP, are used to bypass call-gaping for a given Category. The authority to activate GTPS has been extended to either a central or delegated authority. 8.1. GTPS and the Framework Document The design of the current GTPS, with its designation of preference based on physical static devices, precludes the need for several aspects presented in this document. However, one component that can have a direct correlation is the labeling capability of the proposed Resource Priority extension to SIP. A new label mechanism for SIP could allow a transparent interoperation between IP telephony and the U.K. PSTN that supports GTPS. 9. Appendix B: Related Standards Work The process of defining various labels to distinguish calls has been, and continues to be, pursued in other standards groups. As mentioned in section 1.1.1, the ANSI T1S1 group has previously defined a label SS7 ISUP Initial Address Message. This single label or value is referred to as the National Security and Emergency Preparedness (NS/EP) indicator and is part of the T1.631 standard. The following subsections presents a snap shot of parallel on-going efforts in various standards groups. It is important to note that the recent activity in other groups have gravitated to defining 5 labels or levels of priority. The impact of this approach is minimal in relation to this ETS framework document because it simply generates a need to define a set of corresponding labels for the resource priority header of SIP. 9.1. Study Group 16 (ITU) Study Group 16 (SG16) of the ITU is responsible for studies relating to multimedia service definition and multimedia systems, including protocols and signal processing. A contribution [35] has been accepted by this group that adds a Priority Class parameter to the call establishment messages of H.323. This class is further divided into two parts; one for Priority Value and the other is a Priority Extension for indicating subclasses. It is this former part that roughly corresponds to the labels Carlberg & Brown & Beard Expires December 20, 2003 [Page 23] ^L Internet Draft IP Telephony Framework June 20, 2003 transported via the Resource Priority field for SIP [15]. The draft recommendation advocates defining PriorityClass information that would be carried in the GenericData parameter in the H323-UU-PDU or RAS messages. The GenericData parameter contains Priori- tyClassGenericData. The PriorityClassInfo of the PriorityClassGener- icData contains the Priority and Priority Extension fields. At present, 5 levels have been defined for the Priority Value part of the Priority Class parameter: Low, Normal, High, Emergency-Public, Emergency-Authorized. An additional 8-bit priority extension has been defined to provide for subclasses of service at each priority. The suggested ASN.1 definition of the service class is the following: ServiceClassInfo ::= SEQUENCE { priority CHOICE { emergencyAuthorized NULL, emergencyPublic NULL, high NULL, normal NULL, low NULL } priorityExtension INTEGER (0..255) OPTIONAL; requiredClass NULL OPTIONAL tokens SEQUENCE OF ClearToken OPTIONAL cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL } The advantage in using the GenericData parameter is that an existing parameter is used, as opposed to defining a new parameter and causing subsequent changes in existing H.323/H.225 documents. 10. Acknowledgments The authors would like to acknowledge the helpful comments, opinions, and clarifications of Stu Goldman, James Polk, Dennis Berg, as well as those comments received from the IEPS and IEPREP mailing lists. Additional thanks to Peter Walker of Oftel for private discussions on the operation of GTPS, and Gary Thom on clarifications of the SG16 draft contribution. Carlberg & Brown & Beard Expires December 20, 2003 [Page 24] ^L Internet Draft IP Telephony Framework June 20, 2003 11. Author's Addresses Ken Carlberg Ian Brown University College London University College London Department of Computer Science Department of Computer Science Gower Street Gower Street London, WC1E 6BT London, WC1E 6BT United Kingdom United Kingdom Cory Beard University of Missouri-Kansas City Division of Computer Science Electrical Engineering 5100 Rockhill Road Kansas City, MO 64110-2499 USA BeardC@umkc.edu Carlberg & Brown & Beard Expires December 20, 2003 [Page 25] ^L Internet Draft IP Telephony Framework June 20, 2003 Table of Contents 1. Introduction ................................................... 2 1.1 Emergency Related Data ....................................... 3 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 4 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4 1.2 Scope of this Document ....................................... 4 2. Objective ..................................................... 6 3. Considerations ................................................ 6 4. Protocols and Capabilities .................................... 7 4.1 Signaling & State Information ................................ 7 4.1.1 SIP ........................................................ 8 4.1.2 Diff-Serv .................................................. 8 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9 4.1.4 RTP ........................................................ 11 4.1.5 MEGACO/H.248 ............................................... 12 4.2 Policy ....................................................... 13 4.3 Traffic Engineering .......................................... 13 4.4 Security ..................................................... 14 4.5 Alternate Path Routing ....................................... 15 4.6 End-to-End Fault Tolerance ................................... 16 5. Key Scenarios ................................................. 17 6. Security Considerations ....................................... 19 7. References .................................................... 19 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 22 8.1 GTPS and the Framework Document .............................. 23 9. Appendix B: Related Standards Work ............................ 23 9.1 Study Group 16 (ITU) ......................................... 23 10. Acknowledgments .............................................. 24 11. Author's Addresses ........................................... 25 Full Copyright Statement "Copyright (C) The Internet Society 2003. All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Carlberg & Brown & Beard Expires December 20, 2003 [Page 26] ^L Internet Draft IP Telephony Framework June 20, 2003 Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided as an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Carlberg & Brown & Beard Expires December 20, 2003 [Page 27]