Internet Engineering Task Force G. Karagiannis Internet-Draft University of Twente Intended status: Standards Track July 04, 2011 Expires: January 04, 2012 Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains draft-karagiannis-pcn-tsvwg-rsvp-pcn-00 Abstract This document specifies the extensions to the Aggregated RSVP [RFC3175] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 04, 2012. Karagiannis, et al. Expires January 04, 2012 [Page 1] Internet-Draft Aggregated RSVP over PCN July 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Overview of RSVP extensions and Operations . . . . . . . . . . . . . 2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . . . 2.1.1 PCN Marking and encoding and transport of pre-congestion Information . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Traffic Classification Within The Aggregation Region . . . . . . 2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . 2.1.8. Inter-domain Routes 2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . . 2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . 2.1.12. Message Integrity and Node Authentication . . . . . . . . . . 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating router) . . . . . . . . . . . . . . . . . . . . . . . 3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . . . 3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating router) . . . . . . . . . . . . . . . . . . . . . . 3.4. Initiation of new Aggregate Path Message By PCN-ingress node (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . . . 3.5. Handling Of new Aggregate Path Message By Interior Routers . . . . 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . . . 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . . . 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router . Karagiannis, et al. Expires January 04, 2012 [Page 2] Internet-Draft Aggregated RSVP over PCN July 2011 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . . . 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . . 3.11. Handling of Aggregated Resv Message by Aggregating Router . . . . 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . . 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . . 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . . . 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . . . 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Normative References . . . . . . . . . . . . . . . . . . . . . . . . 9. Informative References . . . . . . . . . . . . . . . . . . . . . . . 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction Two main Quality of Service (QoS) architectures have been specified by the IETF. These are the Integrated Services (Intserv) [RFC1633] architecture and the Differentiated Services (DiffServ) architecture ([RFC2475]). Intserv provides methods for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. One of the QoS signaling protocols used by the Intserv architecture is the Resource reServation Protocol (RSVP) [RFC2205], which can be used by applications to request per-flow resources from the network. These RSVP requests can be admitted or rejected by the network. Applications can express their quantifiable resource requirements using Intserv parameters as defined in [RFC2211] and [RFC2212]. The Controlled Load (CL) service [RFC2211] is a quality of service (QoS) closely approximating the QoS that the same flow would receive from a lightly loaded network element. The CL service is useful for inelastic flows such as those used for real-time media. The DiffServ architecture can support the differentiated treatment of packets in very large scale environments. While Intserv and RSVP classify packets per-flow, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability, since the need for per-flow state and per-flow processing, is eliminated. Karagiannis, et al. Expires January 04, 2012 [Page 3] Internet-Draft Aggregated RSVP over PCN July 2011 However, DiffServ does not include any mechanism for communication between applications and the network. Several solutions have been specified to solve this issue, see e.g., [RFC2998]. One of these solutions is Intserv over Diffserv [RFC2998] including resource-based admission control, policy-based admission control, assistance in traffic identification/classification, and traffic conditioning. Intserv over Diffserv can operate over a statically provisioned Diffserv region or RSVP aware. When it is RSVP aware, several Mechanisms may be used to support dynamic provisioning and topology- Aware admission control, including aggregate RSVP reservations, per- flow RSVP, or a bandwidth broker. RFC 3175 [RFC3175] specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. The main objective of Pre-Congestion Notification (PCN) is to support the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. Two mechanisms are used: admission control and flow termination. Admission control is used to decide whether to admit or block a new flow request while flow termination is used in abnormal circumstances to decide whether to terminate some of the existing flows. To support these two features, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link thus providing notification to boundary nodes about overloads before any congestion occurs (hence "pre- congestion" notification). The PCN-egress-nodes measure the rates of differently marked PCN-traffic in periodic intervals and report these rates to the decision points for admission control and flow termination, based on which they take their decisions. The decision points may be collocated with the PCN-ingress-nodes or their function may be implemented in a centralized node. For more details see[RFC5559], [draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. In this document it is Considered that the decision point is collocated with the PCN- ingress-node. This document follows the PCN signaling requirements defined in [draft-ietf-pcn-signaling-requirements-06.txt] and specifies the extensions to RSVP for support of PCN edge behaviours as specified in draft service over a Diffserv cloud using Pre-Congestion Notification as defined in [draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. Moreover, this document specifies how RSVP aggregation can be used to setup and maintain: (1) Ingress Egress Aggregate (IEA) states at Ingress and Egress nodes and (2) aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion and Pre-Congestion Notification) domains. Karagiannis, et al. Expires January 04, 2012 [Page 4] Internet-Draft Aggregated RSVP over PCN July 2011 In this document it is considered that the PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559], [RFC5696],[draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm- edge-behaviour-06]. Furthermore, the PCN-boundary-nodes MUST support the RSVP aggregated reservation procedures specified in [RFC3175], which are augmented with procedures specified in this document. 1.1. Terminology This document uses terms defined in [RFC3175], [RFC5559], [RFC5670], [draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. For readability, a number of definitions from [RFC3175] as well as definitions for terms used in [RFC5559], [draft-ietf-pcn-cl-edge-behaviour-09], and [draft-ietf-pcn-sm-edge-behaviour-06] are provided here, where some of them are augmented with new meanings: Aggregator This is the process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC3175]. In this document, it is also the PCN-ingress-node and the decision point. Deaggregator This is the process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC3175]. In this document, it is also the PCN-egress-node. E2E End to end E2E Reservation This is an RSVP reservation such that: (i) corresponding RSVP Path messages are initiated upstream of the Aggregator and terminated downstream of the Deaggregator, and (ii) corresponding RSVP Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and (iii) this RSVP reservation is aggregated over an Ingress Egress Aggregate (IEA) between the Karagiannis, et al. Expires January 04, 2012 [Page 5] Internet-Draft Aggregated RSVP over PCN July 2011 Aggregator and Deaggregator An E2E RSVP reservation may be a per-flow reservation, which in this document is only maintained at the PCN-ingress-node and PCN-egress- node. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation, see [RFC3175]). As per regular RSVP operations, E2E RSVP reservations are unidirectional. PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking packets, influence decisions about flow admission and termination for the PCN-domain; includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes. PCN-boundary-node: a PCN-node that connects one PCN-domain to a node either in another PCN-domain or in a non-PCN-domain. PCN-interior-node: a node in a PCN-domain that is not a PCN- boundary-node. PCN-node: a PCN-boundary-node or a PCN-interior-node. PCN-egress-node: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain. PCN-ingress-node: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain. In this document the PCN-ingress-node operates also as a Decision Point and aggregator. PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of different Diffserv behaviour aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv codepoint (DSCP) and ECN fields. PCN-flow: the unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single microflow (as defined in [RFC2474]) or some identifiable collection of microflows. Karagiannis, et al. Expires January 04, 2012 [Page 6] Internet-Draft Aggregated RSVP over PCN July 2011 Ingress-egress-aggregate (IEA): The collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes. PCN aggregated session: similar to the RSVP aggregation session, which is identified by using the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN-boundary-nodes used by a ingress-egress- aggregate. PCN aggregated state: is an RSVP based aggregation state, which is identified by the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN-boundary-nodes used by a ingress-egress-aggregate. In this document the PCN aggregated state coincides with the IEA. PCN-admission-state The state ("admit" or "block") derived by the Decision Point (PCN-ingress-node) for a given ingress-egress-aggregate based on PCN packet marking statistics. The Decision Point decides to admit or block new flows offered to the aggregate based on the current value of the PCN-admission-state. Congestion level estimate (CLE) The ratio of PCN-marked to total PCN-traffic (measured in octets) received for a given ingress- egress-aggregate during a given measurement period. The CLE is used to derive the PCN-admission-state and is also used by the report suppression procedure if report suppression is activated. T-meas A configurable time interval that defines the measurement period over which the PCN-egress-node collects statistics relating to PCN-traffic marking. At the end of the interval the PCN-egress-node calculates the values NM-rate, ThM-rate, and ETM-rate as defined and sends a report to the Decision Point, subject to the operation of the Report suppression feature. Karagiannis, et al. Expires January 04, 2012 [Page 7] Internet-Draft Aggregated RSVP over PCN July 2011 T-maxsuppress A configurable time interval after which the PCN- egress-node MUST send a report to the Decision Point for a given ingress-egress-aggregate regardless of the most recent values of the CLE. This mechanism provides the Decision Point with a Periodic confirmation of liveness when report suppression is activated. T-fail A configurable interval after which the Decision Point Concludes that communication from a given PCN- egress-node has failed if it has received no reports from the PCN-egress-node during that interval. t-recvFail An ingress-egress-aggregate timer that is used at The Decision point (in this document at the PCN- ingress-node) which when expires raises an alarm to management, and activates the PCN-ingress-node to block the admission of new PCN-flows. This timer expires when it value is equal to T-fail and is reset when a report, i.e., RSVP aggregated RESV message, is received for the ingress-egress- aggregate. 2. Overview of RSVP extensions and Operations 2.1 Overview of RSVP Aggregation Procedures in PCN domains The PCN-boundary-nodes can support PCN aggregated sessions, which are depending on ingress-egress-aggregates. In particular, a PCN aggregated session matches to only one ingress-egress-aggregate. The same holds for an ingress-egress-aggregate, where an ingress-egress- aggregate matches to only one PCN aggregated session. Therefore, a PCN aggregate session and its associated state is identified by using the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN-boundary-nodes used by a ingress-egress-aggregate. In this document it is considered that a PCN aggregated session and its associated state coincides with an RSVP aggregated session and its associated state [RFC3175]. In addition, in this document it is considered that the PCN-boundary nodes are able to distinguish and process (1) RSVP aggregated sessions and messages according to [RFC3175], (2) e2e RSVP sessions and messages according to [RFC2205]. Karagiannis, et al. Expires January 04, 2012 [Page 8] Internet-Draft Aggregated RSVP over PCN July 2011 Furthermore, it is considered that the PCN-interior-nodes are not able to distinguish neither PCN aggregated sessions nor RSVP aggregated sessions and their associated messages [RFC3175], nor e2e RSVP sessions and their associated messages [RFC2205]. Moreover, each PCN-boundary-node (aggregator and deaggregator) MUST support policies to initiate and maintain for each combination of the PCN-boundary-node and all other PCN-boundary-nodes of the same PCN- Domain one unique ingress-egress-aggregate (i.e., PCN aggregated state). Additionally, the PCN aggregated state maintains the mapping and association between the PCN aggregated session and the PCN-flows (e2e RSVP reservation session) that travel in one direction between the specific pair of PCN-boundary-nodes specified by the ingress-egress- aggregate. 2.1.1 PCN Marking and encoding and transport of pre-congestion information The method of PCN marking within the PCN domain is based on [RFC5670]. In addition the method of encoding and transport of pre- congestion information is based [RFC5696]. 2.1.2. Traffic Classification Within The Aggregation Region The PCN-traffic is marked using PCN-marking and is classified using The PCN-BA (i.e., combination of the DSCP and ECN fields). The PCN-traffic belonging to an PCN aggregated session can be classified only at the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN-boundary-nodes used by a ingress-egress-aggregate. The method of classification and traffic conditioning of PCN-traffic And non-PCN traffic and PHB configuration is described in draft-ietf- pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. 2.1.3. Deaggregator (PCN-egress-node) Determination In this document it is considered that for the determination of the deaggregator, the same methods can be used as the ones described in [RFC3175]. 2.1.4. Mapping E2E Reservations Onto Aggregate Reservations In this document it is considered that for the mapping of e2e reservations onto aggregate reservations, the same methods can be used as the ones described in [RFC3175], augmented by the following rules: Karagiannis, et al. Expires January 04, 2012 [Page 9] Internet-Draft Aggregated RSVP over PCN July 2011 o) PCN-ingress-node MUST use one or more policies to estimate whether a e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN-ingress-node can be mapped onto an existing RSVP aggregation reservation state (i.e., PCN aggregation state). 2.1.5. Size of Aggregate Reservations In this document it is considered that for the determination of the size of the aggregate reservations, the same methods can be used as the ones described in [RFC3175]. 2.1.6. E2E Path ADSPEC update In this document it is considered that for the update of the e2e Path ADSPEC, the same methods can be used as the ones described in [RFC3175]. 2.1.7. Intra-domain Routes The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP aggregation states and reservations (nor PCN aggregated states and reservations). Therefore, intra-domain route changes will not affect intra-domain reservations since such reservations are not maintained by the PCN-interior-nodes. 2.1.8. Inter-domain Routes In this document it is considered that for the solving the issues caused by the inter-domain route changes, the same methods can be used as the ones described in [RFC3175]. 2.1.9. Reservations for Multicast Sessions PCN does not consider reservations for multicast sessions. 2.1.10. Multi-level Aggregation PCN does not consider multi-level aggregations within the PCN domain. 2.1.11. Reliability Issues In this document it is considered that for solving possible reliability issues, the same methods can be used as the ones described in [RFC3175]. 2.1.12. Message Integrity and Node Authentication In this document it is considered that for message integrity and node authentication, the same methods can be used as the ones described in [RFC3175] and [RFC5559]. Karagiannis, et al. Expires January 04, 2012 [Page 10] Internet-Draft Aggregated RSVP over PCN July 2011 3. Elements of Procedure This section describes the procedures used to implement the RSVP procedure over PCN. 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating router) When the e2e RSVP message arrives at the exterior interface of the aggregator, i.e., PCN-ingress-node, then standard RSVP aggregation [RFC3175] procedures are used, augmented with the following rules: o) The e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN- ingress-node is mapped onto an existing RSVP aggregation reservation state (i.e., PCN aggregation state). o) If the timer t-recvFail expires for a given PCN-egress-node, the Decision Point (i.e., PCN-ingress-node) SHOULD NOT allow the e2e RSVP flow to be admitted to that aggregate. This procedure is defined in detail in: [draft-ietf-pcn-cl-edge-behaviour-09], and [draft-ietf-pcn-sm-edge-behaviour-06]. This SHOULD be considered as an error and the PCN-ingress-node SHOULD generate an e2e PathErr message using standard e2e RSVP procedures [RFC2205]. This e2e PathErr message is sent to the originating sender of the e2e Path message. o) If the timer t-recvFail does NOT expire for a given PCN-egress- node, then: *) If the PCN-admission state for the PCN aggregation state associated with the received e2e Path is "admit", the Decision Point (i.e., PCN-ingress-node) SHOULD allow new flows to be admitted to that aggregate. The e2e Path message is then forwarded towards destination. *) If the PCN-admission-state for the same PCN aggregation state is "block", the Decision Point (i.e., PCN-ingress- node) SHOULD NOT allow the e2e RSVP flow to be admitted to that aggregate. This SHOULD be considered as an error and the PCN-ingress-node SHOULD generate an e2e PathErr message using standard e2e RSVP procedures RFC2205]. This e2e PathErr message is sent to the originating sender of the e2e Path message. A new error code "PCN-domain rejects e2e reservation" MUST be augmented to the RSVP error codes to inform the sender that a PCN domains rejects the e2e reservation request. The way of how the PCN-admission-state is maintained is specified in [draft-ietf-pcn-cl-edge-behaviour-09] and [draft-ietf-pcn-sm-edge-behaviour-06]. Karagiannis, et al. Expires January 04, 2012 [Page 11] Internet-Draft Aggregated RSVP over PCN July 2011 3.2. Handling Of E2E Path Message By Interior Routers The e2e Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the e2e Path message on an interior interface and forward it on another interior interface. The e2e Path messages are simply forwarded as normal IP datagrams. 3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating router) When receiving the e2e Path message the PCN-egress-node (deaggregating router) performs main regular [RFC3175] procedures, augmented with the following rules, see also [draft-lefaucheur-rsvp- ecn-01]: o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- check and MUST NOT update the ADspec Break bit. This is because the whole PCN-domain is effectively handled by e2e 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. The PCN-egress-nodes forwards the e2e Path message towards the receiver. 3.4. Initiation of new Aggregate Path Message By PCN-ingress node (Aggregating Router) In this document it is considered that for the initiation of the new RSVP aggregated Path message by the PCN-ingress-node (Aggregation Router), the same methods can be used as the ones described in [RFC3175]. 3.5. Handling Of new Aggregate Path Message By Interior Routers The Aggregate Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the e2e Path message on an interior interface and forward it on another interior interface. The Aggregated Path messages are simply forwarded as normal IP datagrams. 3.6. Handling of E2E Resv Message by Deaggregating Router When the e2e Resv message arrives at the exterior interface of the Deaggregating router, i.e., PCN-egress-node, then standard RSVP aggregation [RFC3175] procedures are used. 3.7. Handling Of E2E Resv Message By Interior Routers The e2e Resv messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the e2e Resv message on an interior interface and forward it on another interior interface. The e2e Resv messages are simply forwarded as normal IP datagrams. Karagiannis, et al. Expires January 04, 2012 [Page 12] Internet-Draft Aggregated RSVP over PCN July 2011 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router In this document it is considered that for the initiation of the new RSVP aggregated Resv message by the PCN-ingress-node (Aggregation Router), the same methods can be used as the ones described in [RFC3175] augmented with the following rules: o) At the end of each t-meas measurement interval, or less frequently if "optional report suppression" is activated, see [draft-ietf-pcn-cl-edge-behaviour-09], and [draft-ietf-pcn-sm-edge-behaviour-06], the PCN-egress-node MUST include the new PCN object that will be sent to the associated Decision Point (i.e., PCN-ingress-node). The PCN object is specified in this document and is used to report of the data measured by the PCN-egress-node, for a particular ingress-egress-aggregate, see [draft-ietf-pcn-cl- edge-behaviour-09], and [draft-ietf-pcn-sm-edge-behaviour-06]. The address of the PCN-ingress-node is the one specified in the same ingress-egress-aggregate. 3.9. Handling of Aggregate Resv Message by Interior Routers The Aggregated Resv messages traverse zero or more PCN-interior- nodes. The PCN-interior-nodes receive the Aggregated Resv message on an interior interface and forward it on another interior interface. The Aggregated Resv messages are simply forwarded as normal IP datagrams. 3.10. Handling of E2E Resv Message by Aggregating Router When the e2e Resv message arrives at the interior interface of the Aggregating router, i.e., PCN-ingress-node, then standard RSVP aggregation [RFC3175] procedures are used. 3.11. Handling of Aggregated Resv Message by Aggregating Router When the Aggregated Resv message arrives at the interior interface of the Aggregating router, i.e., PCN-ingress-node, then standard RSVP aggregation [RFC3175] procedures are used, augmented with the following rules: o) the Decision Point (i.e., the PCN-ingress-node) SHOULD use the information carried by the PCN object as specified in [draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. 3.12. Removal of E2E Reservation In this document it is considered that for the removal of e2e reservations, the same methods can be used as the ones described in [RFC3175]. Karagiannis, et al. Expires January 04, 2012 [Page 13] Internet-Draft Aggregated RSVP over PCN July 2011 3.13. Removal of Aggregate Reservation In this document it is considered that for the removal of aggregated reservations, the same methods can be used as the ones described in [RFC3175]. 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router The handling of data on the reserved e2e Flow by Aggregating Router is using the procedures described in [RFC3175] augmented with: o) Regarding, PCN marking and traffic classification the procedures defined in Section 2.1.1 and 2.1.3 of this document are used. 3.15. Procedures for Multicast Sessions In this document no multicast sessions are considered. 4. Protocol Elements The protocol elements in this document are using the protocol Elements defined in [RFC3175], augmented with the following rules: o) A PCN-egress-node (i.e., deaggregator) SHOULD send periodically and at the end of each t-meas measurement interval, or less frequently if "optional report suppression" is activated, an (refresh) aggregated RSVP message to the PCN-ingress-node (i.e. aggregator). o) the DSCP value included in the SESSION object, SHOULD be set equal to a PCN-compatible Diffserv codepoint. o) An aggregated Resv message MUST carry a PCN object to report the data measured by an PCN-egress-node (i.e., Deaggregator). 4.1 PCN object The PCN object reports data measured by an PCN-egress-node. PCN objects are defined for different PCN edge behavior drafts. This document defines several types of PCN objects. o) Single Marking (SM) PCN object, when IPv4 addresses are used: Class = PCN C-Type = RSVP-AGGREGATE-IPv4-PCN-SM Karagiannis, et al. Expires January 04, 2012 [Page 14] Internet-Draft Aggregated RSVP over PCN July 2011 +-------------+-------------+-------------+-------------+ | IPv4 PCN-ingress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | IPv4 PCN-egress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Congestion-Level-Estimate | +-------------+-------------+-------------+-------------+ | rate of not marked PCN-traffic (NM-rate) | +-------------+-------------+-------------+-------------+ | rate of PCN-marked PCN-traffic (PM-rate) | +-------------+-------------+-------------+-------------+ o) Single Marking (SM) PCN object, when IPv6 addresses are used: Class = PCN C-Type = RSVP-AGGREGATE-IPv6-PCN-SM +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 PCN-ingress-node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 PCN-egress-node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Congestion-Level-Estimate | +-------------+-------------+-------------+-------------+ | rate of not marked PCN-traffic (NM-rate) | +-------------+-------------+-------------+-------------+ | rate of PCN-marked PCN-traffic (PM-rate) | +-------------+-------------+-------------+-------------+ o) Controlled (CL) PCN object, IPv4 addresses are used: Class = PCN C-Type = RSVP-AGGREGATE-IPv4-PCN-CL Karagiannis, et al. Expires January 04, 2012 [Page 15] Internet-Draft Aggregated RSVP over PCN July 2011 +-------------+-------------+-------------+-------------+ | IPv4 PCN-ingress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | IPv4 PCN-egress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Congestion-Level-Estimate | +-------------+-------------+-------------+-------------+ | rate of not marked PCN-traffic (NM-rate) | +-------------+-------------+-------------+-------------+ | rate of threshold-marked PCN-traffic (ThM-rate) | +-------------+-------------+-------------+-------------+ | rate of excess-traffic-marked PCN-traffic (ETM-rate) | +-------------+-------------+-------------+-------------+ o) Controlled (CL) PCN object, IPv6 addresses are used: Class = PCN C-Type = RSVP-AGGREGATE-IPv6-PCN-CL +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 PCN-ingress-node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 PCN-egress-node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Congestion-Level-Estimate | +-------------+-------------+-------------+-------------+ | rate of not marked PCN-traffic (NM-rate) | +-------------+-------------+-------------+-------------+ | rate of threshold-marked PCN-traffic (ThM-rate) | +-------------+-------------+-------------+-------------+ | rate of excess-traffic-marked PCN-traffic (ETM-rate) | +-------------+-------------+-------------+-------------+ The fields carried by the PCN object are specified in [draft-ietf-pcn-signaling-requirements-06.txt], [draft-ietf-pcn-cl- edge-behaviour-09] and [draft-ietf-pcn-sm-edge-behaviour-06]: o the IPv4 or IPv6 address of the PCN-ingress-node and the the IPv4 or IPv6 address of the PCN-egress-node; together they specify the ingress-egress-aggregate to which the report refers; Karagiannis, et al. Expires January 04, 2012 [Page 16] Internet-Draft Aggregated RSVP over PCN July 2011 o rate of not-marked PCN-traffic (NM-rate) in octets/second; its format is a 32-bit IEEE floating point number; o rate of PCN-marked traffic (PM-rate) in octets/second; its format is a 32-bit IEEE floating point number; o congestion-level-estimate, which is a number between zero and one; its format is a 32-bit IEEE floating point number; o rate of threshold-marked PCN traffic (ThM-rate) in octets/second; its format is a 32-bit IEEE floating point number; o rate of excess-traffic-marked traffic (ETM-rate) in octets/second; its format is a 32-bit IEEE floating point number; 5. Security Considerations The same security considerations specified in [RFC3175] and [RFC5559] apply also to this document. 6. IANA Considerations This document makes the following requests to the IANA: o allocate a new Object Class (PCN Object), see Section 4.1. o allocate a "PCN-domain rejects e2e reservation" Error Code that may appear only in e2e PathErr messages, see Section 3.1. Error Value for "PCN-domain rejects e2e reservation "= To be allocated by IANA 7. Acknowledgments We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 01.txt], since some ideas used in this document are based on the work initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. 8. Normative References [draft-ietf-pcn-cl-edge-behaviour-09] T. Taylor, A, Charny, F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation (Work in progress)", June 2011. [draft-ietf-pcn-sm-edge-behaviour-06] A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation (Work in progress)", June 2011. Karagiannis, et al. Expires January 04, 2012 [Page 17] Internet-Draft Aggregated RSVP over PCN July 2011 [draft-ietf-pcn-signaling-requirements-06] G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain(Work in progress)", July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol (RSVP)- Functional Specification", RFC 2205, September 1997. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009. [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009. 9. Informative References [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN) (Work in progress)", June 2006. [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [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 [RFC2474] 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. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "A framework for Differentiated Services", RFC 2475, December 1998. [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. Karagiannis, et al. Expires January 04, 2012 [Page 18] Internet-Draft Aggregated RSVP over PCN July 2011 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009. 10. Authors' Address Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@utwente.nl Karagiannis, et al. Expires January 04, 2012 [Page 19]