PCN J. Babiarz Internet-Draft K. Chan Intended status: Informational Nortel Expires: April 17, 2007 G. Karagiannis University of Twente P. Eardley BT Research October 14, 2006 SIP Controlled Admission and Preemption draft-babiarz-pcn-sip-cap-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This framework defines a method of providing Explicit Congestion Control to real-time inelastic traffic like voice and video through the use of session admission control and preemption mechanisms. This approach uses the Pre-Congestion Notification Marking (PCN) [1] Babiarz, et al. Expires April 17, 2007 [Page 1] Internet-Draft SIP Controlled Admission and Preemption October 2006 mechanism. PCN marking is deployed in routers to measure and convey two levels of onset of congestion with the SIP controlled endpoints responding to the marking. This approach is different from what is defined in An edge-to-edge Deployment Model for Pre-Congestion Notification [3], as here the admission and preemption control function resides in the application (either in the endpoint or the application server that controls the endpoint. This framework is focused on using Session Initiated Protocol (SIP) as the application signaling protocol but other application signaling protocols could be extended for this purpose. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Terminology used in this Document . . . . . . . . . . . . . . 4 4. Operational Overview with SIP . . . . . . . . . . . . . . . . 5 4.1. PCN Metering and Marking Overview . . . . . . . . . . . . 5 4.2. Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6 4.3. Session Admission Control . . . . . . . . . . . . . . . . 8 4.4. Session Preemption . . . . . . . . . . . . . . . . . . . . 11 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Explanation of Terminology . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Babiarz, et al. Expires April 17, 2007 [Page 2] Internet-Draft SIP Controlled Admission and Preemption October 2006 1. Introduction Converged networks that are configured for multiple-services are normally engineered to provide the required quality of service using Diffserv [5], [6] technologies. Real-time inelastic traffic (e.g. voice) is normally configured to use the Expedited Forwarding (EF) PHB [8] to provide very low delay, loss and jitter transport. To stay within that engineered quality of service, and to ensure a quality of service level for that traffic, some type of admission control mechanism is necessary. Due to the sensitive nature of voice and other telephony applications (video conferencing), freely allowing these types of sessions onto a network where resources are limited can quickly lead to degradation of service that users may not tolerate. And in a packet based network, the degradation is not limited only to the offending flows, but all real-time flows within the same service class [12] are impacted. This document proposes an admission control solution based on Pre- Congestion Notification (PCN) Marking [1] process for real-time traffic and probing during session setup. The gist of the solution is that routers at selected points in the network, where congestion is most likely to occur, measure traffic per service class and perform PCN Marking [1] based on observed traffic against two levels, "admissible rate" and "supportable rate". For admission control during session setup, a probing mechanism is used between endpoints to verify bearer path connectivity and the traffic level along the path. SIP endpoints process information that is obtained during probing and make session admission decisions based on application service policy. PCN marking offers two levels of pre-congestion indication, an "admissible rate" and a "supportable rate". This adds flexibility to admission control decisions. The admissible rate indication essentially warns that network resources have reached the pre- configured traffic limit for admission of new flows but that there is still some available bandwidth. Using this information, applications can decide to filter out certain types of sessions for admission in favor of other types. For example, normal voice flows might be denied, while higher precedence calls such as E911 emergency voice flows are admitted. Whatever the admission control policy, PCN marking enables some discernment in the decision making rather than wholesale denial of sessions. Normally flows are only admitted as long as the admissible rate is not exceeded, but the admitted traffic on a link can exceed the supportable rate, e.g., due to changing flow behavior or due to redirected traffic after link or router failures. In such a case, corrective actions may be taken to reduce the traffic on the link, Babiarz, et al. Expires April 17, 2007 [Page 3] Internet-Draft SIP Controlled Admission and Preemption October 2006 e.g., by preempting already admitted flows in order to restore the QoS to the service class. The preemption procedure is as follows, SIP endpoints monitor PCN markings of media packets from already admitted flows and when they see PCN marking indicating that traffic is above the supportable rate, they invoke their session preemption policy. This session preemption policy is local to the application. The preemption policy can even be "take no action" at jurisdictions where preemption is not allowed. This proposed framework for session admission control and preemption does not introduce a significant amount of overhead to the network. The PCN marking can be implemented using simple packet metering techniques without the need for flow state information. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. 3. Terminology used in this Document Here we provide a brief definition of the terminology used in this document as it applies to the PCN work. A more complete definition and explanation of terminology for this framework is provided in Section 7. o PCN - Pre-Congestion Notification is a method for detecting the onset of congestion (before any packets are significantly queued or lost) and signalling to the endpoints via packet marking of the IP header. This method is applicable to real-time inelastic traffic. The marking of the IP header will be defined in Pre- Congestion Notification Marking [1]. o ECN - Refers to the use of the standardized two bit field in the IP header that is used for signalling Explicit Congestion Notification [7]. In this framework the ECN field maybe reused to signal two levels of Pre-Congestion Notification Marking [1]. o Admissible Rate - A bandwidth or resource threshold configured in network elements that when crossed marking of packets occurs to indicate that additional flow/session should not be admitted. In Pre-Congestion Notification Marking [1] this is called the "configured-admission-rate". Babiarz, et al. Expires April 17, 2007 [Page 4] Internet-Draft SIP Controlled Admission and Preemption October 2006 o Supportable Rate - A bandwidth or resource threshold configured in network elements that when crossed marking of packets occurs to indicate that on-path traffic has exceeded the configured service level. Normally, this would be before any significant queuing or packet loss occurs for traffic being forwarded by this service class. In Pre-Congestion Notification Marking [1] this is called the "configured-pre-emption-rate". o Service class - By service class we mean a grouping of packets belonging to one or more applications or services that generated traffic with similar characteristics and requiring similar QoS treatment. See RFC 4594 [12] for details. o Endpoint - SIP controlled media device such as a phone, a media gateway or a multi media terminal. o Admission Control - It is the action of blocking the adding of new flows or sessions in to the network in the attempt to prevent overload condition. o Preemption - During an overload condition, it is the action of removing excess traffic by randomly terminating flows or sessions. Some solution may have additional policies where termination of flows or sessions is performed in some controlled hierarchical fashion. 4. Operational Overview with SIP In the following sections, we address "how this framework is put together" by providing an operational overview using SIP. We provide an overview of the pre-congestion measurement and packet marking mechanism, and leave the details and PCN marking syntax and metering marking behavior definition to Pre-Congestion Notification Marking [1] draft. The SIP protocol provides a mechanism for two or more endpoints to join a session where they exchange media packets between each other. SIP messages control the setup and tear down of the session. The following subsections provide an operational overview for the SIP application environment, with description of session admission control and session preemption respectively. 4.1. PCN Metering and Marking Overview Routers in the network are configured to meter traffic per service class (DSCP or group of DSCPs) and when the aggregate metering rate exceeds the configured rate, perform PCN marking of packets being forwarded. The metering and marking policy may be per DSCP or group of DSCPs. The routers meter traffic against two configured rates, Babiarz, et al. Expires April 17, 2007 [Page 5] Internet-Draft SIP Controlled Admission and Preemption October 2006 "admissible rate" and "supportable rate" whereby the supportable rate is larger than the admissible rate. The "supportable rate" normally is less than the maximum service rate (but may be equal) for this service class, which itself is less than the physical links maximum line rate. The metering and marking algorithms are configured such that they provide optimal response to changing traffic levels without reacting too fast or too slow. Details of metering and marking can be found in Pre-Congestion Notification Marking [1]. Note, in Pre- Congestion Notification Marking [1], "admissible rate" is referred to as "configured-admission-rate" and the "supportable rate" is referred to as "configured-pre-emption-rate". Service Class BW 100%^ | Mark packets indicating | supportable rate is exceeded Supportable rate|---------------------------------------------- | Mark packets indicating | admissible rate is exceeded Admissible rate |---------------------------------------------- | | No marking of packets | 0%+-------------------------------------------------> Figure 1: Packet Marking by Routers We believe that the above described measurement concept and marking behavior can be extended and applied to other transmission technologies such as radio transmission. For example, a wireless access node may measure radio resources that are currently used for traffic transmission using "rise over thermal" measurement method and mark packets as per the defined thresholds and marking behaviors. It is believed that the measurement method or algorithm that is used for measuring forwarding resource and bandwidth utilization may be different and do not need to be standardization as long as they conform to the marking behavior. 4.2. Probing Mechanism The probing mechanism is an application level function residing in the application control endpoint (this can be implemented in an end user device, a phone, a media gateway, a multi media terminal or a proxy for the end user device). The probing mechanism is designed to verify: o Media packets can be sent between the application endpoints. Babiarz, et al. Expires April 17, 2007 [Page 6] Internet-Draft SIP Controlled Admission and Preemption October 2006 o The current on-path traffic level, with inclusion of the probe traffic, does not violate the required QoS of the service class. The probing mechanism is used during the session setup process prior to when real media flow packets are allowed to be sent. During the session setup process, the probing mechanism provides these additional benefits: o Should some method of route control such as ECMP (Equal Cost Multi-Path) be used, probing verifies the path that real media packets will take. o During the session admission phase, probing can also be used to detect packet loss which also can be used as additional information input to the admission decision. o Probing effectively can control over admission during "flash calling events". The probing mechanism being proposed is unidirectional UDP based packet flow with IP source and destination addresses and port numbers matching media packets. For bidirectional flows (VoIP) probing needs to be performed in both directions. With the probing mechanism being an application function, much of its configuration and detail functional goals are application dependent. The following are some considerations when the application is VoIP using SIP: o How closely does the probe traffic need to be to real media traffic? Our current simulation and analyses indicate the admission control results can be achieved when the probing flow only consumes a percentage of what the real media traffic would have used if it was admitted. o When should the probing be stopped during the admission control process? Our current simulation and analyses indicate the probing should be continued during the admission control process until the application level connection is completed, that is until the phone is answered. Our simulation results show that this use of the probing mechanism can control the probability of over admission of flows during "flash calling events" (large number of users placing calls at the same time). Hence, it effectively eases the requirement for having a large bandwidth separation between admissible and supportable rate levels. The simulation work indicated above is part of another document to be published. More detail will be provided in that future document. Babiarz, et al. Expires April 17, 2007 [Page 7] Internet-Draft SIP Controlled Admission and Preemption October 2006 The complete definition of a probing method that can be used for admission control needs to be agreed upon. And, as being part of the application function, the probing mechanism depends on and needs to be coordinated with its application usage. 4.3. Session Admission Control In this approach admission control uses a probing mechanism to determine whether there is available bandwidth for a new session. The endpoints of a session perform this probing which occurs during session setup. Depending upon results of the probing mechanism, the session will be either admitted or denied. This decision can be made within an endpoint, or by a session control server. Using SIP, the session setup procedure begins with the calling endpoint sending an "INVITE" to the called endpoint. The called endpoint must send a response. If it is busy, it will send a response indicating it is busy. Assuming that it is not busy and doesn't answer automatically, it will typically alert the user and send a response indicating that it is alerting the user (e.g. 180 Ringing). When the user responds, it will send a final (non-failure) response to the calling endpoint. The calling endpoint will acknowledge that response and media packets will begin to flow between the two endpoints. Notice this is a highly simplified overview of SIP for the purpose of this example. Admission control decisions must be made prior to the point where the called endpoint alerts the user or sends a final non-failure response. This implies that the SIP protocol itself must accommodate this decision. The mechanism for doing so is called a precondition and its operation is described in "Integration of Resource Management and Session Initiation Protocol" RFC 3312 [10]. Basically, a response from the network about network resource usability and path connectivity status is a precondition to allowing the session setup process to continue. The called party interrupts its normal call processing before alerting the user and initiates a procedure to determine the network resource usability status. The procedure in this example uses a pre-media probe flow for determining the status of the network. A probe flow consists of small UDP packets that have no real-media information, possibly transmitted at the codec packet time interval, with the endpoints monitoring for PCN marking in IP header of the received packets. Routers along the path perform PCN marking of the packets to provide path utilization levels. Because probe packets have the same source/ destination IP address and port information as the media packets, they will be forwarded along the same path as the media packets. Because the path through the network for media packets going in each Babiarz, et al. Expires April 17, 2007 [Page 8] Internet-Draft SIP Controlled Admission and Preemption October 2006 direction may be different, and loading of each link may be different in each direction, probing must take place in both directions for bidirectional flows. Details of the interaction between probes sent through the network and SIP will not be given here. However, a high level walk through is provided to illustrate the process. The walk through assumes that probing is unidirectional. That is, each device independently initiates probing as soon as it knows the destination address of the other endpoint. The number, frequency and size of probe packets to be sent falls outside the scope of this document. Suffice it to say that probe packets are sent in each direction to determine network status before call processing at the called party proceeds to the point of alerting the user. Probe packets may be sent in both directions until user answers the phone or the originator terminates the call attempt. When a new session is being setup, SIP signalling is used to exchange endpoint capabilities, including whether the endpoints are PCN capable. The following is an overview of a method that can be used for admission control of new session using the PCN method of providing network's ability to support or not to support additional traffic. Figure 2 shows the sequence of events that would take place: 1. Alice, the session originator, sends INVITE sip:bob@abc.com message to Bob, indicating that the precondition [10] for PCN needs to be met before alerting begins. 2. Upon reception of the INVITE message, Bob starts sending probe packets to Alice. As well, Bob generates and sends a 183 Session Progress SDP2 (Answer) to Alice providing Alice sufficient information so that Alice can sending probe packets to Bob. 3. Alice, upon reception of 183 Session Progress SDP2 (Answer) message, starts sending probe packets to Bob. 4. Alice monitors the PCN markings of probe packets sent by Bob and sends the received PCN marking information to Bob in UPDATE SDP3 message. 5. Bob monitors the PCN markings of probe packets sent by Alice as well as the status information received in the UPDATE SDP3 message. If all the probe measurement conditions are met, then the precondition is met and the session setup proceeds as normal. However, should one or more of the conditions not be met, then session setup is terminated with an appropriate failure message sent to Alice. Babiarz, et al. Expires April 17, 2007 [Page 9] Internet-Draft SIP Controlled Admission and Preemption October 2006 The above simplified approach is just one way of how SIP signalling can be used with PCN marking to provide admission control. Alice Bob | | | INVITE sip:bob@abc.com | (1)|-------------------------------------------------------->| | | | 183 Session Progress SDP2 (Answer) | |<--------------------------------------------------------|(2) | | |<========================================================| | UDP Probe Flow | (3)|========================================================>| | | | UPDATE SDP3 | (4)|-------------------------------------------------------->|(5) | | | 180 Ringing | |<--------------------------------------------------------| | | | 200 OK | |<--------------------------------------------------------| | | | ACK | |-------------------------------------------------------->| | | |<<=======================================================| | RTP/RTCP Media (G.711) | |=======================================================>>| | | | BYE | |<--------------------------------------------------------| | | | 200 OK | |-------------------------------------------------------->| | | Figure 2: SIP Session Setup The procedures used by the endpoint to determine whether to proceed with session setup depend on which endpoint is receiving the result and on local policy with respect to the precedence of the session. If there is a need to handle emergency (or within a self contained network other traffic designated as higher precedence) session differently than normal session, and since the network device is unaware of the precedence of the session, this decision must be made at the endpoints. In the context of admission control, application Babiarz, et al. Expires April 17, 2007 [Page 10] Internet-Draft SIP Controlled Admission and Preemption October 2006 level session admission policy may dictate that higher priority sessions may get admitted when probe packets indicate traffic level that prevent normal sessions from being admitted, e.g., PCN marking indicates traffic is above "admissible rate" but below "supportable rate". Endpoints should be authenticated as complying with the end-to-end call admission control requirements before they are allowed to initiate sessions on the network using this mechanism. With SIP this implies that the SIP Proxy or Call Server that services them directly should perform this authentication. In the absence of complying endpoints, edge device which can proxy the PCN monitoring and probing functions on behalf of the endpoint may be used. Also note that this implies that a trust relationship must exist between the endpoints, the SIP server that controls the service and routers performing the metering and marking in the network. If such trust relationship is not possible, the enforcement of the action as signalled by the PCN marking in the IP packet headers needs to be enforced at trusted network edge nodes. The methods to achieve this is for further study but some form of packet filtering may be used. 4.4. Session Preemption There are situations where the network must shed any extra traffic that it can not forward. This is normally done through packet dropping. This approach works reasonably well for elastic traffic that use flow control protocols such as TCP. However, inelastic traffic such as voice or video normally does not have the ability to adapt to available bandwidth in the network, therefore excess traffic is dropped, causing quality of service degradation to all users until the offered load is reduced. Session preemption is a method whereby some inelastic flows equaling the excess traffic are removed so that the remaining traffic can experience good quality of service. Normally, the session preemption procedure would be applied only to inelastic flows. To better understand how preemption can work, we provide an overview of one of the approaches that is currently being studied. Note, this approach is different to what is currently described in Pre- Congestion Notification Marking [1] and An edge-to-edge Deployment Model for Pre-Congestion Notification [3]. With this approach, routers using a token bucket measure the rate that is in excess of the configured supportable rate and mark a packet every "n" bytes. This marking approach marks a packet every "n" bytes of traffic that is above the "supportable rate". The marking frequency is dependent on the value of "n", the size of measured packets at the time that traffic has exceeded the supportable rate and the amount by which the Babiarz, et al. Expires April 17, 2007 [Page 11] Internet-Draft SIP Controlled Admission and Preemption October 2006 traffic has exceeded. This marking behavior is proportional to the rate that is in excess of the supportable service rate. When traffic is above the supportable rate by small amount, marking is infrequent, and when traffic exceeds by large amount, packet marking becomes more frequent. The other property of this approach is that routers mark packets belonging to random flows when traffic is in excess of supportable rate at the measuring point. Routers in the network meter packets per service class (per DSCP or group of DSCPs) and when the measured rate exceeds the configured "supportable rate" of the service class, mark packets. In this document we will call this marking as Preemption Marking (PM). PM is conveyed to the SIP controlled endpoints using the agreed upon PCN marking method in the IP header. The SIP endpoints monitor the received media packets and on detecting a packet that is PM marking, invoke the defined preemption procedure for the session. A PM marked packet is as an indication that the "supportable rate" on the packet forwarding path was exceeded. Should the service policy allow for network initiated termination of a session to proceed, the endpoint signals using SIP to the traffic origination endpoint to stop sending packets belonging to that session. For applications that need bidirectional flows, e.g., VoIP, the application using SIP signalling would terminate both sessions. In summary, the routers at the congestion points in the network mark a packet and the endpoints react to the marking by terminating the session or flow that had the marked packet. Simulation results of this preemption mechanism will be provided in another document to be published. More details will be provided in that future document. Also note that this implies that a trust relationship must exist between the endpoints, the SIP server that controls the service and routers performing the metering and marking in the network. If such trust relationship is not possible, the enforcement of the action as signalled by the PCN marking in the IP packet headers needs to be enforced at trusted network edge nodes. The methods to achieve this is for further study but some form of packet filtering may be used. One approach could be where edge nodes drop packets belonging to the marked flow. 5. Summary The high level walk through of session admission control and session preemption in previous sections provided an operational overview of this framework: Babiarz, et al. Expires April 17, 2007 [Page 12] Internet-Draft SIP Controlled Admission and Preemption October 2006 1. In the Diffserv enabled network, routers meter real-time inelastic traffic per service class and mark packets indicating that admissible rate or supportable rate at the measuring point was exceeded. 2. SIP controlled endpoints look at the markings of received packets to determine bandwidth utilization along the path from sender to receiver, and based on the marking, session state and service policy take action, admit, block or preempt. 3. During session setup, probing is performed to verify that media packets can be sent end-to-end and that the end-to-end path will have sufficient network resources (bandwidth, etc.) once real media packets are sent to meet its QoS needs. The solution provided by this framework indicates couple of dependencies: 1. There needs to be a standardized way for indicate the current resource (bandwidth, etc.) utilization condition in the network, to convey the exceeding "admissible rate" and "supportable rate" conditions. We think this dependency will be fulfilled by PCN Marking [1] draft. 2. There needs to be a way for SIP to allow the consideration of network resources prior to admitting new sessions. We think this dependency can be fulfilled by SIP precondition RFC 3312[10]. 3. There needs to be a way for the probe packets to be sent prior to making the session admission decision. There needs to be further work on this. 4. A method needs to be agreed upon for SIP endpoints to signal results of probing and reaction to PCN marking. It is believe that this will need to be done in the appropriate SIP working group. 5. Some form of trust relationship may need to be established between different control functions of the solution. This need will depend on the environment that utilize this solution. Further work on this will be needed with the attempt of using existing trust relationship method as much as possible. 6. There may be a need for the trusted network edges to enforce the reaction to PCN marking should the endpoints not behave properly. Further work on this will be needed with the attempt of using existing edge traffic filtering methods. Babiarz, et al. Expires April 17, 2007 [Page 13] Internet-Draft SIP Controlled Admission and Preemption October 2006 The resolution of these dependencies may be provided by work in PCN or by other working groups or areas. 6. Open Issues In this section we list the currently known open issues, some with possible resolutions and discussions. 1. Initially the focus of this workgroup is to define how admission control and where need preemption would be invoked in trusted networks. By trusted we mean that routers will mark packets correctly and that SIP endpoints and the application that is controlling them will respond to the marking per defined polices. This assumption maybe valid for solutions that are controlled by a single administrator or where the trust relationship is established and enforced by other means between two administrators. However, in situation where this trust relationship is not possible, a method needs to be defined so that the network edge devices can enforce the behavior that is signalled from internal network routers using PCN marking, mainly to block the addition of new flows or removal of existing marked flows. This is to address scenarios where the transport network can not trust SIP controlled endpoints or the application controlling the service. 1. Need to investigate other trust relationships, like can endpoints trust the marking as well can one network segment trust the marking of the previous network? 2. Is the ECN nonce as defined in RFC 3168 [7] and RFC 3540 [11] useful for this application? Or can one of the codepoints be reused for other purpose, possibly to indicate one of the pre-congestion traffic level? 3. What method will be used to validate the markings and is it needed with PCN where signalling is used to close the congestion control loop? 2. Currently only non rate-adaptive media codecs are addressed in this draft. A method needs to be defined so that PCN can take advantage of rate-adaptive media codecs. To start the discussion, here is one possible approach: * During session setup primary and secondary (being a lower rate) codecs are negotiated and agreed upon. Babiarz, et al. Expires April 17, 2007 [Page 14] Internet-Draft SIP Controlled Admission and Preemption October 2006 * Once a flow has been admitted and the traffic exceeds the admissible rate, routers in the network PCN marking media packet. * Upon detection by the endpoint that the admissible rate was exceeded, endpoints that have the ability to dynamically react to PCN marking do so and reduce their sending rate as agreed to during session setup. Endpoints switch to lower rate codec. * The signalling of codec change is performed using RTCP (Real Time Control Protocol) message sent from the receiver to the transmitter. 7. Explanation of Terminology In this section we provide additional explanations to terminology unique to this framework: o Admissible Rate: The configured parameter for determining if the current measured IP packet rate is within the limit for allowing flow/session admission. Notice this rate measurement is done for each service class, hence this is a "bulk" rate, not a per flow/ session rate. Please note this parameter: * Is local to each measurement point (router) of the end-to-end flow/session path. * Can be expressed in terms of percentage of total bandwidth allocated to the Diffserv Service Class [12] for handling this type of flow/session, or in absolute terms like bit per second. o Supportable Rate: The parameter for determining if the current measured IP packet rate is within the limit for providing the required QoS, the QoS support required by the application/service. Notice this rate measurement is done for each service class, hence this is a "bulk" rate, not a per flow/session rate. Please note this parameter: * Is local to each measurement point of the end-to-end flow/ session path. * Can be expressed in terms of percentage of total bandwidth allocated to the Diffserv Service Class [12] for handling this type of flow/session, or in absolute terms like bit per second. Babiarz, et al. Expires April 17, 2007 [Page 15] Internet-Draft SIP Controlled Admission and Preemption October 2006 o Admission Control: The action process taken by the application entity, based on the network condition indication provided by the packet marking, for determining if a new flow/session is to be admitted. Please note this action process: * Resides in an application functional module. * Normally occurs in the application control point of an end-to- end flow/session or intermediary node that is in the path. o Preemption: The action process taken by the application entity, based on the network condition indication provided by the packet marking, for determining if a previously admitted flow/session is to be terminated. Please note this action process: * Resides in an application functional module. * Normally occurs in the application control point of an end-to- end flow/session or intermediary node that is in the path. o Flow/Session Precedence: An application level flow/session parameter. This parameter: * Is used to indicate the relative importance of its associated flow/session. * Can be used by the application control point for admission control or preemption purpose. * Is an application level parameter. The network does not have any knowledge of this parameter. o Probing: An application level function for generation of traffic for the purpose of obtaining current network condition indication provided by packet marking and loss measurement. This is needed when there is no normal flow/session packet traffic, for example before a flow/session is admitted. The probing traffic generated needs to: * Be treated by the network the same as the normal flow/session packet traffic. Needs to be forward along the same end-to-end path that normal flow/session packet traffic. * Be understood by the application control point as different from the normal media packet traffic. Babiarz, et al. Expires April 17, 2007 [Page 16] Internet-Draft SIP Controlled Admission and Preemption October 2006 8. Security Considerations This section needs to be completed. The network needs to protect its self from overload through filtering (dropping packets) at the edges and rate limiting traffic to agreed levels. Further, in the interior network nodes, should traffic in a service class exceed the forwarding capacity, the excess traffic needs to be dropped. Methods to establish, maintain, and enforce trusts need to be defined and used. As well in networks were trust relations are not possible, enforcement of the action as indicated by PCN marking is required at network edges, blocking of new flows and removing of PM marked flows. 9. Acknowledgement The authors acknowledge a great many inputs into this framework, including the following: Corey Alexander, Marvin Krym, Stephen Dudley, John Rutledge, and Lars Westberg. 10. Informative References [1] Briscoe, B., "Pre-Congestion Notification marking", draft-briscoe-tsvwg-cl-phb-02 (work in progress), June 2006. [2] Chan, K., "Pre-Congestion Notification Problem Statement", draft-chan-pcn-problem-statement-00 (work in progress), September 2006. [3] Briscoe, B., "An edge-to-edge Deployment Model for Pre- Congestion Notification: Admission Control over a DiffServ Region", draft-briscoe-tsvwg-cl-architecture-03 (work in progress), June 2006. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [6] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [7] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Babiarz, et al. Expires April 17, 2007 [Page 17] Internet-Draft SIP Controlled Admission and Preemption October 2006 Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [8] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [10] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [11] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [12] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. Authors' Addresses Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Email: babiarz@nortel.com Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1-978-288-8175 Email: khchan@nortel.com Babiarz, et al. Expires April 17, 2007 [Page 18] Internet-Draft SIP Controlled Admission and Preemption October 2006 Georgios Karagiannis University of Twente P.O. BOX 217, 7500 AE Enschede The Netherlands Email: g.karagiannis@ewi.utwente.nl Philip Eardley BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: philip.eardley@bt.com Babiarz, et al. Expires April 17, 2007 [Page 19] Internet-Draft SIP Controlled Admission and Preemption October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Babiarz, et al. Expires April 17, 2007 [Page 20]