NSIS A. Mayutan Internet-Draft October 16, 2006 Intended status: Informational Expires: April 19, 2007 NSIS-PCN : NSIS Extensions for Admission Control over Diffserv using Pre- congestion Notification (PCN) draft-mayutan-nsis-pcn-00.txt 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 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Mayutan Expires April 19, 2007 [Page 1] Internet-Draft NSIS-PCN October 2006 Abstract This document specifies the extensions to the NSIS QoS signalling protocol (QoS-NSLP)[QoS-NSLP] for support of the Controlled Load (CL) service over a DiffServ cloud using Pre-Congestion Notification as defined in [CL-DEPLOY]. The CL-DEPLOY is a QoS architecture similiar to RMD-QOSM measurement-based admission control. This draft is based on [RSVP-PCN] and uses some text from it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the RMD-QOSM extensions and Operations . . . . . . 6 3.1. Overall QoS Architecture . . . . . . . . . . . . . . . . . 6 3.2. Overview of Procedures for Admission Control of New Reservations . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Removal of E2E reservations . . . . . . . . . . . . . . . 8 4. CL-PCN-QSpec Object and Error Code Definition . . . . . . . . 9 4.1. CL-PCN-QSPEC Object . . . . . . . . . . . . . . . . . . . 9 4.2. CL-PCN-QSPEC Probes Required Error Code . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Mayutan Expires April 19, 2007 [Page 2] Internet-Draft NSIS-PCN October 2006 1. Introduction This document describes an extension to the QoS-NSLP and specifies a CL-DEPLOY-specific QSpec (CL-DEPLOY-QSPec) to enable it to use Pre- Congestion Notification as defined in [CL-DEPLOY] for supporting Controlled Load (CL) service. The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) [QoS- NSLP] specifies a generic model for carrying Quality of Service (QoS) signaling information end-to-end in an IP network. Each network along the end-to-end path is expected to implement a specific QoS Model (QOSM) that interprets the requests and installs the necessary mechanisms, in a manner that is appropriate to the technology in use in the network, to ensure the delivery of the requested QoS. 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. Mayutan Expires April 19, 2007 [Page 3] Internet-Draft NSIS-PCN October 2006 2. Terminology 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 [RFC2119]. The terminology defined by GIST [GIST] QoS-NSLP [QoS-NSLP], RMD-QSpec [RMD-QSpec] and [CL-DEPLOY] applies to this draft. For readability, a number of definitions from the above mentioned documents are repeated here: QNE ingress edge (or QNE ingress gateway) QNE Ingress edge is a router at an ingress to the CL- region. A CL-region may have several ingress gateways. QNE egress edge (or QNE egress gateway) QNE Egress edge is a router at an egress from the CL- region. A CL-region may have several egress gateways. Interior router Interior router is a router which is part of the CL-region, but is not an ingress or egress gateway. CL-region CL-region is 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. CL-region-aggregate CL-region-aggregate is a term used to represent 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. Congestion-Level-Estimate Congestion-Level-Estimate is a term used to represent the 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. Mayutan Expires April 19, 2007 [Page 4] Internet-Draft NSIS-PCN October 2006 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. Sustainable-Aggregate-Rate Sustainable-Aggregate-Rate is a term used to represent 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. Mayutan Expires April 19, 2007 [Page 5] Internet-Draft NSIS-PCN October 2006 3. Overview of the RMD-QOSM extensions and Operations 3.1. Overall QoS Architecture The overall QoS architecture is described in [CL-DEPLOY] and for readability and better understanding is reproduced in figure 1. This QoS architecture is similiar to a special case of the RMD-QOSM architecture where the interior nodes are non-NSIS aware. ---- ----- ----------------------------------------- ----- ----- | | | | |QNE QNE QNE | | | | | | | | | |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) | | | | | | | | | | | | | | | ---- ----- ----------------------------------------- ----- ----- QNI QNR Sx Access CL-region Access Rx End Network Network End Host Host <------ edge-to-edge signalling -----> (for admission control and 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 RMD-QOSM operations to support such a measurement-based admission control scheme relying on Pre- Mayutan Expires April 19, 2007 [Page 6] Internet-Draft NSIS-PCN October 2006 Congestion Notification in the edge-to-edge region. When a new request for QoS reservation arrives at the Ingress Edge, the Ingress Edge does regular NSIS processing and forwards it to the next QoS-NSLP aware NSIS node along the path to the destination. This next QoS-NSLP aware node happens to be the QNE-Egress node since all the interior nodes are either QoS-NSLP non-aware nodes or nodes that have the QOS-NSLP functionality disabled. When the QoS Reservation message arrives at the QNE Egress Edge, the QNE Egress Edge in addition to processing it as as per regular QoS- NSLP processing, may 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 NOTIFY message to the QNE 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 QNE Ingress Edge and measured by the QNE 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. When the QoS-NSLP Response message is received by the Egress Edge (from the downstream side), the Egress Edge performs regular QoS-NSLP 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-QSPEC object in the RESPONSE message transmitted to the QNE Ingress Edge. The CL-PCN- QSPEC 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 timer and puts the QoS-NSLP Reserve message processing on hold 2) sends a NOTIFY message towards the QNE 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 Reserve processing resumes. Assuming the Congestion-Level-Estimate is now available, the Egress Edge can Mayutan Expires April 19, 2007 [Page 7] Internet-Draft NSIS-PCN October 2006 include it in the CL-PCN-QSPEC object and complete Reservation processing. If the Congestion-Level-Estimate is still unavailable, 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 NOTIFY with QoS Model Error (0x06) towards the QNE ingress edge node with ErrorCode "Congestion-level-estimate Failure". The Egress Edge will then forward the Response message to the QNE ingress edge in the upstream path. When receiving the Response message, the QNE Ingress Edge processes the Response message as per regular QoS-NSLP with the following exceptions: 1) if the CL-PCN-QSPec object is absent from the Response message, this means that the QoS-NSLP 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 NOTIFY message towards the initiator with a 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. 2) The QNE Ingress Edge MUST carry out the admission control decision (for admission of the reservation over the path from Ingress 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. 3) In case the Ingress Edge forwards the Resv message upstream, the Ingress Edge MUST remove the CL-PCN object When receiving a NOTIFY 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 QNE Egress Edge which sent the NOTIFY Message, and MUST not propagate the NOTIFY message further upstream. 3.3. Removal of E2E reservations E2E reservations are removed in the usual QoS-NSLP way. This does not directly affect CL-PCN operations. Mayutan Expires April 19, 2007 [Page 8] Internet-Draft NSIS-PCN October 2006 4. CL-PCN-QSpec Object and Error Code Definition This document defines a new CL-PCN-QSpec object and two new error codes. 4.1. CL-PCN-QSPEC Object The QSPEC format is specified in [QSP-T] and is as follows: QSPEC = The and used by the RMD-QOSM are assigned by IANA, see Section 6. The contains the following fields: = The is not used. The CL-PCN-QSPEC Object may only be used in QoS-NSLP response messages. Let us refer: -to the QNE Egress Edge which generated the Response message containing the CL-PCN object as QNEe - to the QNE Previous HOP (Ingres Edge) for the corresponding reservation as QNEi. CL-PCN Congestion-Level-Estimate: This contains the value of the Congestion-Level-Estimate (defined in [CL-DEPLOY] and [PCN-MARKING]) computed by QNEe for the CL-region- aggregate from QNEi to QNEe. Sustainable-Aggregate-Rate: This contains: - When QNEe is not alerted that preemption is needed for the CL- region-aggregate from QNEi to QNEe, this field is set to 0, - When QNEe is alerted that preemption is (or may be) needed for the CL-region-aggregate from QNEi to QNEe, the Sustainable- Aggregate-Rate for the relevant CL-region-aggregate (defined in [CL-DEPLOY] and [PCN-MARKING]) computed by QNEe for this CL- region-aggregate. 4.2. CL-PCN-QSPEC Probes Required Error Code The "CL-PCN Probes Required" Error Code may appear only in NOTIFY messages. Error Code = To be allocated by IANA Mayutan Expires April 19, 2007 [Page 9] Internet-Draft NSIS-PCN October 2006 5. Security Considerations To be added Mayutan Expires April 19, 2007 [Page 10] Internet-Draft NSIS-PCN October 2006 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. NSIS-PCN requires a new IANA registry for CL-DEPLOY QoS Model Identifiers. It is a 32-bit value carried in a QSPEC object [QSP-T]. This document defines a new object for the QSPEC Template: CL-PCN- QSPec Object. For this, new IDs in the QSPEC Template Object Type registry should be assigned. Mayutan Expires April 19, 2007 [Page 11] Internet-Draft NSIS-PCN October 2006 7. Acknowledgements Mayutan Expires April 19, 2007 [Page 12] Internet-Draft NSIS-PCN October 2006 8. References 8.1. 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 using Pre-Congestion Notification, draft-briscoe-tsvwg-cl- architecture-03.txt", (work in progress), June 2006 [RSVP-PCN] B. Briscoe, P. Eardley,Joe Barbiaz, Kwok-Ho Chan , Francois Le Faucheur, Anna Charny, " RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN), draft-lefaucheur-rsvp-ecn-01.txt " , June 2006 [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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., 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. 8.2. Informative References [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Mayutan Expires April 19, 2007 [Page 13] Internet-Draft NSIS-PCN October 2006 Author's Address Mayutan Arumaithurai Hamburg, Germany Email: mayutan.arumaithurai@gmail.com Mayutan Expires April 19, 2007 [Page 14] Internet-Draft NSIS-PCN 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). Mayutan Expires April 19, 2007 [Page 15]