Internet Engineering Task Force Mike Pierce INTERNET DRAFT Artel Expires August, 2002 Don Choi DISA February 2002 Requirements for Assured Service Capabilities in Voice over IP draft-pierce-sipping-assured-service-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 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 a http://www.ietf.org/ietf/lid-abstracts.text The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) Internet Society 2002. All rights reserved. Reproduction or translation of the complete documents, but not of extracts, including this notice, is freely permitted. Pierce Expires August 2002 [Page 1] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 Abstract Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. This memo describes the requirements for such capabilities in support of specific networks such as those used by the US military and government. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. High Level Requirements . . . . . . . . . . . . . . . . . . 5 4. Functional Requirements . . . . . . . . . . . . . . . . . . 5 4.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 6 4.2 Authentication/Authorization . . . . . . . . . . . . . . . . 6 4.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 6 4.4 Diversion if Not Answered . . . . . . . . . . . . . . . . . 7 4.5 Notifications to Preempted Party . . . . . . . . . . . . . . 7 4.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 7 4.7 Protection of Signaling Information from Disclosure . . . . 7 5. Current Situation . . . . . . . . . . . . . . . . . . . . . 7 5.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 IntServ/RSVP . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Possible Approaches . . . . . . . . . . . . . . . . . . . . 10 6.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 10 6.2 Authentication/Authorization . . . . . . . . . . . . . . . . 11 6.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.2 Authentication Procedures . . . . . . . . . . . . . . . . 12 6.2.3 Authorization Procedures . . . . . . . . . . . . . . . . . 12 6.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 12 6.4 Diversion . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5 Notification to Preempted Party . . . . . . . . . . . . . . 14 6.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 14 6.7 Protection of Signaling Information . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 7.1 Authentication/authorization of User Access . . . . . . . . 14 7.2 Security of Signaling Information . . . . . . . . . . . . . 14 7.3 Security of Routing Data . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Pierce Expires August 2002 [Page 2] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 ANNEX A Example Mapping of Call Precedence Levels to DiffServ Codepoints . . . . . . . . . . . . . . . . . 18 A.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2 Packet Forwarding Treatment Using DiffServ . . . . . . . . . 18 A.3 Packet Forwarding Treatment without DiffServ . . . . . . . . 19 Annex B Example Call Preferential Treatment Using Over Committing andPacket Discard . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Throughout many decades of evolution of the telephony network and its supporting protocols, there has been a need to provide special services to a limited subset of the users and calls within a network or domain in order to ensure completion of important calls. Examples of this need have been in support of emergency traffic for natural disasters, network restoration traffic, and high priority traffic in a military network. Provision of the required capabilities with the signaling protocols and within the switching systems has been defined in a number of national and international standards, most notably a service referred to as Multi-Level Precedence and Preemption as defined in an American National Standard [T1.619] in the US and in corresponding ITU-T Recommendations [I.255.3, Q.735.3, and Q.955.3]. In addition, a service called High Probability of Completion (HPC) was defined in [T1.631] and, most recently, two ITU-T Recommendations define the requirements for the International Emergency Preference Scheme (IEPS) [E.106] and the International Emergency Multimedia Service (IEMS) [F.706]. Other drafts submitted to the IETF have addressed aspects of MLPP and IEPS. Some of these are [Polk1], which discusses some of the possible solutions for MLPP within IP; [Folts], which presents the functional requirements, features, and objectives for the Emergency Telecommunications Service (ETS); and [Carlberg], which provides a framework for IEPS for telephony over IP. MLPP was the solution to providing Assured Service capabilities within the circuit switched environment. It is essential that equivalent Assured Service capabilities are defined and implemented for the packet-based, connectionless environment of the Internet, and specifically SIP. Without these capabilities, SIP can not be used for those applications which require such capabilities, and is less than optimal for many other uses. This memo builds on these references and identifies the specific Pierce Expires August 2002 [Page 3] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 requirements for Assured Service capabilities in support of these specific types of environments. The term "Assured Service" is used to refer to the required capabilities, rather than the previous terms of MLPP or IEPS, since the envisioned set of capabilities and protocols to achieve them are not expected to be the same as those previously defined services. Although these requirements are derived from previous military and government applications, many of the same requirements and capabilities may be applied for non-military or government networks, for example, in support of commercial network restoration efforts. A presentation in the TEWG at London [Ash] demonstrated real-life situations from the past in which total network failures required extensive efforts, presumably including communication via other unaffected networks, to bring the affected network back on line. If one considered a situation in which the very network which had failed was needed to carry the network management traffic required to get it back on line, it would be hard to imagine how it could ever be brought back up in the face of overwhelming customer attempts. Capabilities would be required to give priority to the network management traffic, even to the extent of blocking all non-emergency traffic for a period of time. 2. Background In the circuit switched environment, specific circuits or channels were used for each call. These were typically 64 kbit/s channels which were a part of a TDM transmission structure. Later developments used packet/cell based transport instead of dedicated 64 kbit/s channels, however, the effect was the same. There was still a dedicated transport capacity assigned for each call. Assured Service in the circuit switched environment may be provided by one or more of the following techniques. Note that the capabilities included within IEPS [E.106], are included here for reference but not dealt with further in this memo. They are further dealt with in [Folts]: - Giving priority to return of dial tone (IEPS). - Marking of signaling messages for better handling, for example, being last to be dropped in case of congestion in the signaling network (HPC). - Extra routing possibilities for higher priority calls. (IEPS) - Exemption from restrictive management controls (IEPS) such as Pierce Expires August 2002 [Page 4] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 hard-to-reach codes and code gapping. - Reservation of specific facilities (trunks) for higher priority traffic (IEPS). - Higher priority calls may preempt existing lower priority calls, causing the network to release the lower priority call to free up resources for immediate reuse by the higher priority call (MLPP). Identification of traffic authorized to use one or more of these techniques may be via the following methods: - Calls placed from physical lines or devices authorized for its use - Calls placed to specific telephone numbers or blocks of numbers - Entry of a special ID code and PIN from any telephone device 3. High Level Requirements While the existing requirements and capabilities have been developed with the circuit switched environment in mind, many are directly applicable to the packet environment and specifically the Voice over IP application being defined using SIP. Some of the capabilities need to be adapted or modified for application in the packet mode environment. In addition, there will likely be new techniques which can be defined specifically for the SIP case. At a high level, the Assured Service requirements can be stated as the need to ensure that mission critical voice-mode calls get set up and remain connected. 4. Functional Requirements The functional requirements for Assured Service being detailed here are specifically those needed to support the US government requirements, primarily for the military environment. This memo concentrates on those portions mentioned in Section 2 which are derived from the requirements for MLPP as defined in [T1.619]. The basic requirements can be defined as follows; 4.1 Precedence Level Marking Pierce Expires August 2002 [Page 5] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 It must be possible for the originator to select and signal one of five precedence levels for a call, with the call defaulting to the lowest if none is specified. It must be possible to carry this call associated precedence level though the IP network. It must be possible to deliver the originally signaled precedence level to the called party. 4.2 Authentication/Authorization It must be possible to verify that the calling party is authorized to use the Assured Service and the requested value and to take the appropriate action if the calling party attempts to use a higher level. The preferred action is to reject the call, and send an indication of the reason to the caller. 4.3 Preferential Treatment It must be possible to provide preferential treatment to higher precedence calls in relation to lower precedence calls. Examples of preferential treatments are: - reservation of network resources for precedence calls - usage of higher Call Acceptance limits for higher precedence calls - preferential queuing of signaling messages based on precedence level - preferential queuing of user data packets based on precedence level - discarding of packets of lower precedence call - preemption of one or more existing calls of lower precedence level - preemption of some of the resources being used by a call of lower precedence level - preemption of the reservation of resources being held for other traffic 4.4 Diversion if Not Answered If a precedence call (one higher that the lowest level) does not answer within a designated time or the called party is busy with a Pierce Expires August 2002 [Page 6] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 call of equal or higher precedence such that an indication of the new call can not be given to the intended called party, the call must be diverted to a predetermined alternate party. In general, this must operate similar to a normal "Call Forwarding on No Answer" service. 4.5 Notifications to Preempted Party All preempted parties must be provided with a distinct notification informing them that their call has been preempted. 4.6 Acknowledge by Preempted Party When an existing call is preempted for delivery of a higher precedence call to the same party, after the party is notified that a new call is being presented, the party must acknowledge the preemption before the new call is connected. That is, there must be a positive acknowledgement before any audio information is transferred in either direction. 4.7 Protection of Signaling Information from Disclosure Although protection is not actually an integral part of the Assured Service functionality, it is specifically identified here since this capability is always required in those networks which are assumed to be the primary users of Assured Service. It is required that sensitive information not be made available to non-secure portions of the network or to any non-secure network through which the traffic passes. It is also important that it not be accessible by users connected to the network. This non-disclosure requirement especially applies to information which is used to control link state routing protocols based on knowledge of the current traffic load at each precedence level on each route. Further, it is desirable that the precedence information regarding each call (as well as the other information such as calling/called party identity) be protected from disclosure to the greatest extent possible. 5. Current Situation Current support for Assured Service within various IETF defined protocols and ongoing initiatives is not considered to be sufficient. 5.1 IPv4 Although support for the traditional five precedence levels was included in the TOS field of IPv4 from the earliest days, support for Pierce Expires August 2002 [Page 7] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 this field is not universal, and it only provides packet level priority. It does not provide call setup priority or control of call retention. 5.2 DiffServ Although it is possible to map the required five precedence levels to the Assured Forwarding classes defined in RFC 2597, this also provides only per packet priority treatment. While this may provide a fundamental subcomponent of the Assured Service requirements detailed in this memo, it does not support the basic call setup priority that is required. While a mapping could be defined between the required five precedence levels and the four Assured Forwarding classes, there is no explicit order or preferential treatment defined for those AF classes. This may need to be done. Additionally, the Expedited Forwarding PHB may provide a needed capability for the transfer of signaling messages for high priority traffic. On the other hand, it is likely that it will be necessary to use this PHB for all call control signaling in order to meet any acceptable delay limit on the transfer of messages for even the lowest priority calls. 5.3 IntServ/RSVP Although RSVP includes mention of preemption of existing reservations in favor of other higher priority ones, it does not provide detailed procedures for doing so. In principle, it should be straightforward to do so. However, it is not believed that the procedures required for establishment of a path using RSVP, and the additional procedures that would be necessary for preemption of an existing path, would allow this to be useful for the provision of Assured Service capabilities to individual calls. RSVP may be applicable for the establishment of trunk groups between switching points, with each trunk group serving a different precedence level of calls. No preemption of these trunk groups is required. 5.4 MPLS Since MPLS is fundamentally a means to emulate circuit-mode operation by establishment of a "path" which then functions like a "connection", the principles of priority and preemption could be applied to the setup and retention of this path the same as they are in the circuit-mode environment. RFC 2702 describes the requirements Pierce Expires August 2002 [Page 8] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 for such capabilities as applied to "traffic trunks". However, it uses the term "traffic trunk" to refer to a facility which is established to carry an aggregate of traffic, i.e., many telephone calls. This is the equivalent of a "trunk group" in standard telephony terminology [T1.523]. Because of the extensive procedures that are required to establish and remove such a Label Switched Path, it is believed that this prevents MPLS from being used to setup paths for individual calls. MPLS may be applicable for the establishment of the equivalent of dedicated trunk groups between switching entities (if such entities were to exist in the SIP network architecture). Each of these "trunk groups" or "traffic trunks" could exist to support a specific precedence level of traffic between two points and could be setup using the procedures defined in [MPLS-CR-LDP] or those in [RFC3209]. These documents allow the signaling of the required five levels of precedence as well as separate setup and holding priorities. 5.5 SIP The initial version of SIP [RFC2543] defined four tokens for priority levels to be used to control call setup, however, they do not equate to the levels required for Assured Service. It should also be noted that no explicit ordering of these four defined values (emergency, urgent, normal, non-urgent) can be found. The current draft revision [SIP-2543bis] adds the notion of a fifth value or "token" for "other-priority", but it does not define how this would be used. While the intention of this addition might be to allow the definition of whatever tokens are desired in various applications, this does not provide a standard to ensure interoperability without the additional burden of a coordination function such as that provided by IANA. Security is discussed in the draft revision to RFC 2543 [SIP- 2543bis], but it has been recognized in various Working Group discussions that security for all aspects of call control needs to be considered in a unified manner. Security for each individual component of call setup and release can not be designed separately. The procedure being proposed for authorization of call set-up and media allocation [SIP-CALL-AUTH] appears to be too time consuming to expect it to occur each time a user attempts to place a telephone call, especially a high-priority one. The probable delay in establishing this authorization would be contrary to the goals and requirements for Assured Service. Overloads of the proxies responsible for the Call Authorization would prevent or unacceptably delay setup of the high precedence call. Pierce Expires August 2002 [Page 9] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 6. Possible Approaches The following identify possible approaches to meeting the requirements stated above. This section is included in the draft to stimulate discussion on ways of meeting the requirements, but is not expected to be included in the final version when it is advanced toward RFC status. 6.1 Precedence Level Marking The approaches to be used for precedence level marking may need to be different for each of the following cases: A. Individual call setup: There needs to be a definition of a field to be carried in SIP which identifies the precedence levels of 0-4 of the call setup. Currently, the US military uses five values which have specific meanings (as currently defined in MLPP) and the standard may reflect these meanings. However, it is preferable to provide easy support for other network applications which utilize a different number of levels or different meanings. The specification may allow more than 5 levels. There is no need for the 65k levels defined in [RFC2751] nor is there currently a requirement to carry the separate preemption and defending priorities of [RFC2751] or the separate setup and holding priorities proposed in [MPLS-CR-LDP] and [RFC3209]. [Polk2] is expected to result in a draft which satisfies this requirement. B. Packet forwarding: To support preferential treatment on the packet transfer level, the currently defined priority levels in IPV4 and the Assured Forwarding and Expedited Forwarding PHBs of DiffServ will provide the required functionality. Appropriate mappings from the call level precedence levels to these PHBs should be defined in BCPs for various networks. An example of such mapping is provided in Annex A. C. Trunk group establishment: For MPLS, RFC 2702 defines the idea of a "traffic trunk" for which a priority may be signaled by the label distribution protocol in order to establish telephony "trunk groups". If LDP is used for label distribution, the priority defined in [MPLS-CR-LDP] should be used. Pierce Expires August 2002 [Page 10] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 If RSVP is used for label distribution, the priority defined in [RFC3209] should be used. It should be noted that the traditional definition of a "trunk group" does not include the notion of a "priority" associated with a trunk group. The priority is only associated with individual calls placed on that trunk group. It is possible that the routing logic could reserve a trunk group for higher priority traffic, but this is also not the normal application, since it wastes facilities during periods when very little priority traffic exists and it can not support the heavier load of high priority traffic when conditions cause such a high volume. 6.2 Authentication/Authorization This draft uses the following definitions from draft-ietf-aaa- transport-05: Authentication: The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication). Authorization: The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. 6.2.1 Architecture In many other cases besides call setup for Assured Service it is also necessary to perform authentication and authorization. Appropriate security mechanisms have already been defined which may be used. Efficient support for authentication and authorization requires a SIP architecture in which each user has a dedicated proxy to support originating and terminating calls. It appears that discussions of other capabilities within SIP are coming to the same conclusion for provision of other services and capabilities. For examples, [SIP- PRIVACY] states that, in order for an originating device to achieve privacy concerning its IP address related information, "UACs ... must initiate calls through their trusted proxy". In addition, the terminating UAS also has to operate through a specific trusted proxy. This association between a user and a proxy would be established at the time of authentication. 6.2.2 Authentication Procedures It is essential that a framework for security for SIP be established Pierce Expires August 2002 [Page 11] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 that allows a security association to be established between a user's terminal and their dedicated SIP proxy at the time of an initial registration. This initial registration, which includes authentication, may require an extensive number of messages and interactions with numerous network elements, including a Policy Server, and may require a rather large time as a password is verified. This registration and authentication would normally be done when a terminal is turned on, activated, or places the first call. For the purpose of Assured Service provision, as with other SIP-based services, it is expected that Authentication may be performed based on the entry of an ID and password or the use of terminal resident biometrics (e.g., iris scan) so that permission to use the services can be associated with an individual, not a device. Once registration is done, this permission is then associated with the device. 6.2.3 Authorization Procedures After the establishment of a trusted SIP proxy as a result of the authentication procedures, the authorization for the use of the Assured Service capabilities for each individual call establishment must consist of a simple exchange of a minimum number of messages between that user and that proxy. This should consist of the same message sequence as used for a non-Assured Service call in order to avoid any built-in extra overhead (and delay) for the Assured Service call. The security procedure (for all services, not just Assured Service) requires that security information be included in this INVITE which allows the proxy to validate the source of the message (the device, now that authentication is complete) and to determine the permission for that source to access the service being requested. 6.3 Preferential Treatment The preferential treatments would not be standardized unless they require signaling between network elements. Currently, most treatments envisioned are local matters within a proxy or router. Consideration of preferential treatments depends on the case: A. Per call: Preemption of existing calls, if done, would require coordination between network elements, and therefore protocol standards, especially if distinct actions are expected to reserve the preempted resources for setup of the higher precedence call. It is not expected that network initiated preemption of calls within Pierce Expires August 2002 [Page 12] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 the IP environment will be necessary. Instead, sufficient preferential treatment can be provided by applying higher call admission control limits to higher precedence calls. An example of this procedure is shown in Annex B.B. Packet level: Current capabilities of DiffServ may provide the necessary preferential treatments regarding packet transfer, including indications of priority queuing and discard priority. However, as shown in Annex A, the preferential treatment using DiffServ codepoints may require that explicit preferential treatments between different classes be defined, which does not appear to currently exist. C. MPLS/RSVP Paths: There should be no need for preemption of MPLS/RSVP established traffic trunks (trunk groups) as described in [RFC2702] and [RFC2205]. The required capability should be provided by mechanisms to reduce the traffic engineering limits placed on lower priority trunk groups (even by reducing to zero) to allow the capacity to be used for the establishment of higher priority calls. 6.4 Diversion Diversion should be based on procedures that are developed for a Call Forwarding on No Answer type service. However, it should not be dependent on a timing performed by the original called party. Again, this must be a function of either the terminating proxy. 6.5 Notification to Preempted Party Notification to the preempted party should follow whatever is done for notifications for any network-initiated release. Since it expected that actual call preemption will only be needed in the circuit mode environment, the gateway between it and the IP environment should deal with such preemption by application of the required notification (in-band) to the IP side. 6.6 Acknowledge by Preempted Party Acknowledge by the preempted party (before connection of a new call) should follow whatever is done for normal call presentation, that is, it must be acknowledged before any audio is transferred in either direction. 6.7 Protection of Signaling Information Pierce Expires August 2002 [Page 13] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 See Section 7. 7. Security Considerations 7.1 Authentication/authorization of User Access Discussions within SIP are beginning to identify the need to authenticate/authorize all access to capabilities, since virtually any could be misused resulting in harm to the network or to other users. Because Assured Service is intended to provide an authorized user with better service than other users, including the potential of actually preempting resources, it is even more important to authenticate/authorize the user's access to the Assured Service capabilities. [SIP-2543bis] describes the use of a stateless challenged-based mechanism for authentication in which a proxy server or user agent may challenge the initiator of a request to provide assurance of their identity. For real-time needs such as placing telephone calls, especially those for which Assured Service capabilities are being applied, such a challenge-based system will likely be too slow, or would itself be hampered by the very network condition which requires Assured Service be applied. 7.2 Security of Signaling Information The need to protect signaling information from disclosure is independent from the provision of Assured Service. Military/ government networks have long been built on the premise that such information needed to be protected. Bulk encryption of signaling links (as well as the user data channels) between secure switches provided much of this protection. In addition, the Signal Transfer Points of the SS#7 network could be secured against unauthorized access. It should be noted that commercial networks are now beginning to recognize the need for the same protection. In the IP environment, the signaling packets as well as the user data traverse many routers and could be accessed by unauthorized persons at any one of them. While the contents of the individual signaling messages could be hidden by encryption of the request and response for end-to-end protection of information, the header must be visible to intermediate routers. It is preferable to not require decryption/ encryption at each router. The approach has been to encrypt the contents of the signaling message but not the headers which are needed by the routers. However, the headers themselves may contain sensitive information such as precedence level and called party identification. Pierce Expires August 2002 [Page 14] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 [SIP-2543bis] describes the transport and network layer security methods which may be used to protect signaling traffic. 7.3 Security of Routing Data Of more concern than the information about an individual call is the information normally needed by Link State routing logic used by an originating device to select a route though an entire network. Such a routing function requires knowledge of the state (busy or not) of various portions of the network. When Assured Service based on precedence levels is added, this requires that the routing point also know the current loading of various precedence levels for each portion of the network. Especially in a large network, this is highly sensitive information and must not be revealed to unauthorized network elements. It should be noted that the constraint-based LSP setup proposed in [MPLS-CR-LDP] depends on the routing point knowing this information. 8. IANA Considerations It is not expected that there will be any IANA involvement in support of Assured Service beyond what is described in [Polk2]. 9. References [T1.523] ANSI T1.523-2001 Telecommunications Glossary. [T1.619] ANSI T1.619-1992 (R1999) Multi-Level Precedence and Preemption (MLPP) Service, ISDN Supplementary Service Description. [T1.619a] ANSI T1.619a-1994 (R1999) Addendum to MLPP. [T1.631] ANSI T1.631-1993 (R1999) Telecommunications - Signalling System No. 7 (SS7) - High Probability of Completion (HPC) Network Capability. [E.106] ITU-T Recommendation E.106 (2000) International Emergency Preference Scheme (IEPS). [F.706] ITU-T Recommendation F.706 (draft - for approval in Feb 2002) International Emergency Multimedia Service [I.255.3] ITU-T Recommendation I.255.3 (1990), Multilevel precedence and preemption service (MLPP). Pierce Expires August 2002 [Page 15] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 [Q.735.3] ITU-T Recommendation Q.735.3 (1993), Description for community of interest supplementary services using SS No. 7 - Multilevel precedence and preemption (MLPP). [Q.955.3] ITU-T Recommendation Q.955.3 (1993), Description for community of interest supplementary services using DSS1 - Multilevel precedence and preemption (MLPP). [RFC2205] "Resource ReSerVation Protocol (RSVP)", R. Braden, et al, Sept 1997 [RFC2597] "Assured Forwarding PHB Group", J. Heinanen, et al, June 1999. [RFC2598] "An Expedited Forwarding PHB", V. Jacobson, et al, June 1999. [RFC2702] "Requirements for Traffic Engineering Over MPLS", D. Awduche, et al, Sept 1999. [RFC2751] "Signaled Preemption Priority Policy Element", S. Herzog, January 2000. [RFC3209] RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001. [MPLS-CR-LDP] draft-ietf-mpls-cr-ldp-06, "CR-LDP: Constraint-based LSP Setup using LDP", November 2001. [SIP-CALL-AUTH] draft-ietf-sip-call-auth-03, "SIP Extension for Media Authorization", November 2001. [SIP-PRIVACY] draft-ietf-sip-privacy-03, "SIP extensions for Caller Identity and Privacy", November 2001. [SIP-2543bis] draft-ietf-sip-rfc2543bis-07, "SIP: Session Initiation Protocol" (revision), February 2002. [Ash] draft-ash-mpls-diffserv-te-alternative-02, "Alternative Technical Solution for MPLS DiffServ TE", Jerry Ash, Aug 2001. [Carlberg] draft-carlberg-ieps-framework-02, "Framework for Supporting IEPS in IP Telephony", Ken Carlberg, October 2001. [Folts] draft-folts-ieps-white-paper-01, "Emergency Telecommunications Service in Next-Generation Networks", Hal Folts, Feb 2002. Pierce Expires August 2002 [Page 16] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 [Polk1] draft-polk-mlpp-over-ip-01, "Multi-Level Precedence and Preemption over IP", James Polk, November 2001. [Polk2] draft-polk-sip-resource-00, "SIP Communications Resource Priority Header", December 2001. 10. Authors' Addresses Michael Pierce Artel 1893 Preston White Drive Reston, VA 20191 Phone: +1 410.817.4795 Email: pierce1m@ncr.disa.mil Don Choi DISA 5600 Columbia Pike Falls Church, VA 22041-2717 Phone: +1 703.681.2312 Email: choid@ncr.disa.mil ANNEX A Example Mapping of Call Precedence Levels to DiffServ Codepoints The following possible mapping is shown only to illustrate the concept of using DiffServ codepoints to assist in the provision of preferential treatment to the individual packets which make up the information transfer (connection setup and voice transfer) of an Assured Service call. It is not expected that this Annex will be a part of the final version of this document. A.1 General For each of the five precedence levels which may be signaled by the originator, a mapping should take place for each of the components involved in the call. This includes the call setup/disconnect signaling and transfer of the packets carrying the user's data (voice). This example is based on the presumption of the use of an audio coding algorithm which includes marking a portion of the individual packets which may be considered for discard in case of overload (for example, containing low-order encoding bits). A.2 Packet Forwarding Treatment Using DiffServ This example is for the case of the use of DiffServ to provide the Pierce Expires August 2002 [Page 17] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 packet forwarding preferential treatment. Each packet containing a set-up message or user data (speech) is marked with the following DiffServ codepoint: ------------------------------------------------------------------- | Precedence |Indication| Indication in user | Indication in user | | Level |in set-up | data transfer for | data transfer for | | |messages | packets not marked | packets marked for | | | | for discard by | discard by codec | | | | codec | | | | |-----------------------------------------| | | | Class | Drop | Class | Drop | | | | | precedence | | precedence | |-------------------------------------------------------------------| |Routine | None | AF1 | Medium | AF1 | High | |Priority | EF | AF1 | Low | AF1 | Medium | |Immediate | EF | AF2 | Low | AF2 | Medium | |Flash | EF | AF3 | Low | AF3 | Medium | |Flash Override| EF | AF4 | Low | AF4 | Medium | ------------------------------------------------------------------- Since there is currently no definition of differentiated handling between the various AF classes, it may be necessary instead to assign the values as shown in the following table: ------------------------------------------------------------------- | Precedence |Indication| Indication in user | Indication in user | | Level |in set-up | data transfer for | data transfer for | | |messages | packets not marked | packets marked for | | | | for discard by | discard by codec | | | | codec | | | | |-----------------------------------------| | | | Class | Drop | Class | Drop | | | | | precedence | | precedence | |-------------------------------------------------------------------| |Routine | None | AF1 | High | AF1 | High | |Priority | EF | AF1 | Medium | AF1 | High | |Immediate | EF | AF1 | Medium | AF1 | Medium | |Flash | EF | AF1 | Low | AF1 | Medium | |Flash Override| EF | AF1 | Low | AF1 | Medium | ------------------------------------------------------------------- A.3 Packet Forwarding Treatment without DiffServ When the network is not DiffServ capable, the only mapping available for packet level preferential treatment is the defined priority values within IPv4 (and their carry-over into IPv6). The same five call setup precedence levels addressed in this memo are supported by Pierce Expires August 2002 [Page 18] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 RFC 791 and the mapping is direct. ANNEX B Example Call Preferential Treatment Using Over Committing and Packet Discard This Annex is included to show an example of how preferential treatment can be provided for setup of high priority calls without preemption of lower priority calls. It is not expected that this Annex would be a part of the final version of this document, but may form the basis for another Informational draft. Preferential treatment can be provided by allowing higher precedence calls to be setup even when they result in the engineered traffic limit of a route (on an MPLS LSR, for example) to be exceeded. With the use of DiffServ AF assignments as shown in Annex A, the lower precedence calls will then experience packet discard. For example, the limits for call acceptance for new calls could be set as depicted in the following table. If the engineered capacity of a route is "x", new calls of each precedence level may be allowed based on these limits: -------------------------------------- | Precedence Level | Capacity limit of | | |-------------------| | | =< self | total | |------------------|-------------------| | Routine | .9x | .9x | | Priority | .9x | .9x | | Immediate | x | x | | Flash | 1.2x | 1.3x | | Flash-override | 1.3x | 1.5x | | | | | -------------------------------------- For example, a new Flash call is allowed to be setup if the current traffic load for all traffic at or below "Flash" is less than 1.2x and if the total load for all levels is less than 1.3x. This procedure is based on a requirement that Flash override calls should never be blocked. In the circuit-switched environment this could only be guaranteed by having as many circuits as there might be Flash override calls. For IP-based service, there is no fixed number of "circuits". The "x" referred to above is only an engineering limit based on a guarantee for the provision of a certain QoS for normal traffic, i.e., Routine and Priority. This "x" may be thought of as the number of "circuits" for that normal traffic. It is preferable to allow the setup of additional higher precedence calls with reduced Pierce Expires August 2002 [Page 19] Internet Draft Requirements for Assured Service in VoIP 21 Feb 2002 QoS rather than blocking their setup. For example, while a facility may support 100 normal calls (Routine and Priority) at the guaranteed QoS, it might support 150 flash-override calls at a reduced QoS (due to packet loss). Since the packet preferential treatment described in Annex A could result in the discard of the packets for the lower precedence calls, the higher priority calls would be provided a sufficient QoS even though they may have caused the engineered capacity of the route to be exceeded. At the same time, the lower precedence calls would experience such excessive packet loss that the users will soon disconnect without the call actually being preempted. This "encouraged disconnect" may be thought of as a "graceful preemption". Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, 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 Internet organizations, except as needed for the purpose of developing 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 are provided on an "AS IS" basis and THE INTERNET SOCIETY and THE INTERNET ENGINEERING TASK FORCE disclaim 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 of merchantability or fitness for a particular purpose. Pierce Expires August 2002 [Page 20]