Internet DRAFT - draft-babiarz-pcn-sip-cap

draft-babiarz-pcn-sip-cap





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]