Internet DRAFT - draft-lefaucheur-rsvp-ecn

draft-lefaucheur-rsvp-ecn




                   RSVP Extensions for PCN-based CL          June 2006 
 
 
                                                                        
   Internet Draft                                  Francois Le Faucheur 
                                                            Anna Charny 
                                                    Cisco Systems, Inc. 
                                                                        
                                                            Bob Briscoe 
                                                           Phil Eardley 
                                                                     BT 
                                                                        
                                                            Joe Barbiaz 
                                                           Kwok-Ho Chan 
                                                                 Nortel 
   draft-lefaucheur-rsvp-ecn-01.txt                                     
   Expires: December 2006                                     June 2006 
    
                   RSVP Extensions for Admission Control  
           over Diffserv using Pre-congestion Notification (PCN) 
    
    
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. 
    
    
Abstract 
    
   This document specifies the extensions to RSVP for support of the 
   Controlled Load (CL) service over a Diffserv cloud using Pre-
   Congestion Notification as defined in [CL-DEPLOY]. 
    
    
 
 
Le Faucheur, et al.                                           [Page 1] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
Copyright Notice 
      Copyright (C) The Internet Society (2006) 
    
 
Specification of Requirements 
    
   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 [RFC2119]. 
    
    
1.  Introduction 
    
   [RSVP] defines the Resource reSerVation Protocol which can be used by 
   applications to request resources from the network. The network 
   responds by explicitely admitting or rejecting these RSVP requests. 
   Certain applications that have quantifiable resource requirements 
   express these requirements using Intserv parameters as defined in the 
   appropriate Intserv service specifications ([RFC2212], [RFC2211]). 
   Controlled Load (CL) service is a quality of service (QoS) closely 
   approximating the QoS that the same flow would receive from a lightly 
   loaded network element [RFC2211]. CL is useful for inelastic flows 
   such as those for real-time media. 
    
   [CL-DEPLOY] describes a deployment model to achieve a Controlled Load 
   (CL) service ([RFC2211]) by using distributed measurement-based 
   admission control edge-to-edge, i.e. within a particular region of 
   the Internet. The measurement made is of CL packets that have their 
   Congestion Experienced (CE) codepoint set as they travel across the 
   edge-to-edge region. Setting the CE codepoint, which is under the 
   control of a new Pre-congestion Marking behaviour, provides an "early 
   warning" of potential congestion. This information is used by the 
   ingress node of the edge-to-edge region to decide whether to admit a 
   new CL microflow. 
     
   [CL-DEPLOY] also describes how the framework uses rate-based pre-
   emption to maintain the CL service to as many admitted microflows as 
   possible even after localised failure and routing changes in the 
   interior of the edge-to-edge region. 
    
   The edge-to-edge architecture of [CL-DEPLOY] is a building block in 
   delivering an end-to-end CL service. The approach is similar to that 
   described in [INTSERV-DIFFERV] for Integrated services operation over 
   Diffserv networks. Like [INTSERV-DIFFERV], an IntServ class (CL in 
   our case) is achieved end-to-end, with a CL-region viewed as a single 
   reservation hop in the total end-to-end path. Interior nodes of the 
   CL-region do not process flow signalling nor do they hold state.  
    

 
 
Le Faucheur, et al.                                           [Page 2] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   [CL-DEPLOY] assumes that the end-to-end signalling mechanism is RSVP. 
   This document specifies the extensions to RSVP for support of the 
   Controlled Load (CL) service over a Diffserv cloud using Pre-
   Congestion Notification as defined in [CL-DEPLOY]. 
    
    
2.  Definitions 
    
   For readability, a number of definitions from [CL-DEPLOY] are 
   repeated here: 
    
   o ingress edge (or ingress gateway): router at an ingress to the CL-
      region. A CL-region may have several ingress gateways.   
    
   o egress edge (or egress gateway): router at an egress from the CL-
      region. A CL-region may have several egress gateways.  
    
   o Interior router: a router which is part of the CL-region, but is 
      not an ingress or egress gateway.  
    
   o CL-region: A region of the Internet in which all traffic 
      enters/leaves through an ingress/egress gateway and all routers 
      run Pre-Congestion Notification marking. A CL-region is a 
      DiffServ region (a DiffServ region is either a single DiffServ 
      domain or set of contiguous DiffServ domains), but note that the 
      CL-region does not use the traffic conditioning agreements (TCAs) 
      of the (informational) DiffServ architecture.  
    
   o CL-region-aggregate: all the microflows between a specific pair of 
      ingress and egress gateways. Note there is no field in the flow 
      packet headers that uniquely identifies the aggregate. 

   o Congestion-Level-Estimate: the number of bits in CL packets that 
      are admission marked (or pre-emption marked), divided by the 
      number of bits in all CL packets. It is calculated as an 
      exponentially weighted moving average. It is calculated by an 
      egress gateway for the CL packets from a particular ingress 
      gateway, i.e. there is a Congestion-Level-Estimate for each CL-
      region-aggregate. 
    
   o  Sustainable-Aggregate-Rate: the rate of traffic that the network 
      can actually support for a specific CL-region-aggregate. So it is 
      measured by an egress gateway for the CL packets from a particular 
      ingress gateway. 

     
    
3.  Overview of RSVP extensions and Operations 
 
 
 
Le Faucheur, et al.                                           [Page 3] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
3.1.  Overall QoS Architecture 
     
    The overall QoS architecture is described in [CL-DEPLOY]. For 
    readability, the Figure of [CL-DEPLOY] illustrating this QoS 
    architecture is reproduced below in Figure 1. 
    
   ----   -----  -----------------------------------------  -----  -----     
   |   |  |   |  |                                       |  |   |  |   | 
   |   |  |   |  |Ingress         Interior         Egress|  |   |  |   | 
   |   |  |   |  |gateway         routers         gateway|  |   |  |   | 
   |   |  |   |  |-------+  +-------+  +-------+  +------|  |   |  |   | 
   |   |  |   |  | PCN-  |  | PCN-  |  | PCN-  |  |      |  |   |  |   | 
   |   |..|   |..|marking|..|marking|..|marking|..| Meter|..|   |..|   | 
   |   |  |   |  |-------+  +-------+  +-------+  +------|  |   |  |   | 
   |   |  |   |  |  \                                 /  |  |   |  |   | 
   |   |  |   |  |   \                               /   |  |   |  |   | 
   |   |  |   |  |    \  Congestion-Level-Estimate  /    |  |   |  |   | 
   |   |  |   |  |     \  (for admission control)  /     |  |   |  |   | 
   |   |  |   |  |      --<-----<----<----<-----<--      |  |   |  |   | 
   |   |  |   |  |      Sustainable-Aggregate-Rate       |  |   |  |   | 
   |   |  |   |  |        (for flow pre-emption)         |  |   |  |   | 
   |   |  |   |  |                                       |  |   |  |   | 
   ----   -----  -----------------------------------------  -----  -----     
   Sx     Access               CL-region                   Access    Rx 
   End    Network                                          Network   End 
   Host                                                              
   Host 
                   <------ edge-to-edge signalling -----> 
                 (for admission control & flow pre-emption) 
    
   <-------------------end-to-end QoS signalling protocol--------------> 
     
    
                   Figure 1: Overall QoS Architecture  
    
    
3.2.  Overview of Procedures for Admission Control of New Reservations 
    
   As mentioned earlier, [CL-DEPLOY] describes a framework to achieve a 
   Controlled Load (CL) service by using distributed measurement-based 
   admission control edge-to-edge, i.e. within a particular region of 
   the Internet. This section describes RSVP operations to support such 
   an admission control scheme relying on Pre-Congestion Notification in 
   the eddge-to-edge region. 
    
   When a new Path message is received by Ingress Edge, the Ingress Edge 
   does regular RSVP processing (including updating the RSVP PHOP) and 
   forwards the Path towards destination.  
    
 
 
Le Faucheur, et al.                                           [Page 4] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   All the PCN-capable Interior nodes are not RSVP-capable (or have RSVP 
   processing disabled) and thus simply ignore the Path message. 
    
   When the Path message arrives at the Egress Edge, the Egress Edge 
   processes it as per regular RSVP processing, augmented with the 
   following rules: 
    
      1) The Egress Edge does NOT perform the RSVP-TTL vs IP TTL-check 
         and does NOT update the ADspec Break bit. This is because the 
         whole CL-region is effectively handled by RSVP as a virtual 
         "link" on which Integrated Service is indeed supported (and 
         admission control performed) so that the Break bit MUST not be 
         set.  
       
      2) The Egress Edge MAY check, at the time of initial Path 
         processing, whether it has a valid value for the corresponding 
         Congestion-Level-Estimate and if not it MAY send a PathErr 
         message to the Ingress Edge with a new "CL-PCN Probes 
         Required" Error Code. This minimizes call set up time as it 
         allows probes to be generated by the Ingress Edge and measured 
         by the Egress Edge while the Path is traveling towards the 
         receiver and while the Resv travels back from the receiver. 
 
 
   Then the Egress Edge forwards the Path message towards the receiver. 
    
   [Editor Note: discussion on Adspec update to be added] 
    
   When the Resv message is received by the Egress Edge (from the 
   downstream side), the Egress Edge performs regular RSVP processing 
   (including performing admission control for the segment downstream of 
   the Egress Edge) augmented with the procedures described in this 
   section.  
    
   The Egress Edge MUST include the new CL-PCN object in the Resv 
   message transmitted to the RSVP PHOP (which is the Ingress Edge). The 
   CL-PCN object MUST convey the current Pre-Congestion Notification 
   Congestion-Level-Estimate as measured by the Egress Edge from the 
   corresponding Ingress Edge to itself. Details for computing the 
   Congestion-Level-estimate can be found in [CL-DEPLOY] and [PCN-
   MARKING]. 
    
   If the Egress Edge does not have a current value for the Congestion-
   Level-estimate for the corresponding Ingress Edge (because there was 
   no traffic received by the Egress Edge from that Ingress Edge) and it 
   has not already requested the Ingress Edge to generate CL-PCN probes, 
   the Egress Edge: 
    
      1) triggers a timer and puts the Resv message processing on hold 
 
 
Le Faucheur, et al.                                           [Page 5] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
       
      2) sends a PathErr message towards the Ingress Edge with the new 
         Error Code of "CL-PCN Probes Required" specified in this 
         document, in order to instruct the Ingress Edge to generate 
         the necessary probe traffic to enable the Egress Edge to 
         compute the Congestion-Level-Estimate from that Ingress Edge 
       
      3) When timer expires the Resv processing resumes. Assuming the 
         Congestion-Level-Estimate is now available, the Egress Edge 
         can include it in the CL-PCN object and complete Resv 
         processing. If the Congestion-Level-Estimate is still 
         available, the Egress Edge may loop again a few times through 
         step 1) and 2). After a given number of times, the Egress Edge 
         MUST send a ResvErr towards the receiver with existing 
         ErrorCode "Admission Control Failure" 
    
   [Editor note: approach in previous paragraph may be revisited to try 
   avoid having to "put Resv message processing on hold".] 
    
   The Egress Edge will then forward the Resv message to the PHOP 
   signaled earlier in the Path message and which identifies the Ingress 
   Edge. Since the Resv message is directly addressed to the Ingress 
   Edge and does not carry the Router Alert option (as per regular RSVP 
   Resv procedures), the Resv message is hidden from the Interior nodes 
   which handle the E2E Resv message as a regular IP packet. 
    
   When receiving the Resv message, the Ingress Edge processes the Resv 
   message as per regular RSVP with the following exceptions: 
    
      1) if the CL-PCN object is absent from the Resv message, this 
         means that the RSVP Next Hop is not CL-PCN capable and hence 
         proper admission control can not be achieved for that 
         reservation over the PCN cloud. Thus, the Ingress Edge MUST 
         send a ResvErr message towards the receiver with an new Error 
         Code "Inconsistent Admission Control Behaviour across Ingress 
         and Egress Edge" and an Error Value of "Egress Edge Router not 
         CL-PCN capable". The Ingress Edge MAY also generate an alarm 
         to the network operator. 
         Note that in the case where the RSVP Next Hop is not CL-PCN 
         capable, this RSVP hop would have (most probably) performed 
         the RSVP-TTL vs IP-TTL check when processing the initial Path 
         message and as a result would have set the Break bit in the 
         Adspec (assuming there is at least one Interior node on the 
         path from the Ingress Edge to the RSVP Next Hop). Thus, the 
         sender would already have been notified in the first place 
         that the QoS could not be guaranteed end-to-end. 
       
      2) The Ingress Edge MUST carry out the admission control decision 
         (for admission of the reservation over the path from Ingress 
 
 
Le Faucheur, et al.                                           [Page 6] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
         Edge to Egress Edge through the PCN cloud) taking into account 
         the congestion information provided in the CL-PCN object of 
         the Resv message in accordance with the procedures of [CL-
         DEPLOY] and [PCN-MARKING]. For example, if the Congestion 
         Level Estimate conveyed in the CL-PCN object exceeds a 
         configured threshold, the Ingress Edge may decide to reject 
         this new reservation. Once the admission control decision is 
         taken by the Ingress Edge, regular RSVP procedures are 
         followed to either proceed with the reservation (and forward 
         the Resv towards the sender) or tear down the reservation (and, 
         in particular, send a ResvErr towards the receiver with 
         existing Error Code "Admission Control failure". 
       
      3) In case the Ingress Edge forwards the Resv message upstream, 
         the Ingress Edge MUST remove the CL-PCN object  
    
   When generating a refresh for a Resv message towards the Ingress Edge, 
   the Egress Edge SHOULD NOT include the current value of the 
   Congestion-Level-Estimate in the CL-PCN object, but rather SHOULD 
   include the value which was included in the previous refresh. This is 
   for implementation reasons, to facilitate detection by the Ingress 
   Edge that this message is a mere refresh even if the value of the 
   actual Congestion-Level-Estimate has changed since the previous 
   refresh.  
    
   When receiving a PathErr message with the new Error Code of "CL-PCN 
   Probes Required", the Ingress Edge MUST generate CL-PCN probes as 
   described in [CL-DEPLOY] towards the Egress Edge which sent the 
   PathErr Message, and MUST not propagate the PathErr message further 
   upstream. 
    
    
   [Editor Note: discuss RSVP Authentication between ingress and egress 
   edges] 
    
 
3.3.  Removal of E2E reservations  
    
   E2E reservations are removed in the usual RSVP way via PathTear, 
   ResvTear, timeout, or as the result of an error condition. This does 
   not directly affect CL-PCN operations. 
    
    
3.4.  Overview of Procedures for Preemption of Existing Reservations 
    
   As mentioned earlier, [CL-DEPLOY] describes how rate-based pre-
   emption can be used to maintain the CL service to as many admitted 
   microflows as possible, even after localised failure and routing 
   changes in the interior of the edge-to-edge region. The solution 
 
 
Le Faucheur, et al.                                           [Page 7] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   involves the egress edge alerting the ingress edge of the CL-region-
   aggregate that preemption may be needed and conveying to the ingress 
   edge the measured Sustainable-Aggregate-Rate. [CL-DEPLOY] also 
   identifies that this information needs to be transferred reliably. 
   This section describes the corresponding RSVP extensions.  
    
   Section 3.2.1 "Alerting the Ingress Edge that pre-emption may be  
    
   Let us assume that a number of reservations are established and 
   transit through a given Ingress Edge Ei and a given Egress Edge Ee. 
   Let us now assume that Ee is alerted that preemption may be needed 
   and that Ee has measured the Sustainable-Aggregate-Rate for the CL-
   region-aggregate from Ei to Ee. 
    
   Then, Ee MUST arbitrarily select one of the reservations whose 
   Previous Hop is Ei and address to Ei a Resv message for that 
   reservation with a CL-PCN object containing the current Sustainable-
   Aggregate-Rate for the relevant CL-region-aggregate. 
    
   To avoid the risk that this Resv message gets lost and in turn that 
   the Ingress Edge is not made aware in a timely manner that preemption 
   may be needed, the RSVP reliable messaging procedures specified in 
   [RSVP-REFRESH] SHOULD be used. 
    
   Note that, even when reliable messaging is used, there is a very 
   small risk that the alert that preemption may be needed does not make 
   it to the Ingress Edge. For example, this could happen because there 
   could be a race condition whereby the corresponding RSVP reservation 
   may get torn down around the same time where the Resv message with 
   the CL-PCN object is transmitted, resulting in the Ingress Edge 
   ignoring the whole Resv message. However, the probability for this to 
   occur is low and could also be mitigated by the Egress Edge sending 
   the alert on more than one reservation.  
    
   [Editor Note: optional use of a Notify message will be investigated.  
   Can this solve the race condition problem mentioned above?] 
    
   On receipt of the Resv message Ei will detect that this message is 
   not just a refresh because the content of the CL-PCN object has 
   changed and will immediately trigger its preemption logic. This will 
   assess whether some reservations need to be dropped in accordance 
   with the [CL-DEPLOY] and [PCN-MARKING] scheme. In case some do, those 
   will be torn down as per regular RSVP procedures (in particular a 
   ResvErr message is then sent to the receiver).  
 
    
4.  RSVP Object and Error Code Definition 
    
   This document defines a new object and two new error codes. 
 
 
Le Faucheur, et al.                                           [Page 8] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
    
4.1.  CL-PCN Object 
    
   o      Class = To be allocated by IANA 
          C-Type = 1 
    
       0           7 8          15 16            25 26       31 
      +-------------+-------------+-------------+-------------+ 
      |                Congestion-Level-Estimate              | 
      +-------------+-------------+-------------+-------------+ 
      |                 Sustainable-Aggregate-Rate                | 
      +-------------+-------------+-------------+-------------+ 
    
    
   The CL-PCN Object may only be used in Resv messages. 
    
   Let us refer: 
      - to the Egress Edge which generated the Resv message containing 
        the CL-PCN object as Ee 
      - to the RSVP Previous HOP (Ingres Edge) for the corresponding 
        reservation as Ei. 
    
   CL-PCN Congestion-Level-Estimate: 
   This contains the value of the Congestion-Level-Estimate (defined in 
   [CL-DEPLOY] and [PCN-MARKING]) computed by Ee for the CL-region-
   aggregate from Ei to Ee. When generating a refresh for a Resv message 
   towards the Ingress Edge, the Egress Edge SHOULD NOT include the 
   current value of the Congestion-Level-Estimate in the CL-PCN object, 
   but rather SHOULD include the value which was included in the 
   previous refresh.   
   [Editor Note: Encoding details to be added] 
    
   Sustainable-Aggregate-Rate: 
   This contains: 
      - When Ee is not alerted that preemption is needed for the CL-
        region-aggregate from Ei to Ee, this field is set to 0,  
      - When Ee is alerted that preemption is (or may be) needed for 
        the CL-region-aggregate from Ei to Ee, the Sustainable-
        Aggregate-Rate  for the relevant CL-region-aggregate (defined 
        in [CL-DEPLOY] and [PCN-MARKING]) computed by Ee for this CL-
        region-aggregate. 
   [Editor Note: Encoding details to be added] 
    
    
4.2.  "CL-PCN Probes Required" Error Code 
    
   The "CL-PCN Probes Required" Error Code may appear only in PathErr 
   messages. 
    
 
 
Le Faucheur, et al.                                           [Page 9] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   Error Code = To be allocated by IANA 
    
    
4.3.  "Inconsistent Admission Control Behaviour across Ingress and 
    Egress Edge" Error Code 
    
   The "Inconsistent Admission Control Behaviour across Ingress and 
   Egress Edge" may appear only in ResvErr messages. 
   [Editor note: should we allow it in PathErr messages too so that 
   notification can also be provided to the sender?] 
    
   Error Code for "Inconsistent Admission Control Behaviour across 
   Ingress and Egress Edge"= To be allocated by IANA 
    
   Error Value for "Egress Edge Router not CL-PCN capable"= To be 
   allocated by IANA 
    
    
5.  Security Considerations 
    
   To be added 
    
    
6.  IANA Considerations  
    
   This document makes the following requests to the IANA: 
      - allocate a new Object Class (CL-PCN Object) 
      - allocate a new Error Code ("CL-PCN Probes Required") and manage 
   the corresponding Error Value range 
      - allocate a new Error Code ("Inconsistent Admission Control 
   Behaviour across Ingress and Egress Edge"), manage the corresponding 
   Error Value range, and allocate the "Egress Edge Router not CL-PCN 
   capable" under that range. 
    
    
7.  Acknowledgments 
    
   We would like to thank Carol Iturralde for her input into this 
   document. 
    
    
8.  Normative References 
    
   [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 
   (RSVP)- Functional Specification", RFC 2205, September 1997. 
    
   [CL-DEPLOY] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A.   
   Charny, S. Dudley, J. Babiarz, K. Chan, G. Karagiannis, A. Bader., L 
   Westberg. "A Deployment Model for Admission Control over DiffServ 
 
 
Le Faucheur, et al.                                          [Page 10] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   using Pre-Congestion Notification, draft-briscoe-tsvwg-cl-
   architecture-03.txt", (work in progress), June 2006 
    
   [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 
   Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 
   Framework for Integrated Services Operation Over DiffServ Networks", 
   RFC 2998, November 2000. 
    
   [PCN-MARKING] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A.   
   Charny, S. Dudley, J. Babiarz, K. Chan, G. Karagiannis, A. Bader., L 
   Westberg. "Pre-Congestion Notification marking" 
   draft-briscoe-tsvwg-cl-phb-02.txt (work in progress), June 2006. 
    
   [RSVP-REFRESH] Burger et al, "RSVP Refresh Overhead Reduction 
   Extensions", RFC2961, April 2001 
    
   [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 
   Element Service, September 1997 
    
   [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 
   Service, September 1997 
    
    
9.  Informative References 
    
   [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 
   Element Service, September 1997 
    
   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 
   W. Weiss, "A framework for Differentiated Services", RFC 2475, 
   December 1998. 
 
    
10.  Authors' Address 
    
   Francois Le Faucheur 
   Cisco Systems, Inc. 
   Village d'Entreprise Green Side - Batiment T3 
   400, Avenue de Roumanille 
   06410 Biot Sophia-Antipolis 
   France 
   Email: flefauch@cisco.com 
    
   Anna Charny 
   Cisco Systems 
   300 Apollo Drive 
   Chelmsford, MA 01824 
   USA 
   EMail: acharny@cisco.com 
 
 
Le Faucheur, et al.                                          [Page 11] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
    
   Bob Briscoe 
   BT Research 
   B54/77, Sirius House 
   Adastral Park 
   Martlesham Heath 
   Ipswich, Suffolk 
   IP5 3RE 
   United Kingdom 
   Email: bob.briscoe@bt.com 
    
   Philip Eardley 
   BT Research 
   B54/77, Sirius House 
   Adastral Park 
   Martlesham Heath 
   Ipswich, Suffolk 
   IP5 3RE 
   United Kingdom 
   Email: philip.eardley@bt.com 
    
   Kwok Ho Chan 
   Nortel Networks 
   600 Technology Park Drive 
   Billerica, MA  01821 
   USA 
   Email: khchan@nortel.com 
    
   Jozef Z. Babiarz 
   Nortel Networks 
   3500 Carling Avenue 
   Ottawa, Ont  K2H 8E9 
   Canada 
   Email: babiarz@nortel.com 
 
       
IPR Statements 
                                                       
   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 
 
 
Le Faucheur, et al.                                          [Page 12] 

                   RSVP Extensions for PCN-based CL          June 2006 
 
 
   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.  
    
          
Disclaimer of Validity 
                                             
   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.   
    
         
Copyright Notice                                                
      
   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.  
    
    
 
Appendix A - Example RSVP Signaling Flow for Admission Control 
    
   To be added. Shows RSVP message flow in case of admission control of 
   new reservations. 
    
    
Appendix B - Example Signaling Flow for Preemption 
    
   To be added. Shows RSVP message flow in case of preemption of 
   existing reservations. 
    







 
 
Le Faucheur, et al.                                          [Page 13]