draft-ietf-tsvwg-rsvp-pcn-03.txt   draft-ietf-tsvwg-rsvp-pcn-04.txt 
Internet Engineering Task Force Georgios Karagiannis Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente Internet-Draft University of Twente
Intended status: Experimental Anurag Bhargava Intended status: Experimental Anurag Bhargava
Expires: April 12, 2013 Cisco Systems, Inc. Expires: August 23, 2013 Cisco Systems, Inc.
October 12, 2012 February 23, 2013
Generic Aggregation of Resource ReSerVation Protocol (RSVP) Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains for IPv4 And IPv6 Reservations over PCN domains
draft-ietf-tsvwg-rsvp-pcn-03 draft-ietf-tsvwg-rsvp-pcn-04
Abstract Abstract
This document specifies the extensions to the Generic Aggregated RSVP This document specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of the PCN Controlled Load (CL) and Single [RFC4860] for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre- Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Congestion Notification.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2013. This Internet-Draft will expire on August 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of RSVP extensions and Operations . . . . . . . . . . . 10 1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4
2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . 10 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 PCN Marking and encoding and transport of pre-congestion 1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
Information . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11
2.1.2. Traffic Classification Within The Aggregation Region . . . . 12 2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . 12 2.2. PCN Marking and encoding and transport of pre-congestion
2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . 12 Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . 12 2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . 13 2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . 13 2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 14
2.1.8. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . 13 2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14
2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . 13 2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14
2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . 13 2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14
2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . . 13 2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 14
2.1.12. Message Integrity and Node Authentication . . . . . . . . . 13 2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 14
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 13 2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15
2.13. Message Integrity and Node Authentication . . . . . . . . . . 15
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Receipt of E2E Path Message By PCN-ingress-node 3.1. Receipt of E2E Path Message By PCN-ingress-node
(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 13 (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 14 3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 16
3.3. Receipt of E2E Path Message By PCN-egress-node 3.3. Receipt of E2E Path Message By PCN-egress-node
(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 15 (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 15 (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 17
3.5. Handling Of new Aggregate Path Message By Interior Routers . . 15 3.5. Handling Of new Aggregate Path Message By Interior Routers . . 17
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 15 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 17
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 15 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 17
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 15 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 17
3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 16 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 16 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 18
3.11. Handling of Aggregated Resv Message by Aggregating Router . . 16 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 18
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 17 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 17 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 19
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 17 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 17 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 23 9. Informative References . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . . . 24 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 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 node. For more details see [RFC5559], [RFC6661], and
[RFC6662].
The main objective of this document is to specify the signalling
protocol that can be used within a Pre-Congestion Notification (PCN)
domain to carry reports from a PCN-egress-node to a PCN Decision
point, considering that the PCN decision Point and PCN-ingress-node
are collocated.
If the PCN decision point is not collocated with the PCN-ingress-node
then additional signalling procedures are required that are out of
the scope of this document.
Several signaling protocols can be used to carry reports from a PCN-
egress-node to a PCN-ingress-nodes. However, since both PCN-egress-
node and PCN-ingress-nodes are located on the data path, 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 Two main Quality of Service (QoS) architectures have been specified
by the IETF. These are the Integrated Services (Intserv) [RFC1633] by the IETF. These are the Integrated Services (Intserv) [RFC1633]
architecture and the Differentiated Services (DiffServ) architecture architecture and the Differentiated Services (DiffServ) architecture
([RFC2475]). ([RFC2475]).
Intserv provides methods for the delivery of end-to-end Quality of Intserv provides methods for the delivery of end-to-end Quality of
Service (QoS) to applications over heterogeneous networks. One of the Service (QoS) to applications over heterogeneous networks. One of the
QoS signaling protocols used by the Intserv architecture is the QoS signaling protocols used by the Intserv architecture is the
Resource reServation Protocol (RSVP) [RFC2205], which can be used by Resource reServation Protocol (RSVP) [RFC2205], which can be used by
applications to request per-flow resources from the network. These applications to request per-flow resources from the network. These
skipping to change at page 4, line 53 skipping to change at page 5, line 47
aware admission control, including aggregate RSVP reservations, per- aware admission control, including aggregate RSVP reservations, per-
flow RSVP, or a bandwidth broker. flow RSVP, or a bandwidth broker.
[RFC3175] specifies aggregation of Resource ReSerVation [RFC3175] specifies aggregation of Resource ReSerVation
Protocol (RSVP) end-to-end reservations over aggregate RSVP Protocol (RSVP) end-to-end reservations over aggregate RSVP
reservations. In [RFC3175] the RSVP aggregated reservation is reservations. In [RFC3175] the RSVP aggregated reservation is
characterized by a RSVP SESSION object using the 3-tuple <source IP characterized by a RSVP SESSION object using the 3-tuple <source IP
address, destination IP address, Diffserv Code Point>. address, destination IP address, Diffserv Code Point>.
Several scenarios require the use of multiple generic aggregate Several scenarios require the use of multiple generic aggregate
reservations that are established for a given PHB from a given source reservations that are established for a given PHB from a given source
IP address to a given destination IP address, see [RFC4860], IP address to a given destination IP address, see [SIG-NESTED],
[SIG-NESTED]. [RFC4860]. For example, multiple generic aggregate reservations
For example, multiple generic aggregate reservations
can be applied in the situation that multiple e2e reservations using can be applied in the situation that multiple e2e reservations using
different preemption priorities need to be aggregated through a PCN- different preemption priorities need to be aggregated through a PCN-
domain using the same PHB. By using multiple aggregate reservations domain using the same PHB. By using multiple aggregate reservations
for the same PHB allows enforcement of the different preemption for the same PHB allows enforcement of the different preemption
priorities within the aggregation region. This allows more efficient priorities within the aggregation region. This allows more efficient
management of the Diffserv resources, and in periods of resource management of the Diffserv resources, and in periods of resource
shortage, this allows sustainment of a larger number of E2E shortage, this allows sustainment of a larger number of E2E
reservations with higher preemption priorities. In particular, reservations with higher preemption priorities. In particular,
[SIG-NESTED] discusses in detail how end-to-end RSVP reservations can [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can
be established in a nested VPN environment through RSVP aggregation. be established in a nested VPN environment through RSVP aggregation.
skipping to change at page 5, line 31 skipping to change at page 6, line 19
established for a given PHB from a given source IP address to a given 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 destination IP address. This is achieved by adding the concept of a
Virtual Destination Port and of an Extended Virtual Destination Port Virtual Destination Port and of an Extended Virtual Destination Port
in the RSVP SESSION object. In addition to this, the RSVP SESSION in the RSVP SESSION object. In addition to this, the RSVP SESSION
object for generic aggregate reservations uses the PHB Identification object for generic aggregate reservations uses the PHB Identification
Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify 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 the PHB, or set of PHBs, from which the Diffserv resources are to be
reserved. reserved.
The main objective of Pre-Congestion Notification (PCN) is to support The RSVP like signaling protocol required to carry reports from a
the quality of service (QoS) of inelastic flows within a Diffserv PCN-egress-node to a PCN-ingress-node needs to follow the PCN
domain in a simple, scalable, and robust fashion. Two mechanisms are signaling requirements defined in [RFC6663]. In addition to
used: admission control, to decide whether to admit or block a new that the signalling protocol functionality supported by the PCN-
flow request, and (in abnormal circumstances) flow termination to ingress-nodes and PCN-egress-nodes needs to maintain logical
decide whether to terminate some of the existing flows. To achieve aggregate constructs (i.e. ingress-egrees-aggregate state) and be
this, the overall rate of PCN-traffic is metered on every link in the able to map e2e reservations to these aggregate constructs. Moreover,
PCN-domain, and PCN-packets are appropriately marked when certain no actual reservation state is needed to be maintained inside the PCN
configured rates are exceeded. These configured rates are below the domain, i.e., the PCN-interior-nodes are not maintaing any
rate of the link thus providing notification to PCN-boundary-nodes reservation state.
about incipient overloads before any congestion occurs (hence the
"pre" part of "pre-congestion notification"). The level of marking
allows decisions to be made about whether to admit or terminate PCN-
flows.
The PCN-egress-nodes measure the rates of differently marked This can be accomplished by two possible approaches:
PCN-traffic in periodic intervals and report these rates to the
decision points for admission control and flow termination, based on
which they take their decisions. The decision points may be
collocated with the PCN-ingress-nodes or their function may be
implemented in a centralized node. For more details see [RFC5559],
[RFC6661], [RFC6662]. In this document it is considered that the
decision point is collocated with the PCN-ingress-node.
This document follows the PCN signaling requirements defined in Approach (1):
[RFC6663] and specifies the
extensions to the Generic Aggregated RSVP [RFC4860] for the 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.
This document, and according to [RFC4860] MAY also be used end-to-end o) adapting the RFC 4860 aggregation procedures to fit the PCN
directly by end-systems attached to a Diffserv network. requirements with as little change as possible over the RFC 4860
Furthermore, this document and according to [RFC4860], in absence of functionality
e2e RSVP flows, a variety of policies (not defined in this document)
can be used at the Aggregator to set the DSCP of packets passing into
the aggregation region and how they are mapped onto generic aggregate
reservations. These policies are not described in this document but
are a matter of local configuration.
In this document it is considered that the PCN-nodes MUST be able to 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 the PCN-ingress-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 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 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 also the reason of chossing Approach
(1) for the specification of the signaling protocol used to carry PCN
information from the PCN-egress-node to the PCN-ingress-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], support the functionality specified in [RFC5670], [RFC5559],
[RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes
MUST support the RSVP generic aggregated reservation procedures MUST support the RSVP generic aggregated reservation procedures
specified in [RFC4860] which are augmented with procedures specified specified in [RFC4860] which are augmented with procedures specified
in this document. in this document.
1.1. Terminology 1.3. Terminology
This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], This document uses terms defined in [RFC4860], [RFC3175], [RFC5559],
[RFC5670], [RFC6661], [RFC6662]. [RFC5670], [RFC6661], [RFC6662].
For readability, a number of definitions from [RFC3175] as well as For readability, a number of definitions from [RFC3175] as well as
definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are
provided here, where some of them are augmented with new meanings: provided here, where some of them are augmented with new meanings:
Aggregator This is the process in (or associated with) the Aggregator This is the process in (or associated with) the
router at the ingress edge of the aggregation region router at the ingress edge of the aggregation region
skipping to change at page 7, line 54 skipping to change at page 8, line 57
reservation. The length of this idenitifier is 32- reservation. The length of this idenitifier is 32-
bits when IPv4 addresses are used and 128 bits when bits when IPv4 addresses are used and 128 bits when
IPv6 addresses are used. A sender(or Aggregator) IPv6 addresses are used. A sender(or Aggregator)
that wishes to narrow the scope of a SESSION to the that wishes to narrow the scope of a SESSION to the
sender-receiver pair (or Aggregator-Deaggregator sender-receiver pair (or Aggregator-Deaggregator
pair) SHOULD place its IPv4 or IPv6 address here as pair) SHOULD place its IPv4 or IPv6 address here as
a network unique identifier. A sender (or a network unique identifier. A sender (or
Aggregator) that wishes to use a common session Aggregator) that wishes to use a common session
with other senders (or Aggregators) in order to use with other senders (or Aggregators) in order to use
a shared reservation across senders (or a shared reservation across senders (or
Aggregators) MUST set this field to all zeros. In Aggregators) MUST set this field to all zeros.
this document, the Extended vDstPort SHOULD contain
the IPv4 or IPv6 address of the Aggregator. In this document, the Extended vDstPort SHOULD
contain the IPv4 or IPv6 address of the Aggregator.
PCN-domain: a PCN-capable domain; a contiguous set of PCN-domain: a PCN-capable domain; a contiguous set of
PCN-enabled nodes that perform Diffserv scheduling PCN-enabled nodes that perform Diffserv scheduling
[RFC2474]; the complete set of PCN-nodes that in [RFC2474]; the complete set of PCN-nodes that in
principle can, through PCN-marking packets, principle can, through PCN-marking packets,
influence decisions about flow admission and influence decisions about flow admission and
termination for the PCN-domain; includes termination for the PCN-domain; includes
the PCN-egress-nodes, which measure these the PCN-egress-nodes, which measure these
PCN-marks, and the PCN-ingress-nodes. PCN-marks, and the PCN-ingress-nodes.
skipping to change at page 9, line 28 skipping to change at page 10, line 27
SHOULD be set equal to PCN-compatible Diffserv SHOULD be set equal to PCN-compatible Diffserv
codepoint(s). codepoint(s).
o) Extended vDstPort SHOULD be set to the IPv4 or o) Extended vDstPort SHOULD be set to the IPv4 or
IPv6 destination addresses, of the Aggregator IPv6 destination addresses, of the Aggregator
(PCN-ingress-node) (PCN-ingress-node)
Ingress-egress-aggregate (IEA): Ingress-egress-aggregate (IEA):
The collection of PCN-packets from all PCN-flows The collection of PCN-packets from all PCN-flows
that travel in one direction between a specific pair that travel in one direction between a specific pair
of PCN-boundary-nodes. An ingress- of PCN-boundary-nodes. An ingress-egress-aggregate
egress-aggregate is identified by the is identified by the combination of (1) PCN-BA
combination of (1) fields), (2) IP addresses of the (i.e., combination of the DSCP and ECN fields),(2)
specific pair of PCN-boundary-nodes used by a IP addresses of the specific pair of
PCN-boundary-nodes used by the
ingress-egress-aggregate. In this document one RSVP ingress-egress-aggregate. In this document one RSVP
generic aggregated reservation is mapped to only one generic aggregated reservation is mapped to only one
ingress-egress-aggregate, while one ingress-egress- ingress-egress-aggregate, while one
aggregate is mapped to either one or to more than ingress-egress-aggregate is mapped to either one
one RSVP generic aggregated reservations. or to more than one RSVP generic aggregated
reservations.
PCN-admission-state PCN-admission-state:
The state ("admit" or "block") derived by the The state ("admit" or "block") derived by the
Decision Point for a given ingress-egress-aggregate Decision Point for a given ingress-egress-aggregate
based on statistics about PCN-packet marking. The based on statistics about PCN-packet marking. The
Decision Point decides to admit or block new flows Decision Point decides to admit or block new flows
offered to the aggregate based on the current value offered to the aggregate based on the current value
of the PCN-admission-state. of the PCN-admission-state.
Congestion level estimate (CLE) Congestion level estimate (CLE):
The ratio of PCN-marked to total PCN-traffic The ratio of PCN-marked to total PCN-traffic
(measured in octets) received for a given ingress- (measured in octets) received for a given ingress-
egress-aggregate during a given measurement period. egress-aggregate during a given measurement period.
The CLE is used to derive the PCN-admission-state The CLE is used to derive the PCN-admission-state
and is also used by the report suppression procedure and is also used by the report suppression procedure
if report suppression is activated. if report suppression is activated.
t_meas t-meas:
A configurable time interval that defines the A configurable time interval that defines the
measurement period over which the PCN-egress-node measurement period over which the PCN-egress-node
collects statistics relating to PCN-traffic marking. collects statistics relating to PCN-traffic marking.
t_maxsuppress t-fail:
A configurable time interval after which the An interval after which the Decision Point (i.e.,
PCN-egress-node MUST send a report to the Decision PCN-ingress-node) concludes that communication from a
Point for a given ingress-egress-aggregate regardless given PCN-egress-node has failed if it has received
of the most recent values of the CLE. This no reports from the PCN-egress-node during that
mechanism provides the Decision Point with a periodic interval.
confirmation of liveness when report suppression is
activated.
t_fail
An interval after which the Decision Point concludes
That communication from a given PCN-egress-node has
failed if it has received no reports from the
PCN-egress-node during that interval.
t_crit t-recvFail:
A configurable interval used in the calculation of A timer per ingress-egress-aggregate that the
T_fail. Decision point (i.e., PCN-ingress-node) sets every
time it receives an RSVP Aggregated RESV message for
that ingress-egress-aggregate. When its value
reaches t-fail it is assumed that the PCN-ingress-
node has lost contact with the PCN-egress-node.
Therefore the PCN-ingress-node blocks admission of
new PCN-flows into that aggregate and raises a
management alarm.
t-recvFail 1.4. Organization of This Document
An ingress-egress-aggregate timer that is used at This document is organized as follows. Section 2 gives an overview of
The Decision point (in this document at the PCN- RSVP extensions and operations. The elements of the used procedures
ingress-node) which when expires raises an alarm to are specified in Section 3. Section 4 describes the protocol
management, and activates the PCN-ingress-node to elements. The security considerations are given in section 5 and the
block the admission of new PCN-flows. This timer IANA considerations are provided in Section 6.
expires when it value is equal to T-fail and is
reset when a report, i.e., RSVP aggregated RESV
message, is received for a RSVP generic aggregated
reservation (which is matched to one
ingress-egress-aggregate).
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
2.1 Overview of RSVP Aggregation Procedures in PCN domains 2.1 Overview of RSVP Aggregation Procedures in PCN domains
The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
generic aggregated reservations {RFC4860], which are depending on generic aggregated reservations [RFC4860], which are depending on
ingress-egress-aggregates. In particular, one RSVP generic aggregated ingress-egress-aggregates. In particular, one RSVP generic aggregated
reservation matches to only one ingress-egress-aggregate. reservation matches to only one ingress-egress-aggregate.
However, one ingress-egress-aggregate matches to either However, one ingress-egress-aggregate matches to either
one or to more than one RSVP generic aggregated reservations. one or to more than one RSVP generic aggregated reservations.
In addition, in this document it is considered that the PCN-boundary In addition, to comply with this specification it is considered that
nodes are able to distinguish and process (1) RSVP SESSIONS for the PCN-boundary nodes are able to distinguish by usng the addresses
generic aggregated sessions and their messages according to that the RSVP messages are addressed to, and process (1) RSVP
[RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205]. SESSIONS for generic aggregated sessions and their messages according
Furthermore, it is considered that the PCN-interior-nodes are not to [RFC4860], (2) e2e RSVP sessions and messages according to
able to distinguish neither RSVP generic aggregated sessions and [RFC2205]. Furthermore, it is considered that by configuration the
their associated messages [RFC4860], nor e2e RSVP sessions and their PCN-interior-nodes are not able to distinguish neither RSVP generic
associated messages [RFC2205]. aggregated sessions and their associated messages [RFC4860], nor e2e
RSVP sessions and their associated messages [RFC2205].
-------------------------- --------------------------
/ PCN-domain \ / PCN-domain \
|----| | | |----| |----| | | |----|
H--| R |\ |-----| |------| /| R |-->H H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----| |----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag | | Agg |======================>| Deag |
/| | | | | | | |\ /| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H H--------//| | |---| |---| | |\\-------->H
skipping to change at page 11, line 42 skipping to change at page 12, line 42
Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes)
MUST support policies to initiate and maintain for each pair of MUST support policies to initiate and maintain for each pair of
PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress- PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress-
aggregate and (2) either one or more RSVP generic aggregated aggregate and (2) either one or more RSVP generic aggregated
reservations. Note that one RSVP generic aggregated reservation reservations. Note that one RSVP generic aggregated reservation
matches to only one ingress-egress-aggregate, while one ingress- matches to only one ingress-egress-aggregate, while one ingress-
egress-aggregate matches to either one or to more than one RSVP egress-aggregate matches to either one or to more than one RSVP
generic aggregated reservations. This can be accomplished by using generic aggregated reservations. This can be accomplished by using
for the different RSVP generic aggregated reservations the same for the different RSVP generic aggregated reservations the same
combinations of ingress and egress identifiers, but with a different combinations of ingress and egress identifiers, but with a different
PHB-ID value (see [RFC4860]). PHB-ID value (see [RFC4860]). The procedures for aggregation of E2E
Depending on a policy the Aggregator SHOULD be able to decide whether reservations over generic aggregate RSVP reservations are the same as
the procedures specified in Section 4 of [RFC4860].
Depending on a policy the Aggregator MUST be able to decide whether
an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP
generic aggregated reservation and (2) one ingress-egress-aggregate generic aggregated reservation and (2) one ingress-egress-aggregate
maintained by the Aggregator (i.e., PCN-ingress-node). Note that each maintained by the Aggregator (i.e., PCN-ingress-node). Note that each
RSVP generic aggregated reservation is identified by using the RSVP RSVP generic aggregated reservation is identified by using the RSVP
SESSION object [RFC4860]. The RSVP SESSION object for generic SESSION object [RFC4860]. The RSVP SESSION object for generic
aggregate reservations is based on the RSVP SESSION object specified aggregate reservations is based on the RSVP SESSION object specified
in [RFC4860] augmented with the following information: in [RFC4860] augmented with the following information:
o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4
or IPv6 destination addresses, respectively, of the Deaggregator or IPv6 destination addresses, respectively, of the Deaggregator
(PCN-egress-node) (PCN-egress-node), see [RFC4860]. 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 the
Aggregator in the downstream direction is the Deaggregator and
the next RSVP hop for the Deaggregator in the upstream direction
is the Aggregator. Furthermore, it is considered that for the
determination of the Deaggregator, the same methods can be used
as the ones described in Section 4 of [RFC4860].
o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal
to PCN-compatible Diffserv codepoint(s). to PCN-compatible Diffserv codepoint(s).
o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination
addresses, of the Aggregator (PCN-ingress-node) addresses, of the Aggregator (PCN-ingress-node), see [RFC4860].
2.1.1 PCN Marking and encoding and transport of pre-congestion 2.2 PCN Marking and encoding and transport of pre-congestion
information information
The method of PCN marking within the PCN domain is based on The method of PCN marking within the PCN domain is based on
[RFC5670]. In addition, the method of encoding and transport of pre- [RFC5670]. In addition, the method of encoding and transport of pre-
congestion information is based [RFC6660]. The PHB-ID (Per Hop congestion information is based [RFC6660]. The PHB-ID (Per Hop
Behavior Identification Code) used, SHOULD be set equal Behavior Identification Code) used SHOULD be set equal
to PCN-compatible Diffserv codepoint(s). to PCN-compatible Diffserv codepoint(s).
2.1.2. Traffic Classification Within The Aggregation Region 2.3. Traffic Classification Within The Aggregation Region
The PCN-traffic is marked using PCN-marking and is classified using The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., combination
The PCN-BA (i.e., combination of the DSCP and ECN fields). of the DSCP and ECN fields), which interior nodes use to
The PCN-traffic (e.g., e2e microflows) belonging to an ingress- classify PCN-traffic. The PCN-traffic (e.g., e2e microflows)
egress-aggregate can be classified only at the PCN-boundary-nodes belonging to an ingress-egress-aggregate can be classified only at
using the combination of (1) PCN-BA (i.e., combination of the DSCP the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e.,
and ECN fields), (2) IP addresses of the specific pair of PCN- combination of the DSCP and ECN fields), (2) IP addresses of the
boundary-nodes used by a ingress-egress-aggregate. specific pair of PCN-boundary-nodes used by a ingress-egress-
The method of classification and traffic conditioning of PCN-traffic aggregate. The method of classification and traffic conditioning of
and non-PCN traffic and PHB configuration is described in [RFC6661] PCN-traffic and non-PCN traffic and PHB configuration is described in
and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e microflows) [RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e
belonging to a RSVP generic aggregated reservation can be classified microflows) belonging to a RSVP generic aggregated reservation can be
only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by classified only at the PCN-boundary-nodes (i.e., Aggregator and
using the RSVP SESSION object for RSVP generic aggregated Deaggregator) by using the RSVP SESSION object for RSVP generic
reservations, see [RFC4860]. 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.1.3. Deaggregator (PCN-egress-node) Determination 2.4. Deaggregator (PCN-egress-node) Determination
In this document it is considered that for the determination of the To comply with this specification it is considered that to determine
Deaggregator, the same methods can be used as the ones described in the Deaggregator, the same methods can be used as the ones described
[RFC4860]. in Section 4 of [RFC4860].
2.1.4. Mapping E2E Reservations Onto Aggregate Reservations 2.5. Mapping E2E Reservations Onto Aggregate Reservations
In this document it is considered that for the mapping of e2e To comply with this specification it is considered that for the
reservations onto aggregate reservations, the same methods can be mapping of e2e reservations onto aggregate reservations, the same
used as the ones described in [RFC4860], augmented by the following methods can be used as the ones described in Section 4 of [RFC4860],
rules: augmented by the following rules:
o) PCN-ingress-node MUST use one or more policies to estimate whether o) PCN-ingress-node MUST use one or more policies to determine
an e2e RSVP reservation session associated with an e2e Path whether an e2e RSVP reservation session associated with an e2e
message that arrives at the external interface of the PCN-ingress- Path message that arrives at the external interface of the PCN-
node can be mapped onto an existing RSVP generic aggregation ingress-node can be mapped onto an existing RSVP generic
reservation state. aggregation reservation state.
2.1.5. Size of Aggregate Reservations 2.6. Size of Aggregate Reservations
In this document it is considered that for the determination of the To comply with this specification it is considered that for the
size of the RSVP generic aggregate reservations, the same methods can determination of the size of the RSVP generic aggregate reservations,
be used as the ones described in [RFC4860]. the same methods can be used as the ones described in [RFC4860] and
Section 1.4.4. of [RFC3175].
2.1.6. E2E Path ADSPEC update 2.7. E2E Path ADSPEC update
In this document it is considered that for the update of the e2e Path To comply with this specification it is considered that for the
ADSPEC, the same methods can be used as the ones described in update of the e2e Path ADSPEC, the same methods can be used as the
[RFC4860]. ones described in [RFC4860].
2.1.7. Intra-domain Routes 2.8. Intra-domain Routes
The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP
generic aggregation states and reservations. Therefore, intra-domain generic aggregation states and reservations. Therefore, intra-domain
route changes will not affect intra-domain reservations since such route changes will not affect intra-domain reservations since such
reservations are not maintained by the PCN-interior-nodes. reservations are not maintained by the PCN-interior-nodes.
Furthermore, it is considered that by configuration, 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].
2.1.8. Inter-domain Routes 2.9. Inter-domain Routes
In this document it is considered that for the solving the issues The PCN-charter scope precludes inter-domain considerations. However,
caused by the inter-domain route changes, the same methods can be for solving inter-domain routes changes associated with the operation
used as the ones described in [RFC4860]. of the RSVP messages, the same methods SHOULD be used as the ones
described in [RFC4860] and in Section 1.4.7 of
[RFC3175].
2.1.9. Reservations for Multicast Sessions 2.10. Reservations for Multicast Sessions
PCN does not consider reservations for multicast sessions. PCN does not consider reservations for multicast sessions.
2.1.10. Multi-level Aggregation 2.11. Multi-level Aggregation
PCN does not consider multi-level aggregations within the PCN domain. PCN does not consider multi-level aggregations within the PCN domain.
Therefore, the PCN-interior-nodes are not supporting multi-level
aggregation procedures. However, the Aggregator and Deaggregator
SHOULD support the multi-level aggregation procedures specified in
[RFC4860] and in Section 1.4.9 of [RFC3175].
2.1.11. Reliability Issues 2.12. Reliability Issues
In this document it is considered that for solving possible To comply with this specification it is considered that for solving
reliability issues, the same methods can be used as the ones possible reliability issues, the same methods can be used as the ones
described in [RFC4860]. described in Section 4 of [RFC4860].
2.1.12. Message Integrity and Node Authentication 2.13. Message Integrity and Node Authentication
In this document it is considered that for message integrity and node To comply with this specification it is considered that for message
authentication, the same methods can be used as the ones described in integrity and node authentication, the same methods can be used as
[RFC4860] and [RFC5559]. the ones described in Section 4 of [RFC4860] and [RFC5559].
3. Elements of Procedure 3. Elements of Procedure
This section describes the procedures used to implement the This section describes the procedures used to implement the
aggregated RSVP procedure over PCN. aggregated RSVP procedure over PCN. It is considered that the
procedures for aggregation of e2e reservations over generic aggregate
RSVP reservations are the same as the procedures specified in Section
4 of [RFC4860].
3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating
router) router)
When the e2e RSVP message arrives at the exterior interface of the When the e2e RSVP message arrives at the exterior interface of the
Aggregator, i.e., PCN-ingress-node, then standard RSVP generic Aggregator, i.e., PCN-ingress-node, then standard RSVP generic
aggregation [RFC4860] procedures are used, augmented with the aggregation [RFC4860] procedures are used, augmented with the
following rules: following rules:
o) The e2e RSVP reservation session associated with an e2e Path o) The e2e RSVP reservation session associated with an e2e Path
message that arrives at the external interface of the PCN- message that arrives at the external interface of the PCN-
ingress-node is mapped/matched onto an existing RSVP generic ingress-node is mapped/matched onto an existing RSVP generic
aggregation reservation state. aggregation reservation state.
o) If the timer t-recvFail expires for a given PCN-egress-node, the
Decision Point (i.e., PCN-ingress-node) SHOULD NOT
allow the e2e microflow (i.e., PCN-flow) to be admitted to that
RSVP generic aggregated reservation (which is matched to one
ingress-egress-aggregate). The admission or rejection procedure
of a PCN-flow into the PCN-domain is defined in detail in:
[RFC6661] and [RFC6662].
If the Aggregator is not able to admit the e2e microflow it
SHOULD then generate an e2e PathErr message using standard e2e
RSVP procedures [RFC4495]. This e2e PathErr message is sent to
the originating sender of the e2e Path message. A new error code
"PCN-domain rejects e2e reservation" MUST be augmented to the
RSVP error codes to inform the sender that a PCN domains rejects
the e2e reservation request.
o) If the timer t-recvFail does NOT expire for a given PCN-egress- o) If the timer t-recvFail does NOT expire for a given PCN-egress-
node, then: node, then:
o) If (1) the PCN-admission state for the ingress-egress- o) If (1) the PCN-admission state for the ingress-egress-
aggregate associated with the received e2e Path and (2) the aggregate associated with the received e2e Path and (2) the
state for the selected RSVP generic aggregated reservation, state for the selected RSVP generic aggregated reservation,
see [RFC4860], are "admit", the Decision Point (i.e., PCN- see [RFC4860], are "admit", the Decision Point (i.e., PCN-
ingress-node) SHOULD allow the new flow to be admitted to ingress-node) SHOULD allow the new flow to be admitted to
that RSVP generic aggregated reservation. The e2e Path that RSVP generic aggregated reservation, see [RFC6661] and
message is then forwarded towards destination. [RFC6662]. The e2e Path message is then forwarded towards
destination.
o) If for the same ingress-egress-aggregated and the same RSVP o) If for the same ingress-egress-aggregate and the same RSVP
generic aggregated reservation then (1) the PCN-admission- generic aggregated reservation (1) the PCN-admission-
state and/or (2) the state for the RSVP generic aggregated state and/or (2) the state for the RSVP generic aggregated
reservation are/is "block", the flow SHOULD NOT be reservation are/is "block", the flow SHOULD NOT be
admitted by the Aggregator and an e2e PathErr message SHOULD admitted by the Aggregator and an e2e PathErr message SHOULD
be generated, using standard e2e RSVP procedures be generated, using standard e2e RSVP procedures
[RFC4495]. This e2e PathErr message is sent to the [RFC4495]. This e2e PathErr message is sent to the
originating sender of the e2e Path message, using standard originating sender of the e2e Path message, using standard
e2e RSVP procedures [RFC2205], [RFC4495]. A new error code e2e RSVP procedures [RFC2205], [RFC4495]. A new error code
"PCN-domain rejects e2e reservation" MUST be augmented to "PCN-domain rejects e2e reservation" MUST be augmented to
the RSVP error codes to inform the sender that a PCN domains the RSVP error codes to inform the sender that a PCN domains
rejects the e2e reservation request. rejects the e2e reservation request.
o) If the timer t-recvFail expires for a given PCN-egress-node, the
Decision Point (i.e., PCN-ingress-node) SHOULD NOT
allow the e2e microflow (i.e., PCN-flow) to be admitted to that
RSVP generic aggregated reservation (which is matched to one
ingress-egress-aggregate), see [RFC6661], [RFC6662]. The
admission or rejection procedure of a PCN-flow into the PCN-
domain is defined in detail in: [RFC6661] and [RFC6662].
If the Aggregator is not able to admit the e2e microflow it
SHOULD then generate an e2e PathErr message using standard e2e
RSVP procedures [RFC4495]. This e2e PathErr message is sent to
the originating sender of the e2e Path message. The e2e RSVP
error code "01: Admission Control failure" and the "Sub-code =
2: Requested bandwidth unavailable " specified in Appendix B of
[RFC2205] SHOULD be used for this purpose.
The way of how the PCN-admission-state is maintained is specified in The way of how the PCN-admission-state is maintained is specified in
[RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated
reservation state is maintained is specified in [RFC4860]. reservation state is maintained is specified in [RFC4860].
3.2. Handling Of E2E Path Message By Interior Routers 3.2. Handling Of E2E Path Message By Interior Routers
The e2e Path messages traverse zero or more PCN-interior-nodes. The e2e Path messages traverse zero or more PCN-interior-nodes.
The PCN-interior-nodes receive the e2e Path message on an interior The PCN-interior-nodes receive the e2e Path message on an interior
interface and forward it on another interior interface. The e2e Path interface and forward it on another interior interface. It is
messages are simply forwarded as normal IP datagrams. considered that by configuration the PCN-interior-nodes are not able
to distinguish neither e2e RSVP sessions and their associated
messages [RFC2205]. Therefore, the e2e Path messages are simply
forwarded as normal IP datagrams.
3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating 3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating
router) router)
When receiving the e2e Path message the PCN-egress-node When receiving the e2e Path message the PCN-egress-node
(Deaggregator) performs main regular [RFC4860] procedures, augmented (Deaggregator) performs main regular [RFC4860] procedures, augmented
with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]: with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]:
o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL-
check and MUST NOT update the ADspec Break bit. This is because check and MUST NOT update the ADspec Break bit. This is because
the whole PCN-domain is effectively handled by e2e RSVP as a the whole PCN-domain is effectively handled by e2e RSVP as a
virtual link on which integrated service is indeed supported virtual link on which integrated service is indeed supported
(and admission control performed) so that the Break bit MUST (and admission control performed) so that the Break bit MUST
NOT be set. NOT be set.
The PCN-egress-nodes forwards the e2e Path message towards the The PCN-egress-nodes forwards the e2e Path message towards the
receiver. receiver.
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) (Aggregating Router)
In this document it is considered that for the initiation of the new To comply with this specification it is considered that for the
RSVP aggregated Path message by the PCN-ingress-node (Aggregator), initiation of the new RSVP aggregated Path message by the PCN-
the same methods can be used as the ones described in [RFC4860]. ingress-node (Aggregator), the same methods can be used as the ones
described in [RFC4860].
3.5. Handling Of new Aggregate Path Message By Interior Routers 3.5. Handling Of new Aggregate Path Message By Interior Routers
The Aggregate Path messages traverse zero or more PCN-interior-nodes. The Aggregate Path messages traverse zero or more PCN-interior-nodes.
The PCN-interior-nodes receive the e2e Path message on an interior The PCN-interior-nodes receive the e2e Path message on an interior
interface and forward it on another interior interface. The interface and forward it on another interior interface.
Aggregated Path messages are simply forwarded as normal IP datagrams. It is considered that by configuration, the PCN-interior-nodes are
not able to distinguish neither RSVP generic aggregated sessions and
their associated messages [RFC4860]. Therefore, the Aggregated Path
messages are simply forwarded as normal IP datagrams.
3.6. Handling of E2E Resv Message by Deaggregating Router 3.6. Handling of E2E Resv Message by Deaggregating Router
When the e2e Resv message arrives at the exterior interface of the When the e2e Resv message arrives at the exterior interface of the
Deaggregator, i.e., PCN-egress-node, then standard RSVP Deaggregator, i.e., PCN-egress-node, then standard RSVP
aggregation [RFC4860] procedures are used. aggregation [RFC4860] procedures are used.
3.7. Handling Of E2E Resv Message By Interior Routers 3.7. Handling Of E2E Resv Message By Interior Routers
The e2e Resv messages traverse zero or more PCN-interior-nodes. The The e2e Resv messages traverse zero or more PCN-interior-nodes. The
PCN-interior-nodes receive the e2e Resv message on an interior PCN-interior-nodes receive the e2e Resv message on an interior
interface and forward it on another interior interface. The e2e Resv interface and forward it on another interior interface. It is
messages are simply forwarded as normal IP datagrams. considered that by configuration the PCN-interior-nodes are not able
to distinguish neither e2e RSVP sessions and their associated
messages [RFC2205]. Therefore, the e2e Resv messages are simply
forwarded as normal IP datagrams.
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router
In this document it is considered that for the initiation of the new To comply with this specification it is considered that for the
RSVP aggregated Resv message by the PCN-ingress-node (Aggregator), initiation of the new RSVP aggregated Resv message by the PCN-
the same methods can be used as the ones described in [RFC4860] ingress-node (Aggregator), the same methods can be used as the ones
augmented with the following rules: described in Section 4 of [RFC4860] augmented with the following
rules:
o) At the end of each t-meas measurement interval, or less o) At the end of each t-meas measurement interval, or less
frequently if "optional report suppression" is activated, see frequently if "optional report suppression" is activated, see
[RFC6661], and [RFC6662], the PCN-egress-node MUST include the [RFC6661], and [RFC6662], the PCN-egress-node MUST include the
new PCN object that will be sent to the associated Decision new PCN object that will be sent to the associated Decision
Point (i.e., PCN-ingress-node). The PCN object is specified in Point (i.e., PCN-ingress-node). The PCN-egress-node reports the
this document and is used for the report of the data measured by data it measures for a particular ingress-egress-aggregate in a
the PCN-egress-node, for a particular ingress-egress-aggregate, PCN object, as specified in Section 4 of this document (see
see [RFC6661], and [RFC6662]. The address of the PCN-ingress- [RFC6661], and [RFC6662]). The address of the PCN-ingress-
node is the one specified in the same ingress-egress-aggregate. node, i.e., Aggregator, is the one specified in the same
ingress-egress-aggregate. It is considered that the ingress-
egress-aggregate state stores both IP addresses of the PCN-
ingress-node, i.e., Aggregator, and of the IP-egress-node, i.e.,
Deaggregator.
3.9. Handling of Aggregate Resv Message by Interior Routers 3.9. Handling of Aggregate Resv Message by Interior Routers
The Aggregated Resv messages traverse zero or more PCN-interior- The Aggregated Resv messages traverse zero or more PCN-interior-
nodes. The PCN-interior-nodes receive the Aggregated Resv message on nodes. The PCN-interior-nodes receive the Aggregated Resv message on
an interior interface and forward it on another interior interface. an interior interface and forward it on another interior interface.
The Aggregated Resv messages are simply forwarded as normal IP It is considered that by configuration, the PCN-interior-nodes are
datagrams. not able to distinguish neither RSVP generic aggregated sessions and
their associated messages [RFC4860]. Therefore, the Aggregated Resv
messages are simply forwarded as normal IP datagrams.
3.10. Handling of E2E Resv Message by Aggregating Router 3.10. Handling of E2E Resv Message by Aggregating Router
When the e2e Resv message arrives at the interior interface of the When the e2e Resv message arrives at the interior interface of the
Aggregating router, i.e., PCN-ingress-node, then standard RSVP Aggregating router, i.e., PCN-ingress-node, then standard RSVP
aggregation [RFC4860] procedures are used. aggregation [RFC4860] procedures are used.
3.11. Handling of Aggregated Resv Message by Aggregating Router 3.11. Handling of Aggregated Resv Message by Aggregating Router
When the Aggregated Resv message arrives at the interior interface of When the Aggregated Resv message arrives at the interior interface of
the Aggregating router, i.e., PCN-ingress-node, then standard RSVP the Aggregating router, i.e., PCN-ingress-node, then standard RSVP
aggregation [RFC4860] procedures are used, augmented with the aggregation [RFC4860] procedures are used, augmented with the
following rules: following rules:
o) the Decision Point (i.e., the PCN-ingress-node) SHOULD use the o) If the Decision Point is not collocated with the PCN-ingress-
node, then other procedures need to be specified of handling the
Aggregated Resv Message by the Aggregating router, i.e., PCN-
ingress-node. These procedures are out of the scope of this
document.
o) If the Decision point is collocated with the PCN-ingress-node,
then the PCN-ingress-node (i.e. Aggregator) SHOULD use the
information carried by the PCN objects as specified in information carried by the PCN objects as specified in
[RFC6661], [RFC6662]. When the Aggregator (i.e., [RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress-
PCN-ingress-node) needs to terminate an amount of traffic node) needs to terminate an amount of traffic associated with
associated to one ingress-egress-aggregate (see bullet 2 in one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of
Section 3.3.2 of [RFC6661] and [RFC6662]), then several [RFC6661] and [RFC6662]), then several procedures of terminating
procedures of terminating e2e microflows can be deployed. The e2e microflows can be deployed. The default procedure of
default procedure of terminating e2e microflows (i.e., terminating e2e microflows (i.e., PCN-flows) is as follows, see
PCN-flows) is as follows, see e.g., [RFC6661]. For the same e.g., [RFC6661].
ingress-egress-aggregate, select a number of e2e microflows
to be terminated in order to decrease the total incoming amount
of bandwidth associated with one ingress-egress-aggregate by the
amount of traffic to be terminated, see above.
In this situation the same mechanisms for terminating an e2e
microflow can be followed as specified in [RFC2205].
However, based on a local policy, the Aggregator could use
other procedures of terminating microflows.
For the same ingress-egress-aggregate, select a number of e2e
microflows to be terminated in order to decrease the total
incoming amount of bandwidth associated with one ingress-egress-
aggregate by the amount of traffic to be terminated, see above.
In this situation the same mechanisms for terminating an e2e
microflow can be followed as specified in [RFC2205]. However,
based on a local policy, the Aggregator could use other ways of
selecting which microflows should be terminated.
For example, for the same ingress-egress-aggregate, select a For example, for the same ingress-egress-aggregate, select a
number of e2e microflows to be terminated or to reduce their number of e2e microflows to be terminated or to reduce their
reserved bandwidth in order to decrease the total incoming reserved bandwidth in order to decrease the total incoming
amount of bandwidth associated with one ingress-egress-aggregate amount of bandwidth associated with one ingress-egress-aggregate
by the amount of traffic to be terminated. In this by the amount of traffic to be terminated. In this situation the
situation the same mechanisms for terminating an e2e microflow same mechanisms for terminating an e2e microflow or reducing
or reducing bandwidth associated with an e2e microflow can be bandwidth associated with an e2e microflow can be followed as
followed as specified in [RFC4495]. specified in [RFC4495].
3.12. Removal of E2E Reservation 3.12. Removal of E2E Reservation
In this document it is considered that for the removal of e2e To comply with this specification it is considered that for the
reservations, the same methods can be used as the ones described in removal of e2e reservations, the same methods can be used as the ones
[RFC4860] and [RFC4495]. described in Section 4 of [RFC4860] and [RFC4495], augmented by the
methods described in Section 3.11.
3.13. Removal of Aggregate Reservation 3.13. Removal of Aggregate Reservation
In this document it is considered that for the removal of RSVP To comply with this specification it is considered that for the
generic aggregated reservations, the same methods can be used as the removal of RSVP generic aggregated reservations, the same methods can
ones described in [RFC4860]. 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 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router
The handling of data on the reserved e2e Flow by Aggregating Router The handling of data on the reserved e2e Flow by Aggregating Router
is using the procedures described in [RFC4860] augmented with: is using the procedures described in [RFC4860] augmented with:
o) Regarding, PCN marking and traffic classification the procedures o) Regarding, PCN marking and traffic classification the procedures
defined in Section 2.1.1 and 2.1.3 of this document are used. defined in Section 2.2 and 2.4 of this document are used.
3.15. Procedures for Multicast Sessions 3.15. Procedures for Multicast Sessions
In this document no multicast sessions are considered. In this document no multicast sessions are considered.
4. Protocol Elements 4. Protocol Elements
The protocol elements in this document are using the protocol The protocol elements in this document are using the protocol
Elements defined in [RFC4860], augmented with the following rules: elements defined in Section 4 [RFC4860] and Section 3 of [RFC3175]
augmented with the following rules:
o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically
and at the end of each t-meas measurement interval, or less and at the end of each t-meas measurement interval, or less
frequently if "optional report suppression" is activated, an frequently if "optional report suppression" is activated, an
(refresh) aggregated RSVP message to the PCN-ingress-node (i.e. (refresh) aggregated RSVP message to the PCN-ingress-node (i.e.
aggregator). aggregator), see [RFC6661] and [RFC6662].
o) the DSCP value included in the SESSION object, SHOULD be set equal o) the DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint. to a PCN-compatible Diffserv codepoint.
o) An aggregated Resv message MUST carry one or more C-type PCN o) An aggregated Resv message MUST carry one or more C-type PCN
objects, see Section 4.1, to report the data measured by an objects, see Section 4.1, to report the data measured by an
PCN-egress-node (i.e., Deaggregator). PCN-egress-node (i.e., Deaggregator).
o) As described in [RFC6661], [RFC6663], PCN reports o) As described in [RFC6661], [RFC6663], PCN reports
from the PCN-egress-node (Deaggregator) to the decision point may from the PCN-egress-node (Deaggregator) to the decision point may
skipping to change at page 18, line 19 skipping to change at page 20, line 32
excess-marking. Hence, the PCN report messages used by the PCN CL excess-marking. Hence, the PCN report messages used by the PCN CL
edge behavior MUST be capable of carrying sequences of octet edge behavior MUST be capable of carrying sequences of octet
strings constituting such identifiers. When the PCN CL edge strings constituting such identifiers. When the PCN CL edge
behavior is used, the individual flow identifiers need to be behavior is used, the individual flow identifiers need to be
included in specific PCN objects, see Section 4.1 included in specific PCN objects, see Section 4.1
(C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, (C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs,
= RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs)
4.1 PCN object 4.1 PCN object
The PCN object reports data measured by an PCN-egress-node. PCN The PCN object reports data measured by a PCN-egress-node and
objects are defined for different PCN edge behavior drafts. This carried by the generic aggregated RESV messages specified in
document defines several types of PCN objects. [RFC4860]. PCN objects are defined for different PCN edge behavior
drafts. This document defines six types of PCN objects:
o) Single Marking (SM) PCN object, when IPv4 addresses are used: o) Single Marking (SM) PCN object, when IPv4 addresses are used:
Class = PCN Class = PCN
C-Type = RSVP-AGGREGATE-IPv4-PCN-SM C-Type = RSVP-AGGREGATE-IPv4-PCN-SM
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) | | IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) | | IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 20, line 38 skipping to change at page 22, line 38
| rate of threshold-marked PCN-traffic (ThM-rate) | | rate of threshold-marked PCN-traffic (ThM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of excess-traffic-marked PCN-traffic (ETM-rate) | | rate of excess-traffic-marked PCN-traffic (ETM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The fields carried by the PCN object are specified in The fields carried by the PCN object are specified in
[RFC6663], [RFC6661] and [RFC6662]: [RFC6663], [RFC6661] and [RFC6662]:
o the IPv4 or IPv6 address of the PCN-ingress-node and the IPv4 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 or IPv6 address of the PCN-egress-node; together they specify the
ingress-egress-aggregate to which the report refers; 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 o rate of not-marked PCN-traffic (NM-rate) in octets/second; its
format is a 32-bit IEEE floating point number; format is a 32-bit IEEE floating point number;
o rate of PCN-marked traffic (PM-rate) in octets/second; its format o rate of PCN-marked traffic (PM-rate) in octets/second; its format
is a 32-bit IEEE floating point number; is a 32-bit IEEE floating point number;
o rate of threshold-marked PCN traffic (ThM-rate) in o rate of threshold-marked PCN traffic (ThM-rate) in
octets/second; its format is a 32-bit IEEE floating point number; octets/second; its format is a 32-bit IEEE floating point number;
skipping to change at page 23, line 15 skipping to change at page 25, line 15
o) Protocol (1 byte): The IP protocol number. It refers to the o) Protocol (1 byte): The IP protocol number. It refers to the
true upper layer protocol carried by the packets. true upper layer protocol carried by the packets.
o) Source Port (2 bytes): contains the source port number. o) Source Port (2 bytes): contains the source port number.
o) Destination Port (2 bytes): contains the destination port o) Destination Port (2 bytes): contains the destination port
number. number.
5. Security Considerations 5. Security Considerations
The same security considerations specified in [RFC4860] and [RFC5559] The same security considerations specified in [RFC2205], [RFC4230],
apply also to this document. [RFC4860], [RFC5559] and [RFC6411].
6. IANA Considerations 6. IANA Considerations
This document makes the following requests to the IANA: This document makes the following requests to the IANA:
o allocate a new Object Class (PCN Object), see Section 4.1. o allocate a new Object Class (PCN Object), see Section 4.1.
o allocate a "PCN-domain rejects e2e reservation" Error Code that o allocate a "PCN-domain rejects e2e reservation" Error Code that
may appear only in e2e PathErr messages, see Section 3.1. may appear only in e2e PathErr messages, see Section 3.1.
7. Acknowledgments 7. Acknowledgments
skipping to change at page 25, line 5 skipping to change at page 27, line 5
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "A framework for Differentiated Services", RFC 2475, W. Weiss, "A framework for Differentiated Services", RFC 2475,
December 1998. December 1998.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A
Framework for Integrated Services Operation Over DiffServ Networks", Framework for Integrated Services Operation Over DiffServ Networks",
RFC 2998, November 2000. RFC 2998, November 2000.
[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",
RFC 4230, December 2005.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. 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 [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
Virtual Private Network", Work in Progress, February 2007. Virtual Private Network", Work in Progress, February 2007.
10. Authors' Address 10. Authors' Address
Georgios Karagiannis Georgios Karagiannis
University of Twente University of Twente
P.O. Box 217 P.O. Box 217
7500 AE Enschede, 7500 AE Enschede,
The Netherlands The Netherlands
 End of changes. 85 change blocks. 
278 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/