Internet Engineering Task Force Mike Pierce Internet Draft Artel draft-pierce-ieprep-pref-treat-examples-02.txt Don Choi January 2004 DISA Expires July 2004 Examples for Provision of Preferential Treatment in Voice over IP draft-pierce-ieprep-pref-treat-examples-02.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Copyright (C) Internet Society 2004. All rights reserved. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. Abstract Assured Service refers to the set of capabilities used to ensure that mission critical communications are setup and remain connected. [Pierce] describes the requirements, one of which is to provide preferential treatment to higher priority calls. IEPS refers to a set of capabilities used to provide a higher probability of call completion to emergency calls made by authorized personnel, usually from ordinary telephones. This also requires some form of preferential treatment. This informational memo describes some of the methods which may be applied to provide that preferential treatment. Mike Pierce Expires July 2004 [Page 1] Internet Draft Examples of Preferential Treatment January 2003 Table of Contents 0. Changes............................................................2 1. Introduction.......................................................3 2. Background.........................................................4 3. Potential Preferential Treatments..................................4 3.1. Reservation of Network Resources...............................4 3.1.1. RSVP....................................... ................4 3.1.2. MPLS........................................ ...............5 3.2. Use of Higher Call Acceptance Limits...........................6 3.3. Preferential Queuing of Signaling Messages.....................7 3.4. Preferential Queuing of User Data Packets......................7 3.5. Discarding of Packets using DiffServ...........................7 3.5.1. Treatment for Signaling Packets.............. ..............8 3.5.2. Treatment for Voice Packets................... .............9 3.6. Preemption of One or More Existing Calls......................10 4. Preemption of Some of the Resources Being Used....................11 4.1. Preemption of the Reservation.................................11 4.2. Others........................................................11 5. Security Considerations...........................................11 6. IANA Considerations...............................................11 7. References........................................................11 8. Authors' Addresses................................................13 A Overview of existing priority mechanisms..........................13 A.1 IPv4..........................................................13 A.2 DiffServ......................................................13 A.3 IntServ/RSVP..................................................14 A.4 MPLS..........................................................14 A.5 SIP...........................................................14 B Possible Protocol Approaches......................................15 B.1 Precedence Level Marking......................................15 B.2 Authentication/Authorization..................................16 B.2.1 Architecture.................................... ...........17 B.2.2 Authentication Procedures........................ ..........17 B.2.3 Authorization Procedures.......................... .........17 B.3 Preferential Treatment........................................17 B.4 Diversion if Not Answered.....................................18 B.5 Notification to Preempted Party...............................18 B.6 Acknowledge by Preempted Party................................19 B.7 Protection of Signaling Information from Disclosure...........19 B.8 Accounting....................................................19 B.9 Call Control Signaling Precedence.............................19 B.10 Interworking..................................................20 0. Changes This draft was originally submitted under SIPPING, but now being submitted under IEPREP to focus consideration and discussion in that WG in conjunction with the related discussions for IEPS. Mike Pierce Expires July 2004 [Page 2] Internet Draft Examples of Preferential Treatment January 2003 (SIPPING) -00 Initial version based on material removed from draft- pierce-sipping-assured-service-01. (IEPREP) -00 Added references to IEPREP in Intro. Update references. add details about packet dropping procedure. (IEPREP) -01 Updated references (IEPREP) -02 Added Annexes from requirements draft. 1. Introduction The requirements for Assured Service in support of networks requiring precedence treatment for certain calls is are described in [Pierce]. One of those requirements is Preferential treatment, which is the following: 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 Several current drafts describe the requirements for provision of the International Emergency Preparedness Scheme (IEPS). This service requires some types of preferential treatment for these calls, which can be viewed as a subset of the requirements for Assured Service listed above. These requirements include: . higher probability of call completion Mike Pierce Expires July 2004 [Page 3] Internet Draft Examples of Preferential Treatment January 2003 . lower probability of premature disconnect . distinguish IEPS data packets from other types of VoIP Packets in order to give them "priority". . alternate path routing This informational memo describes some ways in which the above listed preferential treatments may be provided by utilizing current or new capabilities. Two annexes provide background information on current support within various IETF defined protocols for preferential treatment and describe some of the possible approaches to providing additional preferential treatment capabilities. 2. Background The requirement for Precedence Level marking of a call setup attempt using SIP [RFC3261] will be met by the proposed Resource Priority header [Resource]. The value carried in this header represents the relative precedence level of the call, and is used to control any of the following described procedures for providing Preferential Treatment. 3. Potential Preferential Treatments The requirement to provide preferential treatment to calls may be met by applying any combination of the following procedures: 3.1. Reservation of Network Resources This procedure involves pre-reserving certain network resources during periods when no higher precedence traffic is present so as to be prepared to handle a given level of high precedence traffic in the case of an emergency. While this method is already used in the circuit switched environment, it is less than desirable since it requires a tradeoff between the amount of wasted resources during non-emergency periods and the amount of emergency traffic which can be handled using those reserved facilities. IETF defined QoS mechanisms for packet-mode operation offer some improvement to this situation by allowing the amount of reserved resources to be adjusted. 3.1.1. RSVP RSVP may be used to establish multiple trunk groups between switching points, with each trunk group serving a different precedence level of calls. Each trunk group would be sized based on Mike Pierce Expires July 2004 [Page 4] Internet Draft Examples of Preferential Treatment January 2003 the number of simultaneous calls of that precedence level to be supported. (In this context, a trunk group refers to a facility which can support a certain number of voice connections at a certain Quality of Service level. As noted later, the number of connections can be increased with a corresponding decease in the QoS level.) With TE, the reserved sizes of these trunk groups could be adjusted during times of emergency. No preemption of these trunk groups is needed. However, reducing the size of a group to near zero would prevent further calls from using it while allowing existing calls to continue. 3.1.2. MPLS MPLS may be used to establish the equivalent of dedicated trunk groups between switching entities, enterprise network, etc. Each of these "trunk groups" could exist to support a specific precedence level of traffic between two points and could be setup using the procedures of CR-LDP [RFC3212] or RSVP-TE [RFC3209]. These support the signaling of the required five levels of precedence. 3.1.2.1. Constraint-based LSP Setup using LDP CR-LDP [RFC3212] defines an extension to LDP to provide a constraint-based routing using MPLS. One of the constraints is based on the notion of a "priority" level for the new setup. It includes the signaling of a setup priority and a holding priority with the value of each being 0-7 (0 is the highest priority). When setting up an LSP as a trunk group to carry the traffic of one of the expected precedence levels defined in [Pierce], the following mapping would be used: +------------------+------------------------+ | Assured Service | RFC3212 Preemption TLV | | Precedence +-----------+------------+ | Level | SetPrio | HoldPrio | +------------------+-----------+------------+ | Routine | 4 | 0 | | Priority | 3 | 0 | | Immediate | 2 | 0 | | Flash | 1 | 0 | | Flash Override | 0 | 0 | +------------------+-----------+------------+ This mapping prevents any preemption of a trunk group for the establishment of another. Rather, it is expected that trunk groups for all precedence levels would be initially created and remain. Only their allocated size might be changed. If actual preemption were desired, the appropriate HoldPrio values would be used. Mike Pierce Expires July 2004 [Page 5] Internet Draft Examples of Preferential Treatment January 2003 3.1.2.2. RSVP-TE: Extensions to RSVP for LSP Tunnels As an alternative to LDP, RSVP-TE [RFC3209] defines the use of RSVP with extensions to perform the label distribution for MPLS. It also includes the same setup and holding priorities as defined in CR-LDP [RFC3212]. When using RSVP as the label distribution protocol, the same mapping shown above for LDP would be used. 3.2. Use of Higher Call Acceptance Limits One aspect of preferential treatment may be provided, without resorting to preemption of calls, by allowing higher precedence calls to be setup even when they result in exceeding the engineered traffic limit on a facility (on an MPLS LSR, for example). This procedure presumes the existence of a call acceptance function which is aware of the traffic loading on various links and entities, and compares these against some thresholds before allowing the establishment of a new call (packet flow). For example, the limits for call acceptance for new calls could be set as depicted in the following table, where the engineered capacity of a route or facility is "x". A new call of each precedence level would be allowed only if the current load is within the limit shown: +------------------+-----------+ | Precedence Level | Capacity | | | limit of | +------------------+-----------+ | Routine | .9x | | Priority | .95x | | Immediate | x | | Flash | 1.1x | | Flash-override | 1.2x | +------------------+-----------+ Explanation of table: In this example, a new Flash call is allowed to be setup if the current traffic load for all traffic on the facility is less than 1.2x. In the example shown in this table, Routine traffic is always prevented from using the last 10% of the capacity. The choice of the multipliers would be based on an analysis of the tradeoff between getting the high precedence level call through vs. sacrificing its QoS. It would depend on the voice encoding algorithms typically used and the end user expectations. This procedure is based on a requirement that Flash override calls should "never" be blocked. (In a probability-based system, there is no such thing as "never".) 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 Mike Pierce Expires July 2004 [Page 6] Internet Draft Examples of Preferential Treatment January 2003 number of "circuits" on any facility. 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 normal traffic. It is preferable to allow the setup of additional higher precedence calls with reduced QoS rather than blocking their setup. For example, while a particular facility may support 100 normal calls (Routine and Priority) at the guaranteed QoS, it might support 130 flash-override calls at a reduced, yet acceptable, QoS (due to packet loss) when in an emergency situation. Since the packet preferential treatment using Diff-Serv described in Section 3.5 could result in the discard or loss of the packets for the lower precedence calls, the higher precedence calls could still be provided a sufficient QoS even though they may have caused the engineered capacity of the route to be exceeded. The lower precedence calls will then experience higher packet discard rates or queuing delay times. If the discard rate or delay for these lower precedence calls is excessive, the end user will experience poor QoS and will likely disconnect, thereby freeing up the resources. 3.3. Preferential Queuing of Signaling Messages There is no plan to apply preferential queuing to signaling messages (ahead of other signaling messages), just as this was not done in the circuit switched network. No advantage can be shown for such a procedure and it would only aggravate the problem of out-of-order messages. 3.4. Preferential Queuing of User Data Packets It is not expected that priority queuing of user data packets (ahead of other user data packets of the same type) would provide a useful capability. 3.5. Discarding of Packets using DiffServ Within DiffServ, Assured Forwarding [RFC2597] provides four classes and three drop precedences for each class (12 DSCP code points). One of these classes could be used for the signaling messages for session establishment and release. AF is not considered as being appropriate for audio. Expedited Forwarding [RFC3246] defines a single class (DSCP code point) and operation, but does not include multiple drop precedences as AF does. The intention of EF is to "provide low loss, latency and jitter" and is understood to be intended for traffic such as speech, although RFC 3246 does not explicitly mention speech or voice. However, speech is less susceptible to loss than the signaling traffic and, under some traffic situations, will constitute a much larger portion of the overall load. Therefore, multiple drop Mike Pierce Expires July 2004 [Page 7] Internet Draft Examples of Preferential Treatment January 2003 precedences to alleviate overload are more appropriate to EF than they are to AF. The result of this use of DiffServ classes is that voice packets are always given priority over the signaling packets and all voice packets are treated the same. While this is the desired behavior in many cases, it is not desired in those cases in which a limited sized facility could become completely occupied by voice traffic (using EF). In this situation, further signaling messages (using AF), including those to setup new high precedence calls and those to release low precedence calls, would be lost or excessively delayed. Therefore, it is necessary to reserve a small capacity for use by the AF class which serves the signaling traffic as described in Section 2.10 of EF [RFC3246]. For that portion of the capacity using EF for voice, the required preferential treatment for the five call precedence levels may be provided by the use of multiple drop precedence (probability) levels for packets. The procedures for these drop precedence levels would be the same as defined currently for the three levels for each class in AF [RFC2597]. Five such levels for packet marking, using DSCPs, are needed to provide the required functionality. In the absence of "standardized" DSCP values, local values could be assigned. Based on the definitions for AF, these levels are referred to here as: . Very low (i.e., lowest probability of being dropped) . Low . Medium . High . Very high (i.e., highest probability of being dropped) The following possible mappings are shown 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 (both the connection setup signaling and the voice transfer) of an Assured Service call. 3.5.1. Treatment for Signaling Packets Consideration could be given to utilization of different drop precedences for the signaling messages associated with different precedence sessions. However, using SS#7 in the PSTN as a basis, it might also be meaningful to provide different drop precedences based on the type of message rather than only based on the precedence of the call. For example, for routine traffic, those messages which cause the release of sessions could be given a lower drop precedence than those which set up new sessions in order to allow such releases to take place properly under overload conditions. High precedence calls, on the other hand could use a lower drop precedence level for Mike Pierce Expires July 2004 [Page 8] Internet Draft Examples of Preferential Treatment January 2003 session setup messages than those of routine precedence calls. The following table shows what is defined for SS#7 [T1.111], including High Probability of Completion [T1.631] and MLPP [T1.619], and what might be used for SIP. (Note: The highest SS#7 Congestion Priority Level, i.e., "3", is the last to be dropped during congestion.) (Refer to RFC 3398 for mapping of ISUP to SIP messages.) +---------------------------------+-----------------------------+ | SS#7 | SIP | +--------------------+------------+----------------+------------+ | Message | Congestion | Message | Drop | | | Priority | | Precedence | | | Level | | Level | +--------------------+------------+----------------+------------+ | Network management | 3 | ? | low | | ANM | 2 | 200 OK (INVITE)| medium | | RLC | 2 | 200 OK (BYE) | (note) | | IAM (MLPP) | 1 or 2 | INVITE (AS) | low/medium | | IAM (HPC) | 1 | INVITE (IEPS) | low | | ACM | 1 | 18x | medium | | CPG | 1 | 100 Trying/18x | medium | | REL | 1 | BYE | low | | IAM (normal) | 0 | INVITE (normal)| high | | Others | 0 | | | +--------------------+------------+----------------+------------+ Note: For SIP, unless noted otherwise, all ACKs should have the same preferential treatment as the message they are acknowledging. 3.5.2. Treatment for Voice Packets This example is for the case of the use of DiffServ to provide the packet forwarding preferential treatment through multiple drop precedence levels. It uses the Multi-Level Expedited Forwarding Per Hop Behavior [Silverman]. Each packet containing user data (voice) is marked with a unique DiffServ codepoint to indicate one of the following levels and resulting treatment: Mike Pierce Expires July 2004 [Page 9] Internet Draft Examples of Preferential Treatment January 2003 +--------------+--------------------+-----------------+ | Precedence | Indication in user | Drop if current | | Level | voice packets | queue is more | | +-------+------------+ than -- % full | | | Class | Drop | (note 1) | | | | precedence | | +--------------+-------+------------+-----------------+ |Routine | MLEF | Very high | 80% | |Priority | MLEF | High | 90% | |Immediate | MLEF | Medium | 100% | |Flash | MLEF | Low | 110% | |Flash Override| MLEF | Very low | 120% | +--------------+-------+------------+-----------------+ All voice traffic is then served by a single instance of MLEF, and served by a single (strict FIFO) queue. This results is an equal treatment in terms of delay variation (often called "jitter") for all precedence levels for those packets which are delivered, but achieves this by selective packet discard. The discard may use a simple tail dropping algorithm as shown in the above table or a form of "Random Early Detection" as described in [RFC2309] to drop some packets before the queue actually reaches the fill shown above. However, since the packets in this queue are not using TCP and can not be bursty or "aggressive", there appears to be no advantage gained by the complexity of early detection and random dropping. Note 1: The "queue full" here refers to the engineered limit, that is, the limit which needs to be applied in order to meet the requirements of the EF PHB and the desired QoS. Since this calculation is based on probabilities of achieving a certain target QoS, it can be temporarily exceeded as described in the following section. 3.6. Preemption of One or More Existing Calls The procedures described above for use of higher call acceptance limits and selective discard of voice packets based on the precedence level of the call reduce or eliminate the need to perform preemption of existing calls within the IP domain. The statistical nature of packet transmission makes it possible to "squeeze" an additional high precedence call into an already "full" facility, as illustrated in the previous section. It should be noted that, in the extreme case, these procedures would result in the same effect as preemption, since the resources of the lower precedence calls would be so severely degraded (via packet loss) that communication would be impossible and the users would likely disconnect. Because each packet flow arrives at somewhat regular intervals, it is expected that, when packet loss is occurring due to discard, that the loss will not be random across all flows using the DSCP with the highest discard probability. Rather, losses will likely be bursty on Mike Pierce Expires July 2004 [Page 10] Internet Draft Examples of Preferential Treatment January 2003 each flow, with most discards being on one flow for many consecutive packets. When interworking with circuit switched portions of the telecommunications network, preemption procedures are still required within transport facilities which are based on fixed numbers of circuits. In some cases, this preemption results in specific procedures being applied in the packet portion, such as notifications of preemption and forced disconnect of a session. 4. Preemption of Some of the Resources Being Used The "preemption" of some of the resources being used by lower precedence traffic may be accomplished through the packet discard described above. 4.1. Preemption of the Reservation Based on traffic engineering, the amount of resources allocated to reserved paths (e.g., MPLS or RSVP) could be adjusted. For example, when an emergency situation occurs, the need for more resources to support higher priority traffic could be recognized. The existing LSPs could be changed using the procedures of [RFC3214] to allow the size of those LSPs supporting the higher priority traffic to be increased while others are decreased. 4.2. Others There may be other procedures which could be used to provide the required preferential treatments. 5. Security Considerations The security considerations are covered in [Pierce]. 6. IANA Considerations It is not expected that there will be any IANA involvement in support of provision of Preferential Treatment for Assured Service beyond what is described in [Resource]. 7. References [RFC2205] "Resource ReSerVation Protocol (RSVP)", R. Braden, et al, September 1997 [RFC2309] "Recommendations on Queue Management and Congestion Avoidance", B. Braden, April 1998. Mike Pierce Expires July 2004 [Page 11] Internet Draft Examples of Preferential Treatment January 2003 [RFC2597] "Assured Forwarding PHB Group", J. Heinanen, et al, June 1999. [RFC2702] RFC 2702, "Requirements for Traffic Engineering Over MPLS", D. Awduche, et al, September 1999. [RFC2751] "Signaled Preemption Priority Policy Element", D. Thaler, January 2000. [RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels", D. Awduche, December 2001. [RFC3212] "CR-LDP: Constraint-based LSP Setup using LDP", B. Jamoussi, et al, January 2002. [RFC3214] "LSP Modification Using CR-LDP", J. Ash, et al, January 2002. [RFC3246] "An Expedited Forwarding PHB", B. Davie, et al, March 2002. [RFC3261] "SIP: Session Initiation Protocol", J. Rosenberg, et al, June 2002. [RFC3313] RFC 3313, "Private SIP Extensions for Media Authorization", W. Marshall, May 2002. [T1.111] ANSI T1.111-2001, "Signalling System No. 7 (SS7) - Message Transfer Part". [T1.523] ANSI T1.523-2001, "Telecommunications Glossary". [T1.619] ANSI T1.619-1992 (R1999) "ISDN - Multi-Level Precedence and Preemption (MLPP) Service Capability". [T1.631] ANSI T1.631-1993 (R1999) "Telecommunications - Signalling System No. 7 (SS7) - High Probability of Completion (HPC) Network Capability". [Aboda] draft-ietf-aaa-transport-12, "Authentication, Authorization and Accounting (AAA) Transport Profile", Bernard Aboda, January 2003. (in editor's queue) [Johnston] draft-ietf-sipping-service-examples-05, "Session Initiation Protocol Service Examples", A. Johnston, et al, August 2003. [Pierce] draft-pierce-ieprep-assured-service-req-02, "Requirements for Assured Service Capabilities in Voice over IP", Jan 2004 Mike Pierce Expires July 2004 [Page 12] Internet Draft Examples of Preferential Treatment January 2003 [Resource] draft-ietf-sip-resource-priority-01, "SIP Communications Resource Priority Header", Henning Schulzrinne and James Polk, July 2003. [Silverman] draft-silverman-mlefphb-02, "Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB", Steve Silverman, et al, June 2003. 8. 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 A Overview of existing priority mechanisms Current support within various IETF defined protocols and ongoing initiatives is not considered to be sufficient for Assured Services requirements. This informative Annex details some of these. This Annex is being included here for reference, but is not intended to be included as this draft moves forward for approval as an RFC. A.1 IPv4 Although support for the traditional five precedence levels was included in the TOS field of IPv4 from the earliest days, support for this field is not universal, and it only provides packet level priority. It does not provide call setup priority or control of call retention. A.2 DiffServ Within DiffServ, Assured Forwarding [RFC 2597] provides four classes and three drop precedences for each class. One of these classes could be used for the signaling messages for session establishment and release. The multiple drop precedences could be used for various signaling messages, as is being done with the equivalent call control messages in ISUP for SS#7. However, AF is not considered to be appropriate for voice. Mike Pierce Expires July 2004 [Page 13] Internet Draft Examples of Preferential Treatment January 2003 Expedited Forwarding [RFC 3246] is intended for voice, but it treats all such voice packets the same. It does not define multiple drop precedences as AF does so there is no way to provide preferential treatment to packets associated with higher priority calls. A.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. A.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 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. 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 [RFC3212] or those in [RFC3209]. These documents allow the signaling of the required five levels of precedence as well as separate setup and holding priorities. A.5 SIP SIP [RFC3261] defines four tokens for priority levels (non-urgent, normal, urgent, and emergency), however, they are not intended to be used to control call setup nor do they equate to the levels required for Assured Service. The proposed Resource Priority Header [Resource] provides for the five precedence levels required for per call marking. Security is discussed in [RFC3261] and many drafts, but it has been recognized in various Working Group discussions that security for Mike Pierce Expires July 2004 [Page 14] Internet Draft Examples of Preferential Treatment January 2003 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 [RFC3313] 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. Use of this type of procedure would require that preferential treatments also be applied to all message interactions and proxy processing of the sequence of messages required for the authorization. Overloads of the proxies responsible for the Call Authorization would prevent or unacceptably delay setup of the high precedence call. B Possible Protocol Approaches The following identify possible approaches to meeting the requirements stated above. This Annex 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. B.1 Precedence Level Marking The approaches to be used for precedence level marking are 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 for the call (session) setup. Currently, MLPP uses five values which have specific meanings as currently defined in applicable standard [T1.619, I.225.3]) and the definition of the field in SIP 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 separate preemption and defending priorities [RFC2751] or separate setup and holding priorities [RFC3212, RFC3209]. The proposed Resource Priority Header [Resource] is expected to satisfy this requirement. Mike Pierce Expires July 2004 [Page 15] Internet Draft Examples of Preferential Treatment January 2003 B. Packet forwarding: To support preferential treatment on the packet transfer level, the current lack of any priority mechanism within the single Expedited Forwarding class of DiffServ will need additional capabilities to provide the required functionality. Just as Assured Forwarding includes multiple drop precedences for each class, there should be multiple drop precedences for EF, which is intended for voice. In fact, voice transport is more tolerable to dropped packets than many of the intended uses of AF classes. (It should be emphasized again that such multiple "drop precedence" levels for EF would not provide an actual priority forwarding mechanisms per packet, e.g., priority queuing of some packets ahead of other within that EF class, just as there is no such capability included within the AF PHB definition.) In order to provide the required preferential treatments for the five call precedence levels, it is required to provide five corresponding drop precedence levels for the voice packet handling. The proposed MLEF PHB [Silverman] provides this capability. 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 [RFC3212] should be used. 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 high priority traffic exists and it can not support the heavier load of high priority traffic when conditions cause such a high volume. B.2 Authentication/Authorization This draft uses the following definitions from draft-ietf-aaa- transport-12 [Aboda]: . 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). Mike Pierce Expires July 2004 [Page 16] Internet Draft Examples of Preferential Treatment January 2003 . 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. B.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. Refer to [pierce2] for a discussion of the architecture required to support the authentication/authorization requirements in a network providing the Assured Service capability. B.2.2 Authentication Procedures It is essential that a framework for security for SIP be established 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. It is not performed for each call. This reduces the need to apply preferential treatment procedures to the authentication process. 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. B.2.3 Authorization Procedures The procedures for authorization per call should consist only of added fields/information within the normal messages used for basic call setup as defined for SIP [RFC3261]. It should not require additional messages to be added to the call setup sequence. B.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: Mike Pierce Expires July 2004 [Page 17] Internet Draft Examples of Preferential Treatment January 2003 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 (sessions) within the IP environment will be necessary. Instead, sufficient preferential treatment can be provided by applying higher call admission control limits and lower drop precedence procedures to higher precedence calls. Examples of these procedures are shown in [Pierce1]. B. Packet Level: Current capabilities of DiffServ, with additional code points for drop precedences within an EF-type class, will provide the necessary preferential treatments regarding voice packet transfer, including indications of discard priority. It will also be necessary to define new capabilities to provide the necessary preferential treatment for call control signaling. 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 in other traffic engineered traffic trunks. B.4 Diversion if Not Answered It is expected that Diversion would 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 calling or called parties' devices, but rather, be the function of a proxy serving the called party as shown in the proposed Service Examples [Johnston]. B.5 Notification to Preempted Party Notification to the preempted party should follow whatever is done for notifications for any network-initiated release. Since it is 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 party on the IP side. Mike Pierce Expires July 2004 [Page 18] Internet Draft Examples of Preferential Treatment January 2003 B.6 Acknowledge by Preempted Party Acknowledge by the preempted party (before connection of a new call) should follow the same general procedures as used for normal call presentation, that is, the new call is acknowledged (answered) before any audio is transferred in either direction between end users. (Note that this does not refer to the transfer of "media" between the terminals, only the transfer of actual audio between the persons using the terminals.) B.7 Protection of Signaling Information from Disclosure See Section 7. B.8 Accounting This draft uses the following definition from draft-ietf-aaa- transport-12 [Aboda]: Accounting: The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation. Call detail records (CDR) can be maintained by the proxy, since it knows which users are authorized to place Assured Service calls and knows when they do. Since not actually done to support billing functions, it is not expected that a record of call duration is required. B.9 Call Control Signaling Precedence Adequate precedence (and preferential treatment) can be provided to call control signaling, with respect to user data carried by EF, by utilization of a single AF class (single queue) for all call control signaling. A weighted queue serving algorithm is then required to guarantee that this queue receives a minimum percentage of the bandwidth of the outgoing facility, if it needs it, regardless of the volume of "higher priority" packers (such as voice in an "EF" queue). It is expected that this percentage for call control signaling would be less than 5% of the total bandwidth. To address the situation in which the signaling traffic exceeds the minimum guaranteed and there is excessive traffic, thereby blocking some call control messages, the multiple drop precedence capability of AF would suffice. Relative drop precedences for SIP messages can be modeled on those use in ISUP. In order to address the other side of the problem - preventing long call control messages from adversely affecting the performance of the voice packets - it may be necessary to utilize a packet segmentation scheme. Mike Pierce Expires July 2004 [Page 19] Internet Draft Examples of Preferential Treatment January 2003 B.10 Interworking Interworking requirements can be met in the following manner: Within a single network which supports two or more priority schemes, the network operator determines the relative priority and preferential treatments to apply. For example, the operator may decide that the IEPS priority for "Authorized Emergency" will fall between the Assured Service levels of Immediate and Flash. At the gateway between two networks which support two different priority schemes, the operator of the gateway determines and performs the mapping between the two schemes. For example, for the priority schemes defined for Assured Service (in the Defense Switched Network or DSN) and assuming 3 levels (normal, public emergency, and authorized emergency) for IEPS (in the public network), the mappings could be: From DSN To public network ------------ --------------------- Routine --> Normal Priority --> Normal Immediate --> Normal Flash --> Authorized Emergency Flash Override --> Authorized Emergency and From Public network TO DSN -------------------- ------- Normal --> Routine Public Emergency --> Immediate Authorized Emergency --> Flash Full Copyright Statement Copyright (c) The Internet Society (2003). 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 Mike Pierce Expires July 2004 [Page 20] Internet Draft Examples of Preferential Treatment January 2003 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 on 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 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mike Pierce Expires July 2004 [Page 21]