Internet Engineering Task Force                     Georgios Karagiannis
Internet-Draft                                      University of Twente
Intended status: Experimental                            Anurag Bhargava
Expires: April 21, August 14, 2014                             Cisco Systems, Inc.
                                                      October 21, 2013
                                                       February 14, 2014

        Generic Aggregation of Resource ReSerVation Protocol (RSVP)
              for IPv4 And IPv6 Reservations over PCN domains
                     draft-ietf-tsvwg-rsvp-pcn-07
                     draft-ietf-tsvwg-rsvp-pcn-08

Abstract

   This document specifies extensions to Generic Aggregated RSVP
   [RFC4860]
   RFC 4860 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 April 21, August 14, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   1.1. Objective   . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . .  4
   1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  7
   1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
2.  Overview of RSVP extensions and Operations . . . . . . . . . . .  11
2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.2. PCN Marking and encoding and transport of pre-congestion
     Information . . . . . . . . . . . . . . . . . . . . . . . . . .  13
2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 14 13
2.6  Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 15 14
2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 15 14
2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .15 .14
2.9.  Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15
2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . .  15
2.13.  Message Integrity and Node Authentication . . . . . . . . . .  16  15
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . .  16  15
3.1.  Receipt of E2E Path Message By by PCN-ingress-node
     (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 17 15
3.2.  Handling Of E2E Path Message By by Interior Routers . . . . . . .  17  16
3.3.  Receipt of E2E Path Message By by PCN-egress-node
     (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 17 16
3.4.  Initiation of new Aggregate Path Message By PCN-ingress-node
      (Aggregating Router) . . . . . . . . . . . . . . . . . . . . .  18  16
3.5.  Handling Of new Aggregate Path Message By by Interior Routers . .  18
3.6.  16
3.6   Handling Of Aggregate Path Message by Deaggregating Router . .  16
3.7.  Handling of E2E Resv Message by Deaggregating Router . . . . .  18
3.7.  17
3.8.  Handling Of E2E Resv Message By by Interior Routers . . . . . . .  18
3.8.  17
3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 19
3.9. 17
3.10.  Handling of Aggregate Resv Message by Interior Routers  . . . .  18
3.10.
3.11.  Handling of E2E Resv Message by Aggregating Router . . . . . . 19
3.11. 18
3.12.  Handling of Aggregated Resv Message by Aggregating Router . .  19
3.12.  18
3.13.  Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 20
3.13. 19
3.14.  Removal of Aggregate Reservation . . . . . . . . . . . . . . . 20
3.14. 19
3.15.  Handling of Data On Reserved E2E Flow by Aggregating Router .  20
3.15.  19
3.16.  Procedures for Multicast Sessions . . . . . . . . . . . . . .  21
3.16.  19
3.17.  Misconfiguration of PCN node  . . . . . . . . . . . . . . . .  21  19
3.18.  PCN based Flow Termination .  . . . . . . . . . . . . . . . .  19
4.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 21 20
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . .  21  20
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . . 26 23
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  26  23
7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 24
8.  Normative References . . . . . . . . . . . . . . . . . . . . . .  27  24
9.  Informative References . . . . . . . . . . . . . . . . . . . . .  27  25
10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . .  28  25
11.  Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 31 28
1.  Introduction

1.1 Objective

   Pre-Congestion Notification (PCN) can 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; the Decision Points use
   these rates to make decisions.  The Decision Points may be collocated
   with the PCN-ingress-nodes, or their function may be implemented in a
   centralized
   another node. For more details see [RFC5559], [RFC6661], and
   [RFC6662].

   The main objective of this document is to specify the signaling
   protocol that can be used within a Pre-Congestion Notification (PCN)
   domain to carry reports from a PCN-egress-node PCN-ingress-node to a PCN Decision
   point, considering that the PCN decision Decision Point and PCN-ingress-node PCN-egress-node
   are collocated.
   If the PCN decision point Decision Point is not collocated with the PCN-ingress-node PCN-egress-node
   then additional signaling procedures are required that are out of
   the scope of this document. Moreover, as mentioned above this
   architecture conforms with PBAC (Policy-Based Admission Control),
   when decision point the Decision Point is located in a centralized another node then the PCN-
   ingress-node [RFC2753].

   Several signaling protocols can be used to carry reports from a PCN-
   egress-node to a PCN-ingress-nodes. information between
   PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However,
   since (1) both PCN-egress-
   node PCN-egress-node and PCN-ingress-nodes are located on
   the data path, path and (2) the admission control procedure needs to be
   done at PCN-egress-node, a signaling protocol that follows the same
   path as the data path, like RSVP (Resource Reservation Protocol), is
   more suited for this purpose. In particular, this document specifies
   extensions to Generic Aggregated RSVP [RFC4860] for support of the
   PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over
   a Diffserv cloud using Pre-Congestion Notification.

1.2 Overview and Motivation

   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.

   However, DiffServ does not include any mechanism for communication
   between applications and the network.  Several solutions have been
   specified to solve this issue. One of these solutions is Intserv over
   Diffserv [RFC2998] including resource-based admission control (RBAC),
   PBAC, 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.  [RFC3175]
   specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-
   end reservations over aggregate RSVP reservations. In [RFC3175] the
   RSVP generic aggregated reservation is characterized by a RSVP
   SESSION object using the 3-tuple <source IP address, destination IP
   address, Diffserv Code Point>.

   Several scenarios require the use of multiple generic aggregate
   reservations that are established for a given PHB from a given source
   IP address to a given destination IP address, see [SIG-NESTED],
   [RFC4860]. For example, multiple generic aggregate reservations
   can be applied in the situation that multiple e2e E2E reservations using
   different preemption priorities need to be aggregated through a PCN-
   domain using the same PHB. By using multiple aggregate reservations
   for the same PHB allows enforcement of the different preemption
   priorities within the aggregation region. This allows more efficient
   management of the Diffserv resources, and in periods of resource
   shortage, this allows sustainment of a larger number of E2E
   reservations with higher preemption priorities. In particular,
   [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can
   be established in a nested VPN environment through RSVP aggregation.

   [RFC4860] provides generic aggregate reservations by extending
   [RFC3175] to support multiple aggregate reservations for the same
   source IP address, destination IP address, and PHB (or set of PHBs).
   In particular, multiple such generic aggregate reservations can be
   established for a given PHB from a given source IP address to a given
   destination IP address. This is achieved by adding the concept of a
   Virtual Destination Port and of an Extended Virtual Destination Port
   in the RSVP SESSION object. In addition to this, the RSVP SESSION
   object for generic aggregate reservations uses the PHB Identification
   Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
   Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify
   the PHB, or set of PHBs, from which the Diffserv resources are to be
   reserved.
   The RSVP like signaling protocol required to carry reports (1) requests from
   a PCN-egress-node to a PCN-ingress-node and (2) reports from a
   PCN-ingress-node to a PCN-egress-node needs to follow the PCN
   signaling requirements defined in [RFC6663]. In addition to
   that the signaling protocol functionality supported by the PCN-
   ingress-nodes and PCN-egress-nodes needs to maintain logical
   aggregate constructs (i.e. ingress-egress-aggregate state) and be
   able to map e2e E2E reservations to these aggregate constructs. Moreover,
   no actual reservation state is needed to be maintained inside the PCN
   domain, i.e., the PCN-interior-nodes are not maintaining any
   reservation state.

   This can be accomplished by two possible approaches:

   Approach (1):

     o) adapting the RFC 4860 aggregation procedures to fit the PCN
        requirements with as little change as possible over the RFC 4860
        functionality

     o) hence performing aggregate RSVP signaling (even if it is to be
        ignored by PCN interior nodes)

     o) using this aggregate RSVP signaling procedures to carry PCN
        information from PCN-egress-node to between the PCN-ingress-node. PCN-boundary-nodes (PCN-ingress-node and
        PCN-egress-node).

   Approach (2):

     o) adapting the RFC 4860 aggregation procedures to fit the PCN
        requirements with more significant changes over RFC4860 (i.e.
        the aspect of the procedures that have to do with maintaining
        aggregate states and to do with mapping the e2e E2E reservations to
        aggregate constructs are kept, but the procedures that have to
        do with the aggregate RSVP signaling and aggregate reservation
        establishment/maintenance are dropped).

     o) hence not performing aggregate RSVP signaling

     o) piggy-backing of the PCN information inside the e2e E2E RSVP
        signaling.

   Both approaches are probably viable, however, since the RFC 4860
   operations have been thoroughly studied and implemented, it can be
   considered that the RFC 4860 solution can better deal with the more
   challenging situations (rerouting in the PCN domain, failure of an
   PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a
   different edge, etc.). This is the reason for choosing Approach (1)
   for the specification of the signaling protocol used to carry
   PCN information from the PCN-egress-node to between the PCN-ingress-node. PCN-boundary-nodes (PCN-ingress-node and
   PCN-egress-node).

   In particular, this document specifies extensions to Generic
   Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
   and Single Marking (SM) edge behaviors over a Diffserv cloud using
   Pre-Congestion Notification.

   This document follows the PCN signaling requirements defined in
   [RFC6663] and specifies extensions to Generic Aggregated RSVP
   [RFC4860] for support of PCN edge behaviors as specified in
   [RFC6661] and [RFC6662]. 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) generic
   aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion
   and Pre-Congestion Notification) domains.

   To comply with this specification, PCN-nodes MUST be able to
   support the functionality specified in [RFC5670], [RFC5559],
   [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes
   MUST support the RSVP generic aggregated reservation procedures
   specified in [RFC4860] which are augmented with procedures specified
   in this document.

1.3.  Terminology

   This document uses terms defined in [RFC4860], [RFC3175], [RFC5559],
   [RFC5670], [RFC6661], [RFC6662].

   For readability, a number of definitions from [RFC3175] as well as
   definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] 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 [RFC4860].  In this
                    document, it is also the PCN-ingress-node and the
                    decision point. PCN-ingress-node. It is
                    important to notice that in the context of this
                    document the Aggregator MUST be able to determine
                    the Deaggregator using the procedures specified in
                    Section 4 of [RFC4860] and in Section 1.4.2 of
                    [RFC3175].

  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.

   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 [RFC4860].  In this
                    document, it is also the PCN-egress-node. PCN-egress-node and
                    Decision Point.

   E2E (or 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
                          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 [RFC4860]). As per regular RSVP
                    operations, E2E RSVP  reservations are
                    unidirectional.

   PHB-ID (Per Hop Behavior Identification Code)
                     A 16-bit field containing the Per Hop Behavior
                     Identification Code of the PHB, or of the set of
                     PHBs, from which Diffserv resources

   E2E microflow    a microflow where its associated packets are to be reserved.  This field MUST be encoded as
                     specified in Section 2 of [RFC3140].

   VDstPort (Virtual Destination Port)

                     A 16-bit identifier used in the SESSION that
                     remains constant over the life of the generic
                     aggregate reservation. being
                    forwarded on an E2E path.

   Extended vDstPort (Extended Virtual Destination Port)

                     An identifier used in the SESSION that remains
                     constant over the life of the generic aggregate
                     reservation. The length of this idenitifier identifier is 32-
                     bits when IPv4 addresses are used and 128 bits when
                     IPv6 addresses are used.

                     A sender(or Aggregator) that wishes to narrow the
                     scope of a SESSION to the sender-receiver pair (or
                     Aggregator-Deaggregator pair) SHOULD place its IPv4
                     or IPv6 address here as a network unique
                     identifier. A sender (or Aggregator) that wishes to
                     use a common session with other senders (or
                     Aggregators) in order to use a shared reservation
                     across senders (or Aggregators) MUST set this field
                     to all zeros. In this document, the Extended
                     vDstPort SHOULD contain the IPv4 or IPv6 address of
                     the Aggregator.

   ETM-rate
                     The rate of excess-traffic-marked PCN-traffic
                     received at a PCN-egress-node for a given ingress-
                     egress-aggregate in octets per second.

  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. In this document one RSVP
                    generic aggregated reservation is mapped to only
                    one ingress-egress-aggregate, while one
                    ingress-egress-aggregate is mapped to either
                    one or to more than one RSVP generic aggregated
                    reservations. PCN-flows and their PCN-traffic that
                    are mapped into a specific RSVP generic aggregated
                    reservation can also easily be mapped into their
                    corresponding ingress-egress-aggregate.

   Microflow:       a single instance of an application-to-application
 (from [RFC2474])   flow of packets which is identified by source
                    address, destination address, protocol id, and
                    source port, destination port (where applicable).

   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. In this
                    document the PCN-ingress-node PCN-egress-node operates also as a
                    deaggregator.
                    Decision Point and Deaggregator.

   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.
                    Aggregator.

   PCN-traffic,
   PCN-packets,
   PCN-BA:          a PCN-domain carries traffic of different Diffserv
                    behavior 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.

   Microflow:       a single instance of an application-to-application
 (from [RFC2474])   flow of packets which is identified by source
                    address, destination address, protocol id, and
                    source port, destination port (where applicable).

  e2e microflow     a microflow where its associated packets are being
                    forwarded on an E2E path.

   PCN-flow:        the unit of PCN-traffic that the PCN-boundary-node
                    admits (or terminates); the unit could be a single
                    e2e
                    E2E microflow (as defined in [RFC2474]) or some
                    identifiable collection of microflows.

RSVP generic aggregated reservation: an RSVP reservation

   PCN-admission-state:
                    The state ("admit" or "block") derived by the
                    Decision Point for a given ingress-egress-aggregate
                    based on statistics about PCN-packet marking.  The
                    Decision Point decides to admit or block new flows
                    offered to the aggregate based on the current value
                    of the PCN-admission-state.

   PCN-sent-rate
                     The rate of PCN-traffic received at a PCN-ingress-
                     node and destined for a given ingress-egress-
                     aggregate in octets per second.

   PHB-ID (Per Hop Behavior Identification Code)
                     A 16-bit field containing the Per Hop Behavior
                     Identification Code of the PHB, or of the set of
                     PHBs, from which Diffserv resources
                     are to be reserved.  This field MUST be encoded as
                     specified in Section 2 of [RFC3140].

   RSVP generic aggregated reservation: an RSVP reservation that is
                    identified by using the RSVP SESSION object
                    for generic RSVP aggregate aggregated reservation. This RSVP
                    SESSION object is based on the RSVP SESSION object
                    specified in [RFC4860] augmented with the following
                    information:

                    o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be
                       set to the IPv4 or IPv6 destination addresses,
                       respectively, of the Deaggregator (PCN-egress-
                       node)

                    o) PHB-ID (Per Hop Behavior Identification Code)
                       SHOULD be set equal to PCN-compatible Diffserv
                       codepoint(s).

                    o) Extended vDstPort SHOULD be set to the IPv4 or
                       IPv6 destination addresses, of the Aggregator
                       (PCN-ingress-node)

  Ingress-egress-aggregate (IEA):
                    The collection of PCN-packets from all PCN-flows
                    that travel

   VDstPort (Virtual Destination Port)

                     A 16-bit identifier used in one direction between a specific pair the SESSION that
                     remains constant over the life of PCN-boundary-nodes. An ingress-egress-aggregate
                    is identified by the combination generic
                     aggregate reservation.

1.4. Organization of (1) PCN-BA
                    (i.e.,  combination This Document

   This document is organized as follows. Section 2 gives an overview of the DSCP
   RSVP extensions and ECN fields),(2)
                    IP addresses operations. The elements of the specific pair of
                    PCN-boundary-nodes used by procedures
   are specified in Section 3. Section 4 describes the
                    ingress-egress-aggregate. In this document one protocol
   elements. The security considerations are given in section 5 and the
   IANA considerations are provided in Section 6.

2.  Overview of RSVP extensions and Operations

2.1 Overview of RSVP Aggregation Procedures in PCN domains

   The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
   generic aggregated reservation is mapped to only
                    one ingress-egress-aggregate, while reservations {RFC4860], which are depending on
   ingress-egress-aggregates. In particular, one RSVP generic aggregated
   reservation matches to only one ingress-egress-aggregate.

   However, one ingress-egress-aggregate is mapped matches to either
                    one
   one, or to more than one one, RSVP generic aggregated reservations.

   PCN-admission-state:
                    The state ("admit" or "block") derived by the
                    Decision Point for a given ingress-egress-aggregate
                    based on statistics about PCN-packet marking.  The
                    Decision Point decides to admit or block new flows
                    offered
   In addition, to comply with this specification, the aggregate based on the current value
                    of the PCN-admission-state.

   Congestion level estimate (CLE):
                    The ratio of PCN-marked PCN-boundary
   nodes need to total PCN-traffic
                    (measured in octets) received distinguish and process (1) RSVP SESSIONS for a given ingress-
                    egress-aggregate during a given measurement period.
                    The CLE is used to derive the PCN-admission-state generic
   aggregated sessions 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 their messages according to PCN-traffic marking.

  t-fail:
                   An interval after which the Decision Point (i.e.,
                   PCN-ingress-node in this document) 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:
                   A timer per ingress-egress-aggregate that the
                   Decision point (i.e., PCN-ingress-node) sets every
                   time it receives an [RFC4860], (2)
   E2E RSVP Aggregated RESV message for
                   that ingress-egress-aggregate. When its value
                   reaches t-fail sessions and messages according to [RFC2205]. Furthermore,
   it is assumed considered that by configuration the PCN-ingress-
                   node has lost contact PCN-interior-nodes do not
   intercept (nor process) RSVP messages associated with the PCN-egress-node.
                   Therefore the PCN-ingress-node blocks admission of
                   new PCN-flows into that aggregate and raises a
                   management alarm.

1.4. Organization of This Document

   This document is organized as follows. Section 2 gives an overview of generic
   aggregated reservation [RFC4860], or with end to end RSVP extensions and operations. The elements of the used procedures
   are specified in Section 3. Section 4 describes the protocol
   elements. The security considerations are given in section 5 and the
   IANA considerations are provided in Section 6.

2.  Overview of RSVP extensions and Operations

2.1 Overview of RSVP Aggregation Procedures in PCN domains

   The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
   generic aggregated
   reservations {RFC4860], which are depending on
   ingress-egress-aggregates. In particular, one RSVP generic aggregated
   reservation matches to only one ingress-egress-aggregate.

   However, one ingress-egress-aggregate matches to either
   one or more than one RSVP generic aggregated reservations.
   In addition, [RFC2205]. Moreover, each Aggregator and Deaggregator
   (i.e., PCN-boundary-nodes) need to comply with this specification it is considered that
   the PCN-boundary nodes are able support policies to distinguish by using the addresses
   that the RSVP messages are addressed to, initiate and process (1) RSVP
   SESSIONS
   maintain for generic aggregated sessions and their messages according
   to [RFC4860], (2) e2e RSVP sessions and messages according to
   [RFC2205]. Furthermore, it is considered that by configuration each pair of PCN-boundary-nodes of the
   PCN-interior-nodes are not able to distinguish neither RSVP generic
   aggregated sessions and their associated messages [RFC4860], nor e2e
   RSVP sessions and their associated messages [RFC2205]. same PCN-domain
   one ingress-egress-aggregate.

                    --------------------------
                   /       PCN-domain         \
      |----|      |                            |      |----|
   H--| R  |\ |-----|                       |------| /| R  |-->H
   H--|    |\\|     |   |---|     |---|     |      |//|    |-->H
      |----| \|     |   | I |     | I |     |      |/ |----|
              | Agg |======================>| Deag |
             /|     |   |   |     |   |     |      |\
   H--------//|     |   |---|     |---|     |      |\\-------->H
   H--------/ |-----|                       |------| \-------->H
                  |                            |
                   \                          /
                    --------------------------

   H       = Host requesting end-to-end RSVP reservations
   R       = RSVP router
   Agg     = Aggregator (PCN-ingress-node)
   Deag    = Deaggregator (PCN-egress-node)
   I       = Interior Router (PCN-interior-node)
   -->   = E2E RSVP reservation
   ==>   = Aggregate RSVP reservation

           Figure 1 : Aggregation of E2E Reservations
            over Generic Aggregate RSVP Reservations
               in PCN domains, based on [RFC4860]

   Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes)
   MUST support policies to initiate and maintain for each pair of
   PCN-boundary-nodes of the same PCN-domain one ingress-egress-
   aggregate. Both the Aggregator and Deaggregator can maintain one or
   more RSVP generic aggregated Reservations, but the Deaggregator is
   the entity that initiates these RSVP generic aggregated reservations.
   Note that one RSVP generic aggregated reservation matches to only
   one ingress-egress-aggregate, while one ingress-egress-aggregate
   matches to either one or to more than one RSVP generic aggregated
   reservations. This can be accomplished by using for the different
   RSVP generic aggregated reservations the same combinations of
   ingress and egress identifiers, but with a different PHB-ID value
   (see [RFC4860]). The procedures for aggregation of E2E reservations
   over generic aggregate RSVP reservations are the same as the
   procedures specified in Section 4 of [RFC4860], augmented with the
   following ones, see also Section 2.5:

   o) Aggregator (PCN-ingress-node) and Deaggregator (PCN-egress-node)
      MUST be able to determine, for each received e2e Path message, in
      which ingress-egress-aggregate it can be mapped to.

   o) Depending on policies the Aggregator and Deaggregator MUST be able
      to decide whether a RSVP generic aggregate reservations can be
      mapped into an ingress-egress-aggregate, see Section 2.5 for more
      details.

2.2   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 [RFC6660]. The PHB-ID (Per Hop
   Behavior Identification Code) used SHOULD be set equal
   to PCN-compatible Diffserv codepoint(s).

2.3.  Traffic Classification Within The Aggregation Region

   The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination
   of the DSCP and ECN fields), which interior nodes use to
   classify PCN-traffic. The PCN-traffic (e.g., e2e microflows)
   belonging to an ingress-egress-aggregate 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
   [RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e
   microflows) belonging to a RSVP generic aggregated reservation can be
   classified only at the PCN-boundary-nodes (i.e., Aggregator and
   Deaggregator) by using the RSVP SESSION object for RSVP generic
   aggregated reservations, see Section 2.1 of [RFC4860]. It is
   considered that tunnels need to be used between Aggregators and
   Deaggregators, using the same procedures as specified in Section 4 of
   [RFC4860].

2.4.  Deaggregator (PCN-egress-node) Determination

   To comply with this specification it is considered that in order to
   determine the Deaggregator, the same methods can be used as the ones
   described in Section 4 of [RFC4860] and in Section 1.4.2 of
   [RFC3175]. In the context of this document this can be determined
   very easily, since from the point of RSVP, the next     |---|     |      |\\-------->H
   H--------/ |-----|                       |------| \-------->H
                  |                            |
                   \                          /
                    --------------------------

   H       = Host requesting end-to-end RSVP hop for the reservations
   R       = RSVP router
   Agg     = Aggregator in the downstream direction is the (PCN-ingress-node)
   Deag    = Deaggregator and the
   next (PCN-egress-node)
   I       = Interior Router (PCN-interior-node)
   -->   = E2E RSVP hop for the Deaggregator in the upstream direction is the
   Aggregator.

2.5.  Mapping reservation
   ==>   = Aggregate RSVP reservation

           Figure 1 : Aggregation of E2E Reservations Onto
            over Generic Aggregate RSVP Reservations

   To comply with this specification it is considered that for the
   mapping of e2e reservations onto aggregate reservations, the same
   methods can be used as the ones described
               in Section 4 of [RFC4860],
   augmented by PCN domains, based on [RFC4860]

   Both the following rules:

   o) An Aggregator (PCN-ingress-node) MUST be able to determine for
      each e2e Path message that arrives at its external interface in
      which ingress-egress-aggregate it can be mapped to. This is
      possible, see also Section 2.4, since from the point of RSVP, the and Deaggregator (PCN-egress-node) is can maintain one RSVP hop away from the
      Aggregator (PCN-ingress-node). The Aggregator (PCN-ingress-node)
      uses PCN related information sent by the Deaggregator to
      map or
   more RSVP generic aggregated states to ingress-egress-aggregates.

   o) A PCN-ingress-node (Aggregator) or PCN-egress-node (Deaggregator)
      MUST use one or more policies to determine whether a Reservations, but the Deaggregator is
   the entity that initiates these RSVP generic aggregated reservation can be mapped into an ingress-egress-
      aggregate. reservations.
   Note that one RSVP generic aggregated reservation  matches to only
   one ingress-egress-aggregate, while one ingress-
      egress-aggregate ingress-egress-aggregate
   matches to either one or to more than one RSVP generic aggregated
   reservations. The Aggregator or the
      Deaggregator MUST be able to map RSVP generic aggregated
      reservations into ingress-egress-aggregates. This can be accomplished by using for the different
   RSVP generic aggregated reservations the same  combinations of
   ingress and egress identifiers, but with a different PHB-ID value (see [RFC4860]). In
      particular, each RSVP generic aggregated reservation is identified
      by using the RSVP SESSION object [RFC4860]. PHB-ID value
   (see [RFC4860]). The RSVP SESSION
      object procedures for aggregation of E2E reservations
   over generic aggregate RSVP reservations is based on are the RSVP
      SESSION object same as the
   procedures specified in [RFC4860] Section 4 of [RFC4860], augmented with the following
      information:

      o)
   ones specified in Section 2.5.

   One significant difference between this document and [RFC4860] is the IPv4 DestAddress, IPv6 DestAddress MUST be set to
   fact that in this document the IPv4
         or IPv6 destination addresses, respectively, admission control of E2E RSVP
   reservations over the
         Deaggregator (PCN-egress-node), see [RFC4860]. Note that PCN core is performed according to the
         PCN-domain PCN
   procedures, while in [RFC4860] this is considered as being only one achieved via first admitting
   aggregate RSVP hop (for
         Generic aggregated reservations over the aggregation region and then
   admitting the E2E reservations over the aggregate RSVP or e2e RSVP). This reservations.
   Therefore, in this document, the RSVP generic aggregate RSVP
   reservations are not subject to admission control in the PCN-core,
   and the E2E RSVP reservations are not subject to admission control
   over the aggregate reservations. In turn, this means that several
   procedures of [RFC4860] are significantly simplified in this
   document:

      o) unlike [RFC4860], the next generic aggregate RSVP hop for the Aggregator reservations need
         not be admitted in the downstream direction is PCN core.
      o) unlike [RFC4860], the
         Deaggregator RSVP aggregated traffic does not need to
         be tunneled between Aggregator and Deaggregator, see Section
         2.3.
      o) unlike [RFC4860], the next Deaggregator need not perform admission
         control of E2E reservations over the aggregate RSVP hop
         reservations.
      o) unlike [RFC4860], there is no need for dynamic adjustment of
         the Deaggregator RSVP generic aggregated reservation size, see Section 2.6.

2.2   PCN Marking and encoding and transport of pre-congestion
        information

   The method of PCN marking within the PCN domain is specified in
   [RFC5670]. In addition, the
         upstream direction method of encoding and transport of pre-
   congestion information is the Aggregator.

      o) specified in [RFC6660]. The PHB-ID (Per Hop
   Behavior Identification Code) used SHOULD be set equal
   to PCN-compatible Diffserv codepoint(s).

      o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination
         addresses,

2.3.  Traffic Classification Within The Aggregation Region

   The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination
   of the DSCP and ECN fields), which interior nodes use to
   classify PCN-traffic. The PCN-traffic (e.g., E2E microflows)
   belonging to a RSVP generic aggregated reservation can be
   classified only at the PCN-boundary-nodes (i.e., Aggregator (PCN-ingress-node), and
   Deaggregator) by using the RSVP SESSION object for RSVP generic
   aggregated reservations, see [RFC4860].

2.6.  Size Section 2.1 of Aggregate Reservations

   To comply with this specification it is considered [RFC4860]. Note that for the
   determination of
   DSCP value included in the size of SESSION object, SHOULD be set equal
   to a PCN-compatible Diffserv codepoint. Since no admission control
   procedures over the RSVP generic aggregate reservations, aggregated reservations in the same methods PCN-
   core are required, unlike [RFC4860], the RSVP aggregated traffic need
   not to be tunneled between Aggregator and Deaggregator. In this
   document one RSVP generic aggregated reservation is mapped to only
   one ingress-egress-aggregate, while one ingress-egress-aggregate is
   mapped to either one or to more than one RSVP generic aggregated
   reservations. PCN-flows and their PCN-traffic that are mapped into a
   specific RSVP generic aggregated reservation can also easily be used as the ones
   classified into their corresponding ingress-egress-aggregate. The
   method of traffic conditioning of PCN-traffic and non-PCN traffic and
   PHB configuration is described in [RFC4860] [RFC6661] and
   Section 1.4.4. of [RFC3175].

2.7. [RFC6662].

2.4.  Deaggregator Determination

   The present document assumes the same dynamic Deaggregator
   determination method as used in [RFC4860].

2.5.  Mapping E2E Path ADSPEC update Reservations Onto Aggregate Reservations

   To comply with this specification it is considered that specification for the
   update mapping of the e2e Path ADSPEC, E2E reservations
   onto aggregate reservations, the same methods can MUST be used as the
   ones described in [RFC4860].

2.8.  Intra-domain Routes

   The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP
   generic aggregation 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.
   Furthermore, it is considered that Section 4 of [RFC4860], augmented by configuration, the PCN-
   interior-nodes are not able following
   rules:

   o) An Aggregator (also PCN-ingress-node in this document) or
      Deaggregator (also PCN-egress-node and Decision Point in this
      document) MUST use one or more policies to distinguish neither determine whether a
      RSVP generic aggregated sessions and their associated messages [RFC4860], nor e2e
   RSVP sessions and their associated messages [RFC2205].

2.9.  Inter-domain Routes

   The PCN-charter scope precludes inter-domain considerations. However, reservation can be mapped into an ingress-
      Egress-aggregate. This can be accomplished by using for solving inter-domain routes changes associated with the operation
   of the
      different RSVP messages, generic aggregated reservations the same methods SHOULD be used as the ones
   described in [RFC4860] and in Section 1.4.7
      combinations of
   [RFC3175].

2.10.  Reservations for Multicast Sessions

   PCN does not consider reservations for multicast sessions.

2.11.  Multi-level Aggregation

   PCN does not consider multi-level aggregations within ingress and egress identifiers, but with a
      different PHB-ID value (see [RFC4860]) corresponding to the PCN domain.
   Therefore, the PCN-interior-nodes are not supporting multi-level
   aggregation procedures. However, the Aggregator and Deaggregator
   SHOULD support
      specifications. In particular, the multi-level aggregation procedures RSVP SESSION object specified
      in [RFC4860] and in Section 1.4.9 of [RFC3175].

2.12.  Reliability Issues

   To comply augmented with this specification it is considered that for solving
   possible reliability issues, the same methods can following information:

         o) the IPv4 DestAddress, IPv6 DestAddress MUST be used as set to the ones
   described in Section 4
         IPv4 or IPv6 destination addresses, respectively, of the
         Deaggregator (PCN-egress-node), see [RFC4860].

2.13.  Message Integrity and Node Authentication

   To comply with this specification it Note that the
         PCN-domain is considered as being only one RSVP hop (for
         Generic aggregated RSVP or E2E RSVP). This means that the next
         RSVP hop for message
   integrity the Aggregator in the downstream direction is the
         Deaggregator and node authentication, the same methods can be used as next RSVP hop for the ones described Deaggregator in Section 4 of [RFC4860] and [RFC5559].

3. Elements of Procedure

   This section describes the procedures used
         upstream direction is the Aggregator.

         o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set
         equal to PCN-compatible Diffserv codepoint(s).

         o) Extended vDstPort SHOULD be set to implement the
   aggregated RSVP procedure over PCN. It is considered that IPv4 or IPv6
         destination addresses, of the
   procedures for aggregation Aggregator (PCN-ingress-node),
         see [RFC4860].

2.6.  Size of Aggregate Reservations

   Since:(i) no admission control of e2e E2 reservations over generic aggregate the RSVP
   aggregated reservations are same as the procedures specified in Section
   4 is required, and (ii) no admission control of [RFC4860]. Please refer to [RFC4860] for all
   the below error
   cases:
      *) Incomplete message
      *) Unexpected objects

3.1.  Receipt of E2E Path Message By PCN-ingress-node (aggregating
      router)

   When RSVP aggregated reservation over the e2e Path message arrives at PCN core is required,
   the exterior interface size of the
   Aggregator, i.e., PCN-ingress-node, then standard RSVP generic
   aggregation [RFC4860] procedures are used, augmented with aggregate reservation is irrelevant and can
   be set to any arbitrary value by the Deaggreagtor. The Deaggregator
   SHOULD set the value of a generic aggregate reservation to a null
   bandwidth. We also observe that there is no need for dynamic
   adjustment of the
   following rules:

  o) The e2e RSVP aggregated reservation session associated with an e2e size.

2.7.  E2E Path
     message that arrives at ADSPEC update

   To comply with this specification, for the external interface update of the PCN-
     ingress-node is mapped/matched onto an PCN ingress-egress-
     aggregate.

  o) If the timer t-recvFail does NOT expire for a given PCN-egress-
     node, then:

         o) If (1) E2E Path
   ADSPEC, the PCN-admission state for same methods can be used as the ingress-egress-
            aggregate associated with ones described in
   [RFC4860].

2.8.  Intra-domain Routes

   The PCN-interior-nodes are neither maintaining E2E RSVP nor RSVP
   generic aggregation states and reservations. Therefore, intra-domain
   route changes will not affect intra-domain reservations since such
   reservations are not maintained by the received e2e Path PCN-interior-nodes.
   Furthermore, it is "admit",
            the Decision Point (i.e., PCN-ingress-node) SHOULD allow considered that by configuration, the
            new flow to be admitted PCN-
   interior-nodes are not able to that PCN ingress-egress-
            aggregate, see [RFC6661] distinguish neither RSVP generic
   aggregated sessions and [RFC6662]. their associated messages [RFC4860], nor E2E
   RSVP sessions and their associated messages [RFC2205].

2.9.  Inter-domain Routes

   The e2e Path message
            is then forwarded towards destination.

         o) If PCN-charter scope precludes inter-domain considerations. However,
   for solving inter-domain routes changes associated with the same PCN ingress-egress-aggregate operation
   of the PCN-admission-state is "block", RSVP messages, the request same methods SHOULD NOT be admitted by used as the PCN-ingress-node (Aggregator) ones
   described in [RFC4860] and an e2e
            PathErr message SHOULD be generated, using standard e2e RSVP
            procedures [RFC4495]. This e2e PathErr message is sent to
            the originating sender in Section 1.4.7 of
   [RFC3175].

2.10.  Reservations for Multicast Sessions

   PCN does not consider reservations for multicast sessions.

2.11.  Multi-level Aggregation

   PCN does not consider multi-level aggregations within the e2e Path message, using
            standard e2e RSVP procedures [RFC2205], [RFC4495]. This e2e
            PathErr message is sent to the originating sender of PCN domain.
   Therefore, the e2e
            Path message. The e2e RSVP error code "01: Admission Control
            failure" PCN-interior-nodes are not supporting multi-level
   aggregation procedures. However, the Aggregator and Deaggregator
   SHOULD support the "Sub-code = 2: Requested bandwidth
            unavailable " multi-level aggregation procedures specified in Appendix B
   [RFC4860] and in Section 1.4.9 of [RFC2205] SHOULD be
            used for this purpose.

            When the originating sender receives [RFC3175].

2.12.  Reliability Issues

   To comply with this e2e PathErr
            message it SHOULD apply a PCN specific policy to generate an
            e2e PathTear message to release all the specification, for solving possible Path states
            initiated on the e2e RSVP aware nodes on the path towards reliability
   issues, the PCN-ingress-node (Aggregator).

   o) If same methods MUST used as the timer t-recvFail expires ones described in Section 4
   of [RFC4860].

2.13.  Message Integrity and Node Authentication

   To comply with this specification, for a given PCN-egress-node, the
      Decision Point (i.e., PCN-ingress-node) SHOULD NOT
      allow message integrity and node
   authentication, the e2e microflow (i.e., PCN-flow) to same methods MUST be admitted to that
      PCN ingress-egress-aggregate, see [RFC6661], [RFC6662]. The
      admission or rejection procedure of a PCN-flow into used as the PCN-
      domain is defined ones described
   in detail in: [RFC6661] Section 4 of [RFC4860] and [RFC6662].
      If [RFC5559].

3. Elements of Procedure

   This section describes the Aggregator is not able procedures used to admit implement the e2e microflow it
      SHOULD then generate an e2e PathErr message using standard e2e
   aggregated RSVP procedures [RFC4495]. This e2e PathErr message procedure over PCN. It is sent to considered that the originating sender
   procedures for aggregation of the e2e Path message. The e2e E2E reservations over generic aggregate
   RSVP
      error code "01: Admission Control failure" and reservations are same as the "Sub-code =
      2: Requested bandwidth unavailable " procedures specified in Appendix B Section
   4 of
      [RFC2205] SHOULD be used for this purpose. When the originating
      sender receives this e2e PathErr message it SHOULD apply a PCN
      specific policy to generate an e2e PathTear message [RFC4860] except where a departure from these procedures is
   explicitly described in the present section. Please refer to release
   [RFC4860] for all the possible below error
   cases:
      o) Incomplete message
      o) Unexpected objects

3.1.  Receipt of E2E Path states initiated on the e2e RSVP aware nodes on Message by Aggregating router

   When the path towards E2E Path message arrives at the PCN-ingress-node (Aggregator).

   The way exterior interface of how the PCN-admission-state is maintained is specified
   Aggregator, (also PCN-ingress-node in
   [RFC6661] and [RFC6662]. The way of how the this document), then standard
   RSVP generic aggregated
   reservation state is maintained is specified in [RFC4860]. aggregation [RFC4860] procedures are used.

3.2.  Handling Of E2E Path Message By by Interior Routers

   The e2e E2E Path messages traverse zero or more PCN-interior-nodes.
   The PCN-interior-nodes receive the e2e E2E Path message on an interior
   interface and forward it on another interior interface.
   It is considered that that, by configuration configuration, the PCN-interior-nodes are not able
   to distinguish neither e2e
   ignore the E2E RSVP sessions and their associated signaling messages [RFC2205]. Therefore, the e2e E2E
   Path messages are simply forwarded as normal IP datagrams.

3.3.  Receipt of E2E Path Message By PCN-egress-node (Deaggregating
      router) by Deaggregating router

   When receiving the e2e E2E Path message the PCN-egress-node
   (Deaggregator) Deaggregator (also PCN-
   egress-node and Decision Point in this document) performs main the
   regular [RFC4860] procedures, augmented with the following rules:

     o) The PCN-egress-node Deaggregator 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 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, see also [draft-lefaucheur-rsvp-ecn-01].

     o) If the Deaggregator does not maintain any RSVP generic
        aggregated reservation states, then one or more of such states
        are created during this step. Moreover, also at this step
        the Deaggregator maps the new generated RSVP generic
        aggregated reservations onto one ingress-egress-aggregate
        maintained by the Deaggregator (PCN-egress-node), see Section
        2.5.

    The PCN-egress-nodes Deaggregator forwards the e2e E2E Path message towards the
    receiver.

3.4.  Initiation of new Aggregate Path Message By PCN-ingress-node
      (Aggregating Router) by Aggregating Router

   To comply with this specification it is considered that specification, for the initiation of the new RSVP
   generic aggregated Path message by the PCN-
   ingress-node (Aggregator), Aggregator (also PCN-ingress-
   node in this document), the same methods can MUST be used as the ones
   described in [RFC4860].

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 E2E Path message on an interior
   interface and forward it on another interior interface.
   It is considered that that, by configuration, the PCN-interior-nodes are
   not able to distinguish neither
   ignore the E2E RSVP generic aggregated sessions and
   their associated signaling messages [RFC4860]. [RFC2205]. Therefore, the
   Aggregated Path
   messages are simply forwarded as normal IP datagrams.

3.6. messages are simply forwarded as normal IP datagrams.

3.6.  Handling Of Aggregate Path Message By Deaggregating Router

   When receiving the Aggregated Path message, the Deaggregator (also
   PCN-egress-node and Decision Point in this document) performs the
   regular [RFC4860] procedures, augmented with the following rules:

   o) When the received Aggregated Path message by the Deaggregator
      contains the RSVP-AGGREGATE-IPv4-PCN-response or
      RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the
      PCN-sent-rate, then the procedures specified in Section 3.18 of
      this document MUST be followed.

3.7.  Handling of E2E Resv Message by Deaggregating Router

   When the e2e E2E Resv message arrives at the exterior interface of the
   Deaggregator, i.e., PCN-egress-node, (also PCN-egress-node and Decision Point in this
   document) then standard RSVP aggregation [RFC4860] procedures are used. It is important to be
   noticed
   used, augmented with the following rules:

  o) The E2E RSVP session associated with an E2E Resv
     message that according to [RFC4860] arrives at the external interface of the Deaggregator
     is responsible mapped/matched with an RSVP generic aggregate and with a PCN
     ingress-egress-aggregate.

  o) Depending on the type of performing the PCN edge behavior supported by the
     Deaggregator, the PCN admission control procedures specified in
     Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no
     admission control procedures over the RSVP aggregated reservations
     in the PCN-core are required, unlike [RFC4860], the Deaggregator
     does not perform any admission control of the E2E RESV onto Reservation over
     the mapped generic aggregate RSVP reservation.

3.7. If the PCN based
     admission control procedure is successful then the Deaggregator
     MUST allow the new flow to be admitted onto the associated RSVP
     generic aggregation reservation and onto the PCN ingress-egress-
     aggregate, see [RFC6661] and [RFC6662]. If the PCN based admission
     control procedure is not successful, then the E2E Resv MUST NOT be
     admitted onto the associated RSVP generic aggregate reservation and
     onto the PCN ingress-egress-aggregation. The E2E Resv message is
     further processed according to [RFC4860].

   The way of how the PCN-admission-state is maintained is specified in
   [RFC6661] and [RFC6662].

3.8.  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 E2E Resv message on an interior
   interface and forward it on another interior interface. It is
   considered that by configuration messages traversing the PCN-interior-nodes PCN core are not able IP addressed to distinguish neither e2e RSVP sessions the
   Aggregating router and their associated
   messages [RFC2205]. Therefore, are not marked with Router Alert, therefore
   the e2e E2E Resv messages are simply forwarded as normal IP datagrams.

3.8.

3.9.  Initiation of New Aggregate Resv Message By Deaggregating Router

   To comply with this specification it is considered that specification, for the initiation of the new RSVP
   generic aggregated Resv message by the PCN-
   egress-node (Deaggregator), Deaggregator (also PCN-egress-
   node and Decision Point in this document), the same methods can MUST be
   used as the ones described in
   Section 4 of [RFC4860] augmented with the following rules:

   o) At The size of the end generic aggregate reservation is irrelevant, see
      Section 2.6, and can be set to any arbitrary value by the PCN-
      egress node. The Deaggregator SHOULD set the value of each t-meas measurement interval, or less
        frequently if "optional report suppression" a RSVP
      generic aggregate reservation to a null bandwidth. We also
      observe that there is no need for dynamic adjustment of the RSVP
      generic aggregated reservation size.

   o) When [RFC6661] is activated, used and the ETM-rate measured by the
      Deaggregator contains a non-zero value for some
      ingress-egress-aggregate, see
        [RFC6661], [RFC6661] and [RFC6662], the PCN-egress-node
      Deagregator MUST include request the
        new PCN object that will be sent PCN-ingress-node to provide an
      estimate of the associated Decision
        Point (i.e., PCN-ingress-node). The PCN-egress-node reports rate (PCN-sent-rate) at which the
        data it measures for a particular ingress-egress-aggregate in a
        PCN object, as specified Aggregator
      (also PCN-ingress-node in Section 4 of this document (see
        [RFC6661], document) is receiving PCN-traffic
      that is destined for the given ingress-egress-aggregate.

   o) When [RFC6662] is used and [RFC6662]). The address the PCN-admission-state computed by the
      Deaggregator, on the basis of the PCN-ingress-
        node, i.e., Aggregator, CLE is "block" for the one specified in given
      ingress-egress-aggregate, the same
        ingress-egress-aggregate. It Deaggregator MUST request the PCN-
      ingress-node to provide an estimate of the rate (PCN-sent-rate) at
      which the Aggregator is considered receiving PCN-traffic that is
      destined for the ingress-
        egress-aggregate state stores both IP addresses of given ingress-egress-aggregate.

   o) In the above two cases and when the PCN-sent-rate needs to be
      requested from the PCN-
        ingress-node, i.e., Aggregator, the Deaggregator MUST generate
      and send an (refresh) Aggregated Resv message to the Aggregator
      that MUST carry one of the IP-egress-node, i.e.,
        Deaggregator.

3.9. following PCN objects, see Section 4.1,
      depending on whether IPv4 or IPv6 is supported:
       o) RSVP-AGGREGATE-IPv4-PCN-request
       o) RSVP-AGGREGATE-IPv6-PCN-request.

3.10.  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.
   It is considered that by configuration, traversing the PCN-interior-nodes PCN core are
   not able IP addressed
   to distinguish neither RSVP generic aggregated sessions the Aggregating router and
   their associated messages [RFC4860]. Therefore, are not marked with Router Alert,
   therefore the Aggregated Resv messages are simply forwarded as normal
   IP datagrams.

3.10.

3.11.  Handling of E2E Resv Message by Aggregating Router

   When the e2e E2E Resv message arrives at the interior interface of the
   Aggregating router, i.e., PCN-ingress-node,
   Aggregator (also PCN-ingress-node in this document), then standard
   RSVP aggregation [RFC4860] procedures are used.

3.11.

3.12.  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, Aggregator, (also PCN-ingress-node in this document),
   then standard RSVP aggregation [RFC4860] procedures are used,
   augmented with the following rules:
   o) the Aggregator SHOULD use the information carried by the PCN
      objects, see Section 4, and follow the steps specified in
      [RFC6661], [RFC6662]. If the Decision Point "R" flag carried by the
      RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request
      PCN objects is not collocated set to ON, see Section 4.1, then the Aggregator
      follows the steps described in Section 3.4 of [RFC6661] and
      [RFC6662] on calculating the PCN-sent-rate. In particular, the
      Aggregator MUST provide the estimated current rate of PCN-traffic
      received at that node and destined for a given ingress-egress-
      aggregate in octets per second (the PCN-sent-rate). The way this
      rate estimate is derived is a matter of implementation, see
      [RFC6661] or [RFC6662].

   o) the Aggregator initiates an Aggregated Path message. In
      particular, when the Aggregator receives an Aggregated Resv
      message which carries one of the following PCN objects:
      RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-
      request, with the PCN-ingress-
        node, then other procedures need flag "R" set to ON, see Section 4.1, the
      Aggregator initiates an Aggregated Path message, and includes the
      calculated PCN-sent-rate into the RSVP-AGGREGATE-IPv4-PCN-response
      or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, see Section 4.1,
      which that MUST be specified of handling carried by the Aggregated Resv Message by Path message. This
      Aggregated Path message is sent towards the Aggregating router, i.e., PCN-
        ingress-node. Even though these procedures are out Deaggregator (also
      PCN-egress-node and Decision Point in this document) that
      requested the calculation of the scope PCN-sent-rate.

3.13.  Removal of E2E Reservation

   To comply with this document, specification, for the PCN-ingress-node can refer to a central
        decision point which can respond to removal of E2E
   reservations, the PCN ingress same methods MUST be used as per
        [RFC2753]

    o)  If the Decision point is collocated ones described in
   Section 4 of [RFC4860] and [RFC4495].

3.14.  Removal of Aggregate Reservation

   To comply with this specification, for the PCN-ingress-node,
        then the PCN-ingress-node (i.e. Aggregator) SHOULD use removal of RSVP generic
   aggregated reservations, the
        information carried by same methods MUST be used as the PCN objects, see ones
   described in Section 4, 4 of [RFC4860] and Section 2.10 of [RFC3175]. In
   particular, should an aggregate reservation go away (presumably due
   to map
        the RSVP generic aggregated state onto a configuration change, route change, or policy event), the maintained ingress-
        egress-aggregate state at E2E
   reservations it supports are no longer active.
   They MUST be treated accordingly.

3.15.  Handling of Data On Reserved E2E Flow by Aggregating Router

   The handling of data on the reserved E2E flow by Aggregator (PCN-ingress-node).
        Furthermore, (also
   PCN-ingress-node in this document) uses the Aggregator follows procedures described
   in [RFC4860] augmented with:
   o)  Regarding, PCN marking and traffic classification the steps specified procedures
       defined in
        [RFC6661], [RFC6662]. Using Section 2.2 and 2.3 of this document are used.

3.16.  Procedures for Multicast Sessions

   In this document no multicast sessions are considered.

3.17.  Misconfiguration of PCN-node

   In an event where a PCN-node is misconfigured within a PCN-domain,
   the information contained desired behavior is same as described in the Section 3.10.

3.18 PCN
        object the Aggregator (i.e., PCN-ingress-node) can decide
        whether the PCN-admission state for the ingress-egress-aggregate
        is "admit" or "reject". Moreover, when based Flow Termination

   When the Aggregator (i.e.,
        PCN-ingress-node) Deaggregator (also PCN-egress-node and Decision Point in
   this document) needs to terminate an amount of traffic associated
   with one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of [RFC6661] and
   [RFC6662]), then several procedures of terminating e2e E2E microflows can
   be deployed. The default procedure of terminating e2e E2E microflows
   (i.e., PCN-
        flows) PCN-flows) is as follows, see e.g., [RFC6661]. i.e., [RFC6661] and [RFC6662].

   For the same ingress-egress-aggregate, select a number of e2e E2E
   microflows to be terminated in order to decrease the total incoming
   amount of bandwidth associated with one ingress-egress-
        aggregate ingress-egress-aggregate by
   the amount of traffic to be terminated, see above. In this situation
   the same mechanisms for terminating an e2e E2E microflow can be followed
   as specified in [RFC2205]. However, based on a local policy, the Aggregator
   Deaggregator could use other ways of selecting which microflows
   should be terminated. For example, for the same ingress-egress-aggregate, ingress-egress-
   aggregate, select a number of e2e microflows to be terminated or to reduce their
        reserved bandwidth in order to decrease the total incoming
        amount of bandwidth associated with one ingress-egress-aggregate
        by the amount of traffic to be terminated. In this situation the
        same mechanisms for terminating an e2e microflow or reducing
        bandwidth associated with an e2e microflow can be followed as
        specified in [RFC4495].

3.12.  Removal of E2E Reservation

   To comply with this specification it is considered that for the
   removal of e2e reservations, the same methods can be used as the ones
   described in Section 4 of [RFC4860] and [RFC4495], augmented by the
   methods described in Section 3.11.

3.13.  Removal of Aggregate Reservation

   To comply with this specification it is considered that for the
   removal of RSVP generic aggregated reservations, the same methods can
   be used as the ones described in Section 4 of [RFC4860] and Section
   2.10 of [RFC3175]. In particular, should an aggregate reservation go
   away (presumably due to a configuration change, route change, or
   policy event), the e2e reservations it supports are no longer active.
   They must be treated accordingly.

3.14.  Handling of Data On Reserved E2E Flow by Aggregating Router

   The handling of data on the microflows to be terminated or to
   reduce their reserved e2e Flow by Aggregating Router
   is using the procedures described bandwidth in [RFC4860] augmented with:

   o)  Regarding, PCN marking and traffic classification order to decrease the procedures
       defined in Section 2.2 and 2.4 total
   incoming amount of this document are used.

3.15.  Procedures for Multicast Sessions

   In this document no multicast sessions are considered.

3.16.  Misconfiguration bandwidth associated with one ingress-egress-
   aggregate by the amount of PCN-node traffic to be terminated. In an event where a PCN-node is misconfigured within a PCN-domain, this
   situation the desired behavior is same mechanisms for terminating an E2E microflow or
   reducing bandwidth associated with an E2E microflow can be followed
   as described specified in Section 3.9. Therefore,
   the Aggregated Resv messages are simply forwarded as normal IP
   datagrams. [RFC4495].

4.  Protocol Elements

   The protocol elements in this document are using the protocol
   elements ones defined in
   Section 4 of [RFC4860] and Section 3 of [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), see [RFC6661] and [RFC6662].

  o) the DSCP value included in the SESSION object, SHOULD be set equal
      to a PCN-compatible Diffserv codepoint.

   o) An aggregated Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination
      addresses, of the Aggregator (also PCN-ingress-node in this
      document), see [RFC4860].

   o) When the Deaggregator (also PCN-egress-node and Decision Point
      in this document) needs to request the PCN-sent-rate from the
      PCN-ingress-node, see Section 3.9 of this document, the
      Deaggregator MUST generate and send an (refresh) Aggregate
      Resv message to the Aggregator that MUST carry one or more of the
      following PCN objects, see Section 4.1, to report the data measured by an
     PCN-egress-node (i.e., Deaggregator). depending on whether IPv4
      or IPv6 is supported:
       o) As described in [RFC6661], [RFC6663], PCN reports
     from the PCN-egress-node (Deaggregator) to the decision point may
     contain flow identifiers for individual flows within RSVP-AGGREGATE-IPv4-PCN-request
       o) RSVP-AGGREGATE-IPv6-PCN-request.

  o) When the Aggregator receives an
     ingress-egress-aggregate that have recently experienced
     excess-marking. Hence, Aggregate Resv message which
      carries one of the following PCN report messages used by objects:
      RSVP-AGGREGATE-IPv4-PCN-request or
      RSVP-AGGREGATE-IPv6-PCN-request, with the PCN CL
     edge behavior flag "R" set to ON, see
      Section 4.1, then the Aggregator MUST be capable of carrying sequences of octet
     strings constituting such identifiers. When generate and send to the PCN CL edge
     behavior is used,
      Deaggregator an Aggregated Path message which carries one of the individual flow identifiers need to be
     included in specific
      following PCN objects, see Section 4.1, depending on whether IPv4
      or IPv6 is supported:
       o) RSVP-AGGREGATE-IPv4-PCN-response,
       o) RSVP-AGGREGATE-IPv6-PCN-response.

4.1
     (RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs,
      RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs)

4.1 PCN objects

   The PCN object reports data measured by a PCN-egress-node and
   carried by the generic aggregated RESV messages specified in
   [RFC4860]. PCN objects are defined for different PCN edge behavior
   drafts.

   This document defines six section describes four types of PCN objects that belong
   into the SESSION Class and need to can be carried
   by the (refresh) Aggregate RESV messages. These objects are:

   RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM,
   RSVP-AGGREGATE-IPv4-PCN-CL, RSVP-AGGREGATE-IPv6-PCN-CL,
   RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs.

   o) RSVP-AGGREGATE-IPv4-PCN-SM: Single Marking (SM) PCN object, when
      IPv4 addresses are used:
      Class = 1 (SESSION)
      C-Type = RSVP-AGGREGATE-IPv4-PCN-SM (to be replaced by IANA)

        +-------------+-------------+-------------+-------------+
        |     IPv4 PCN-ingress-node Address (4 bytes)           |
        +-------------+-------------+-------------+-------------+
        |     IPv4 PCN-egress-node Address (4 bytes)            |
        +-------------+-------------+-------------+-------------+
        |       rate of not marked PCN-traffic (NM-rate)        |
        +-------------+-------------+-------------+-------------+
        |       rate of PCN-marked PCN-traffic (PM-rate)        |
        +-------------+-------------+-------------+-------------|

   o) RSVP-AGGREGATE-IPv6-PCN-SM: Single Marking (SM) PCN object, when
      IPv6 addresses are used:

      Class = 1 (SESSION)
      C-Type = RSVP-AGGREGATE-IPv6-PCN-SM (to be replaced by IANA)

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +     IPv6 PCN-ingress-node Address (16 bytes)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +     IPv6 PCN-egress-node Address (16 bytes)           +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |       rate of not marked PCN-traffic (NM-rate)        |
        +-------------+-------------+-------------+-------------+
        |       rate of PCN-marked PCN-traffic (PM-rate)        |
        +-------------+-------------+-------------+-------------+ Path or the (refresh) Aggregate Resv
   messages specified in [RFC4860].

   These objects are:
       o RSVP-AGGREGATE-IPv4-PCN-request,
       o RSVP-AGGREGATE-IPv6-PCN-request,
       o RSVP-AGGREGATE-IPv4-PCN-response,
       o RSVP-AGGREGATE-IPv6-PCN-response.

   o) RSVP-AGGREGATE-IPv4-PCN-CL: Controlled (CL) RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when
      IPv4 addresses are used:
      Class = 1 (SESSION)
      C-Type = RSVP-AGGREGATE-IPv4-PCN-CL (To (to be replaced by IANA)
        +-------------+-------------+-------------+-------------+
        |     IPv4 PCN-ingress-node Address (4 bytes)           |
        +-------------+-------------+-------------+-------------+
        |     IPv4 PCN-egress-node Address (4 bytes)            |
        +-------------+-------------+-------------+-------------+
        |       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) RSVP-AGGREGATE-IPv6-PCN-CL: Controlled (CL) PCN object, IPv6
      addresses are used:
      Class = 1 (SESSION) (PCN)
      C-Type = RSVP-AGGREGATE-IPv6-PCN-CL RSVP-AGGREGATE-IPv4-PCN-request (to be replaced by IANA)

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +     IPv6     IPv4 PCN-ingress-node Address (16 (4 bytes)          +
        |                                                       |
        +                                                       +
        |           |
        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +     IPv6     IPv4 PCN-egress-node Address (16 (4 bytes)           +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |       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
   [RFC6663], [RFC6661] and [RFC6662]:

     o the IPv4 or IPv6 address of the PCN-ingress-node and the     IPv4
       or IPv6 address of the PCN-egress-node; together they specify the
       ingress-egress-aggregate to which the report refers. According to
       [RFC6663] the report should carry the identifier of the PCN-
       ingress-node and the identifier of the PCN-egress-node (typically
       their IP addresses);

     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 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; Decision Point Address (4 bytes)             |
        +-------------+-------------+-------------+-------------+
        |R|     Reserved                                        |
        +-------------+-------------+-------------+-------------|

   o) RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs: Controlled (CL) RSVP-AGGREGATE-IPv6-PCN-request: PCN CL Flow IDs object, IPv4 when
      IPv6 addresses are used:

      Class = 1 (SESSION) (to be replaced by IANA) (PCN)
      C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs RSVP-AGGREGATE-IPv6-PCN-request (to be replaced by IANA)

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                   +-+-+-+-+-+-+-+-+

        +-------------+-------------+-------------+-------------+
        |                                                       | Length
        +                                                       +
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                       |                       Source
        +     IPv6 PCN-ingress-node Address (16 bytes)          +
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                       |                      Destination Address
        +                                                       +
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                       |          Source Port
        +-------------+-------------+-------------+-------------+
        |       Destination Port                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +                                                       +
        |   Protocol                                                       |      Reserved
        +     IPv6 PCN-egress-node Address (16 bytes)           +
        |                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                             //
        +                                                       +
        |                       Source Address                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +-------------+-------------+-------------+-------------+
        |                      Destination Address                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +                                                       +
        |          Source Port                                                       |       Destination Port
        +     Decision Point Address (16 bytes)                 +
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                       |   Protocol
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |R|     Reserved                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o)  Length (1 byte): the length of the
          RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs object in units of 16 bytes.
          This field is used to specify the number of IPv4 flow IDs
          carried by this object. Each flow ID is represented by the
          combination of each subsequent 5 tuple:
          Source address, Destination address, Source Port,
          Destination Port and Protocol number.
          If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is
          empty.

      o) Source address (4 bytes):  The IPv4 source address.

      o) Destination address (4 bytes): The IPv4 destination address.

     o) Protocol (1 byte):  The IP protocol number. It refers to the
         true upper layer protocol carried by the packets.

      o) Source Port (2 bytes): contains the source port number.

      o) Destination Port (2 bytes): contains the destination port
         number.
        +-------------+-------------+-------------+-------------+

   o) RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs: Controlled (CL) RSVP-AGGREGATE-IPv4-PCN-response: PCN CL Flow IDs object, IPv6 IPv4
      addresses are used:
      Class = 1 (SESSION) (to be replaced by IANA) (PCN)
      C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs RSVP-AGGREGATE-IPv4-PCN-response (To be replaced by IANA)

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                   +-+-+-+-+-+-+-+-+

        +-------------+-------------+-------------+-------------+
        | Length     IPv4 PCN-ingress-node Address (4 bytes)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +-------------+-------------+-------------+-------------+
        |     IPv4 PCN-egress-node Address (4 bytes)            |
        +-------------+-------------+-------------+-------------+
        |                       Source     IPv4 Decision Point Address (4 bytes)             |
        +-------------+-------------+-------------+-------------+
        | PCN-sent-rate                                         |
        +-------------+-------------+-------------+-------------+

   o) RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6
      addresses are used:
      Class = (to be replaced by IANA) (PCN)
      C-Type = RSVP-AGGREGATE-IPv6-PCN-response (to be replaced by IANA)

        +-------------+-------------+-------------+-------------+
        |                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
        +                                                       +
        |                                                       |                      Destination
        +     IPv6 PCN-ingress-node Address (16 bytes)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |      Reserved                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                             //
        +                                                       +
        |                                                       |
   |                       Source
        +     IPv6 PCN-egress-node Address (16 bytes)           +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                       |
        +                                                       +
        |                                                       |                       Destination
        +     Decision Point Address (16 bytes)                 +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |      Reserved PCN-sent-rate                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o) Length (1 byte): the length of
        +-------------+-------------+-------------+-------------+

  The fields carried by the
         RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs PCN object are specified in units
   [RFC6663], [RFC6661] and [RFC6662]:

     o the IPv4 or IPv6 address of 40 bytes.
         This field is used the PCN-ingress-node (Aggregator) and
       the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator);
       together they specify the ingress-egress-aggregate to which the
       report refers. According to [RFC6663] the report should carry the
       identifier of the PCN-ingress-node (Aggregator) and the
       identifier of the PCN-egress-node (Deaggregator) (typically
       their IP addresses);

     o Decision Point address specify the number IPv4 or IPv6 address of flow IDs carried by the
       Decision Point. In this object. Each flow ID is represented by document this field MUST contain the combination IP
       address of
         each subsequent 5 tuple fields:

         Source address, Destination address, Source Port,
         Destination Port the Deaggregator.

     o "R": 1 bit flag that when set to ON, signifies, according to
       [RFC6661] and Protocol number.
         If Length [RFC6662], that the PCN-ingress-node (Aggregator)
       MUST provide an estimate of the rate (PCN-sent-rate) at which the
       PCN-ingress-node (Aggregator) is receiving PCN-traffic that is
       destined for the given ingress-egress-aggregate.

     O "Reserved": 31 bits that are currently not used by this
       document and are reserved. These SHALL be set to 0 then and SHALL be
       ignored on reception.

     o PCN-sent-rate: the RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object PCN-sent-rate for the given
       ingress-egress-aggregate. It is empty.

      o) Source address (16 bytes):  The IPv6 source address.

      o) Destination address (16 bytes): The IPv6 destination address.

      o) Protocol (1 byte): expressed in octets/second; its
       format is a 32-bit IEEE floating point number; The IP protocol number. It refers to PCN-sent-rate
       is specified in [RFC6661] and [RFC6662] and it represents the
          true upper layer protocol carried by
       estimate of the packets.

      o) Source Port (2 bytes): contains rate at which the source port number.

      o) Destination Port (2 bytes): contains PCN-ingress-node (Aggregator)
       is receiving PCN-traffic that is destined for the destination port
         number. given
       ingress-egress-aggregate.

5.  Security Considerations

   The same security considerations specified in [RFC2205], [RFC4230],
   [RFC4860], [RFC5559] and [RFC6411].

6.  IANA Considerations

   This document makes the following requests to the IANA.
   IANA needs to modify the RSVP parameters registry, 'Class Names,
   Class Numbers, and Class Types' subregistry, and assigned 6 add a new C-
   Types
   Class Number as well as assign 4 new C-Types under the existing SESSION this new Class (Class number 1),
   Number, as described
   Below, below, see Section 4.1:

   Class
   Number  Class Name                                       Reference
   ------  -----------------------                          ---------

        1  SESSION                                  [RFC2205]
  (defined
   by IANA) PCN                                       this document

           Class Types or C-Types:

            19?   RSVP-AGGREGATE-IPv4-PCN-SM        this document
            20?   RSVP-AGGREGATE-IPv6-PCN-SM        this document
            21?   RSVP-AGGREGATE-IPv4-PCN-CL
(defined by IANA)  RSVP-AGGREGATE-IPv4-PCN-request    this document
            22?   RSVP-AGGREGATE-IPv6-PCN-CL
(defined by IANA)  RSVP-AGGREGATE-IPv6-PCN-request    this document
            23?   RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs
(defined by IANA)  RSVP-AGGREGATE-IPv4-PCN-response   this document
            24?   RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs
(defined by IANA)  RSVP-AGGREGATE-IPv6-PCN-response   this document
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]. Moreover, we would
   like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor,
   Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur, James Polk and
   Lixia Zhang for the provided comments. In particular, we would like
   to thank Francois Le Faucheur for contributing in addition to
   comments also a significant amount of text.

8.  Normative References

   [RFC6661] T. Taylor, A, Charny, F. Huang,
   G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the
   Controlled Load (CL) Mode of Operation", July
   2012.

   [RFC6662] A. Charny, J. Zhang,
   G.  Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour
   for the Single Marking (SM) Mode of Operation",
   July 2012.

   [RFC6663] G. Karagiannis, T. Taylor,
   K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-)
   Congestion Information in a DiffServ Domain",
   July 2012.

   [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.

   [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le
   Faucheur, "Per Hop Behavior Identification Codes",
   RFC 3140, June 2001.

   [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
   "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
   September 2001.

   [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation
   Protocol (RSVP) Extension for the Reduction of
   Bandwidth of a Reservation Flow", RFC 4495, May 2006.

   [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.
   Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP)
   Reservations", RFC4860, May 2007.

   [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes",
    RFC 5670, November 2009.

  [RFC6660]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
    Encoding and Transport of Pre-Congestion Information", RFC 6660,
    July 2012.

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.

   [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",
   RFC 4230, December 2005.

   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
   Architecture", RFC 5559, June 2009.

   [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of
   Keying Methods for RSVP Security", RFC 6411, October 2011.

   [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
   Virtual Private Network", Work in Progress, July 2007.

   [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for
   Policy-based Admission Control", January 2000.

10. Appendix A:  Example Signaling Flow

   This appendix is based on the appendix provided in [RFC4860]. In
   particular, it provides an example signaling flow of the
   specification detailed in Section 3 and 4.

   This signaling flow assumes an environment where E2E reservations are
   aggregated over generic aggregate RSVP reservations and applied over
   a PCN domain. In particular the Aggregator (PCN-ingress-node) and
   Deaggregator (PCN-
   egress-node) (PCN-egress-node) are located at the boundaries of the
   PCN domain. The PCN-interior-nodes are located within the PCN-domain,
   between the PCN-boundary nodes, but are not shown in this Figure. It
   illustrates a possible RSVP message flow that could take place in the
   successful establishment of a unicast E2E reservation that is the
   first between a given pair of Aggregator/Deaggregator.

      Aggregator (PCN-ingress-node)     Deaggregator (PCN-egress-node)

    E2E Path
   ----------->
                (1)
                           E2E Path
                   ------------------------------->
                                                       (2)
                    E2E PathErr(New-agg-needed,SOI=GAx)
                   <----------------------------------
                    E2E PathErr(New-agg-needed,SOI=GAy) PathErr(New-agg-needed,SOI=GApcn)
                   <----------------------------------
(3)
                         AggPath(Session=GAx)
                   ------------------------------->
                         AggPath(Session=GAy)
                         AggPath(Session=GApcn)
                   ------------------------------->
(4)
                                                           E2E Path
                                                          ----------->
                                                       (5)
                         AggResv (Session=GAx) (PCN object)
                   <-------------------------------
                         AggResv (Session=GAy) (Session=GApcn) (PCN object)
                   <-------------------------------
(6)
                     AggResvConfirm (Session=GAx)
                   ------------------------------>
                     AggResvConfirm (Session=GAy) (Session=GApcn)
                   ------------------------------>
(7)
                                                           E2E Resv
                                                          <---------
                                                       (8)
                           E2E Resv (SOI=GAx) (SOI=GApcn)
                   <-----------------------------
                (9)
      E2E Resv
   <-----------

   (1) The Aggregator (PCN-ingress-node) maps the e2e RSVP reservation
    session associated with the e2e Path message onto an PCN ingress-
    egress-aggregate. The Aggregator forwards e2e E2E Path into the aggregation region
       after modifying its IP protocol number to
       RSVP-E2E-IGNORE. Note that in this case it is considered that the
       PCN-admission-state is "admit", see Section 3.1. Otherwise, the
       e2e Path will not be forwarded into the aggregation region and
       the steps associated with the PCN-admission-state is "block"
       situation specified in Section 3.1 will be followed. RSVP-E2E-IGNORE

   (2) Let's assume no Aggregate Path exists.  To be able to accurately
       update the ADSPEC of the e2e E2E Path, the Deaggregator needs the
       ADSPEC of Aggregate Path.  In this example, the Deaggregator
       elects to instruct the Aggregator to set up an Aggregate Path states
       state for the two supported PHB-IDs. PCN PHB-ID.  To do that, the Deaggregator
       sends two e2e an E2E PathErr messages message with a New-Agg-Needed PathErr
       code.  Both

       The PathErr messages message also contain contains a SESSION-OF-INTEREST
       (SOI) object.  In the first e2e PathErr, the SOI contains a
       GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x.  In the
       second e2e PathErr, the The SOI contains a GENERIC-AGGREGATE SESSION
       (GAy)
       (GApcn) whose PHB-ID is set to y.  In both messages the PCN PHB-ID. The GENERIC-
       AGGREGATE SESSION contains an interface-independent Deaggregator
       address inside the DestAddress and appropriate values inside the
       vDstPort and Extended vDstPort fields. In this document, the
       Extended vDstPort SHOULD contain the IPv4 or IPv6 address of
       the Aggregator.

   (3) The Aggregator follows the request from the Deaggregator and
       signals an Aggregate Path for both the GENERIC-AGGREGATE Sessions
       (GAx and GAy). Session
       (GApcn).

   (4) The Deaggregator takes into account the information contained in
       the ADSPEC from both Aggregate Paths and updates the e2e Path
       ADSPEC accordingly. E2E Path
       ADSPEC accordingly. 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, see also
       [draft-lefaucheur-rsvp-ecn-01]. The Deaggregator also modifies
       the e2e E2E Path IP protocol number to RSVP before forwarding it.

   (5) In this example, the Deaggregator elects to immediately proceed
       with establishment of the generic aggregate reservations for both
       PHB-IDs. reservation. In
       effect, the Deaggregator can be seen as anticipating
       the actual demand of e2e E2E reservations so that resources are
       available on the generic
       aggregate reservations reservation is in place when the e2e E2E Resv
       requests arrive,
       request arrives, in order to speed up establishment of e2e E2E
       reservations.
       At this step the Deaggregator maps the new generated RSVP generic
       aggregated reservations onto one ingress-egress-aggregate
       maintained by the Deaggregator (PCN-egress-node), see Section
       3.3. Moreover, the Deaggregator, depending on the used
       PCN edge behaviour and IP version, it includes one of the
       following PCN objects specified in Section 4.1:
       RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM,
       RSVP-AGGREGATE-IPv4-PCN-CL or RSVP-AGGREGATE-IPv6-PCN-CL. Here it is also Assumed assumed that the Deaggregator
       includes the optional Resv Confirm Request in these the Aggregate Resv.
       Resv message.

   (6) The Aggregator merely complies with the received ResvConfirm
       Request and returns the corresponding Aggregate ResvConfirm.
       Moreover, the PCN-ingress-node functionality uses the PCN object
       to map the RSVP generic aggregated reservation state onto the
       maintained PCN ingress-egress-aggregate state. Moreover, the
       Aggregator performs the steps specified in Section 3.11.

   (7) The Deaggregator has explicit confirmation that both Aggregate
       Resvs are the generic
       aggregate reservation is established.

   (8) On receipt of the e2e E2E Resv, the Deaggregator applies the mapping
       policy defined by the network administrator to map the e2e E2E Resv
       onto a generic aggregate reservation.  Let's assume that this
       policy is such that the e2e E2E reservation is to be mapped onto the
       generic aggregate reservation with the PCN PHB-ID=x. The
       Deaggregator knows that a generic aggregate reservation (GAx) (GApcn)
       is in place for the corresponding PHB-ID since (7).  At this step
       the Deaggregator maps the generic aggregated reservation onto one
       ingress-egress-aggregate maintained by the Deaggregator (as a
       PCN-egress-node), see Section 3.7. The Deaggregator performs
       admission control of the e2e E2E Resv onto the generic Aggregate
       reservation for the PCN PHB-ID (GApcn).  The Deaggregator takes
       also into account the PCN admission control procedure as
       as specified in [RFC6661] and [RFC6662], see Section 3.7.

       If one or both the admission control procedures (PCN based
       admission control procedure and admission control procedure
       specified in [RFC4860]) are not successful, then the E2E Resv is
       not admitted onto the associated RSVP generic aggregate
       reservation for PHB-ID=x (GAx).  Assuming the PCN PHB-ID (GApcn). Otherwise, assuming that
       the generic aggregate reservation for PHB-ID=x (GAx) the PCN (GApcn) had been
       established with sufficient bandwidth to support the e2e E2E Resv,
       the Deaggregator adjusts its counter, tracking the unused
       bandwidth on the generic aggregate reservation. Then it forwards
       the e2e E2E Resv to the Aggregator including a SESSION-OF-INTEREST
       object conveying the selected mapping onto GAx GApcn (and hence onto
       PHB-ID=x).
       the PCN PHB-ID).

   (9) The Aggregator records the mapping of the e2e E2E Resv onto GAx GApcn
       (and onto PHB-ID=x). the PCN PHB-ID). The Aggregator removes the SOI object
       and forwards the e2e E2E Resv towards the sender.

11.  Authors' Address

   Georgios Karagiannis
   University of Twente
   P.O. Box 217
   7500 AE Enschede,
   The Netherlands
   EMail: g.karagiannis@utwente.nl

   Anurag Bhargava
   Cisco Systems, Inc.
   7100-9 Kit Creek Road
   PO Box 14987
   RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987
   USA
   Email: anuragb@cisco.com