draft-ietf-tsvwg-rsvp-pcn-01.txt   draft-ietf-tsvwg-rsvp-pcn-02.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: Standards Track Anurag Bhargava Intended status: Standards Track Anurag Bhargava
Expires: September 10, 2012 Cisco Systems, Inc. Expires: January 07, 2013 Cisco Systems, Inc.
March 10, 2012 July 07, 2012
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-01 draft-ietf-tsvwg-rsvp-pcn-02
Abstract Abstract
This document specifies the extensions to the Generic Aggregated RSVP This document specifies the extensions to the 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 10, 2012. This Internet-Draft will expire on January 07, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of RSVP extensions and Operations . . . . . . . . . . . . 9 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 10
2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . . 9 2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . 10
2.1.1 PCN Marking and encoding and transport of pre-congestion 2.1.1 PCN Marking and encoding and transport of pre-congestion
Information . . . . . . . . . . . . . . . . . . . . . . . . . 11 Information . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2. Traffic Classification Within The Aggregation Region . . . . 11 2.1.2. Traffic Classification Within The Aggregation Region . . . . 12
2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . 11 2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . 12
2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . 11 2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . 12
2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . 12 2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . 12
2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . 12 2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . 13
2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . 12 2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . 13
2.1.8. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . 12 2.1.8. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . 13
2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . 12 2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . 13
2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . 12 2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . 13
2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . . 12 2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . . 13
2.1.12. Message Integrity and Node Authentication . . . . . . . . . 12 2.1.12. Message Integrity and Node Authentication . . . . . . . . . 13
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 13 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 13
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) . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 14 3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 14
3.3. Receipt of E2E Path Message By PCN-egress-node 3.3. Receipt of E2E Path Message By PCN-egress-node
(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 14 (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 15
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) . . . . . . . . . . . . . . . . . . . . . 14 (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 15
3.5. Handling Of new Aggregate Path Message By Interior Routers . . 15 3.5. Handling Of new Aggregate Path Message By Interior Routers . . 15
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 15 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 15
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 15 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 15
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 15 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 15
3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 15 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 16
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 16 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 16
3.11. Handling of Aggregated Resv Message by Aggregating Router . . 16 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 16
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 16 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 17
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 17 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 17
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 17 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 17
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 17 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 17
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 23
9. Informative References . . . . . . . . . . . . . . . . . . . . . 25 9. Informative References . . . . . . . . . . . . . . . . . . . . . 24
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
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
RSVP requests can be admitted or rejected by the network. RSVP requests can be admitted or rejected by the network.
Applications can express their quantifiable resource requirements Applications can express their quantifiable resource requirements
skipping to change at page 4, line 43 skipping to change at page 4, line 43
However, DiffServ does not include any mechanism for communication However, DiffServ does not include any mechanism for communication
between applications and the network. Several solutions have been between applications and the network. Several solutions have been
specified to solve this issue. One of these solutions is Intserv over specified to solve this issue. One of these solutions is Intserv over
Diffserv [RFC2998] including resource-based admission control, Diffserv [RFC2998] including resource-based admission control,
policy-based admission control, assistance in traffic policy-based admission control, assistance in traffic
identification/classification, and traffic conditioning. identification/classification, and traffic conditioning.
Intserv over Diffserv can operate over a statically provisioned Intserv over Diffserv can operate over a statically provisioned
Diffserv region or RSVP aware. When it is RSVP aware, several Diffserv region or RSVP aware. When it is RSVP aware, several
mechanisms may be used to support dynamic provisioning and topology- mechanisms may be used to support dynamic provisioning and topology-
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.
RFC 3175 [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
reservations that are established for a given PHB from a given source
IP address to a given destination IP address, see [RFC4860],
[SIG-NESTED].
For example, multiple generic aggregate reservations
can be applied in the situation that multiple 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 [RFC4860] provides generic aggregate reservations by extending
[RFC3175] to support multiple aggregate reservations for the same [RFC3175] to support multiple aggregate reservations for the same
source IP address, destination IP address, and PHB (or set of PHBs). source IP address, destination IP address, and PHB (or set of PHBs).
In particular, multiple such generic aggregate reservations can be In particular, multiple such generic aggregate reservations can be
established for a given PHB (or set of PHBs) from a given source IP established for a given PHB from a given source IP address to a given
address to a given destination IP address. This is achieved by adding destination IP address. This is achieved by adding the concept of a
the concept of a Virtual Destination Port and of an Extended Virtual Virtual Destination Port and of an Extended Virtual Destination Port
Destination Port in the RSVP SESSION object. In addition to this, the in the RSVP SESSION object. In addition to this, the RSVP SESSION
RSVP SESSION object for generic aggregate reservations uses the object for generic aggregate reservations uses the PHB Identification
PHB Identification Code (PHB-ID) defined in [RFC3140], instead of Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
using the Diffserv Code Point (DSCP) used in [RFC3175]. The PHB-ID is Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify
used to identify the PHB, or set of PHBs, from which the Diffserv the PHB, or set of PHBs, from which the Diffserv resources are to be
resources are to be reserved. This is among others used to specify reserved.
whether the Diffserv resources belong to a single PHB or to a set of
PHBs.
The main objective of Pre-Congestion Notification (PCN) is to support The main objective of Pre-Congestion Notification (PCN) is to support
the quality of service (QoS) of inelastic flows within a Diffserv the quality of service (QoS) of inelastic flows within a Diffserv
domain in a simple, scalable, and robust fashion. Two mechanisms domain in a simple, scalable, and robust fashion. Two mechanisms are
are used: admission control and flow termination. Admission control used: admission control, to decide whether to admit or block a new
is used to decide whether to admit or block a new flow request while flow request, and (in abnormal circumstances) flow termination to
flow termination is used in abnormal circumstances to decide decide whether to terminate some of the existing flows. To achieve
whether to terminate some of the existing flows. To support these this, the overall rate of PCN-traffic is metered on every link in the
two features, the overall rate of PCN-traffic is metered on every PCN-domain, and PCN-packets are appropriately marked when certain
link in the domain, and PCN-packets are appropriately marked when configured rates are exceeded. These configured rates are below the
certain configured rates are exceeded. These configured rates are rate of the link thus providing notification to PCN-boundary-nodes
below the rate of the link thus providing notification to boundary about incipient overloads before any congestion occurs (hence the
nodes about overloads before any congestion occurs (hence "pre- "pre" part of "pre-congestion notification"). The level of marking
congestion" notification). allows decisions to be made about whether to admit or terminate PCN-
flows.
The PCN-egress-nodes measure the rates of differently marked The PCN-egress-nodes measure the rates of differently marked
PCN-traffic in periodic intervals and report these rates to the PCN-traffic in periodic intervals and report these rates to the
decision points for admission control and flow termination, based on decision points for admission control and flow termination, based on
which they take their decisions. The decision points may be which they take their decisions. The decision points may be
collocated with the PCN-ingress-nodes or their function may be collocated with the PCN-ingress-nodes or their function may be
implemented in a centralized node. implemented in a centralized node. For more details see [RFC5559],
For more details see[RFC5559], [draft-ietf-pcn-cl-edge-behaviour-12], [draft-ietf-pcn-cl-edge-behaviour-15], [draft-ietf-pcn-sm-edge-
[draft-ietf-pcn-sm-edge-behaviour-09]. In this document it is behaviour-12]. In this document it is considered that the decision
Considered that the decision point is collocated with the PCN- point is collocated with the PCN-ingress-node.
ingress-node.
This document follows the PCN signaling requirements defined in This document follows the PCN signaling requirements defined in
[draft-ietf-pcn-signaling-requirements-08.txt] and specifies the [draft-ietf-pcn-signaling-requirements-08.txt] and specifies the
extensions to the Generic Aggregated RSVP [RFC4860] for the support extensions to the Generic Aggregated RSVP [RFC4860] for the support
of PCN edge behaviors as specified in [draft-ietf-pcn-cl-edge- of PCN edge behaviors as specified in [draft-ietf-pcn-cl-edge-
behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]. Moreover, behaviour-15] and [draft-ietf-pcn-sm-edge-behaviour-12]. Moreover,
this document specifies how RSVP aggregation can be used to setup and this document specifies how RSVP aggregation can be used to setup and
maintain: (1) Ingress Egress Aggregate (IEA) states at Ingress and maintain: (1) Ingress Egress Aggregate (IEA) states at Ingress and
Egress nodes and (2) generic aggregation of RSVP end-to-end RSVP Egress nodes and (2) generic aggregation of RSVP end-to-end RSVP
reservations over PCN (Congestion and Pre-Congestion Notification) reservations over PCN (Congestion and Pre-Congestion Notification)
domains. domains.
This document, and according to [RFC4860] MAY also This document, and according to [RFC4860] MAY also be used end-to-end
be used end-to-end directly by end-systems attached to a Diffserv directly by end-systems attached to a Diffserv network.
network.
Furthermore, this document and according to [RFC4860], in absence of Furthermore, this document and according to [RFC4860], in absence of
e2e RSVP flows, a variety of policies (not defined in this document) 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 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 the aggregation region and how they are mapped onto generic aggregate
reservations. These policies are not described in this document but reservations. These policies are not described in this document but
are a matter of local configuration. are a matter of local configuration.
In this document it is considered that the PCN-nodes MUST be able to In this document it is considered that the PCN-nodes MUST be able to
support the functionality specified in [RFC5670], [RFC5559], support the functionality specified in [RFC5670], [RFC5559],
[RFC5696],[draft-ietf-pcn-cl-edge-behaviour-12], [draft-ietf-pcn-sm- [RFC5696],[draft-ietf-pcn-cl-edge-behaviour-15], [draft-ietf-pcn-sm-
edge-behaviour-09]. Furthermore, the PCN-boundary-nodes MUST support edge-behaviour-12]. Furthermore, the PCN-boundary-nodes MUST support
the RSVP generic aggregated reservation procedures specified in the RSVP generic aggregated reservation procedures specified in
[RFC4860] which are augmented with procedures specified in this [RFC4860] which are augmented with procedures specified in this
document. document.
1.1. Terminology 1.1. Terminology
This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], This document uses terms defined in [RFC4860], [RFC3175], [RFC5559],
[RFC5670], [draft-ietf-pcn-cl-edge-behaviour-12], [RFC5670], [draft-ietf-pcn-cl-edge-behaviour-15], [draft-ietf-pcn-sm-
[draft-ietf-pcn-sm-edge-behaviour-09]. edge-behaviour-12].
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], [draft-ietf-pcn-cl-edge- definitions for terms used in [RFC5559], [draft-ietf-pcn-cl-edge-
behaviour-12], and [draft-ietf-pcn-sm-edge-behaviour-09] are provided behaviour-15], and [draft-ietf-pcn-sm-edge-behaviour-12] are provided
here, where some of them are augmented with new meanings: 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
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-ingress-node and the document, it is also the PCN-ingress-node and the
decision point. decision point.
Deaggregator This is the process in (or associated with) the Deaggregator This is the process in (or associated with) the
router at the egress edge of the aggregation region router at the egress edge of the aggregation region
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-egress-node. document, it is also the PCN-egress-node.
E2E End to end E2E (or e2e) end to end
E2E Reservation This is an RSVP reservation such that: E2E Reservation This is an RSVP reservation such that:
(i) corresponding RSVP Path messages are initiated (i) corresponding RSVP Path messages are initiated
upstream of the Aggregator and terminated upstream of the Aggregator and terminated
downstream of the Deaggregator, and downstream of the Deaggregator, and
(ii) corresponding RSVP Resv messages are initiated (ii) corresponding RSVP Resv messages are initiated
downstream of the Deaggregator and terminated downstream of the Deaggregator and terminated
upstream of the Aggregator, and upstream of the Aggregator, and
(iii) this RSVP reservation is aggregated over an (iii) this RSVP reservation is aggregated over an
Ingress Egress Aggregate (IEA) between the Ingress Egress Aggregate (IEA) between the
Aggregator and Deaggregator.
Aggregator and An E2E RSVP reservation may be a per-flow
Deaggregator An E2E RSVP reservation may be a per-flow
reservation, which in this document is only reservation, which in this document is only
maintained at the PCN-ingress-node and PCN-egress- maintained at the PCN-ingress-node and PCN-egress-
node. Alternatively, the E2E reservation may itself node. Alternatively, the E2E reservation may itself
be an aggregate reservation of various types (e.g., be an aggregate reservation of various types (e.g.,
Aggregate IP reservation, Aggregate IPsec Aggregate IP reservation, Aggregate IPsec
reservation, see [RFC4860]). As per regular RSVP reservation, see [RFC4860]). As per regular RSVP
operations, E2E RSVP reservations are operations, E2E RSVP reservations are
unidirectional. unidirectional.
PHB-ID (Per Hop Behavior Identification Code) PHB-ID (Per Hop Behavior Identification Code)
skipping to change at page 8, line 26 skipping to change at page 8, line 41
PCN-packets, PCN-packets,
PCN-BA: a PCN-domain carries traffic of different Diffserv PCN-BA: a PCN-domain carries traffic of different Diffserv
behavior aggregates (BAs) [RFC2474]. The PCN-BA behavior aggregates (BAs) [RFC2474]. The PCN-BA
uses the PCN mechanisms to carry PCN-traffic, and uses the PCN mechanisms to carry PCN-traffic, and
the corresponding packets are PCN-packets. the corresponding packets are PCN-packets.
The same network will carry traffic of other The same network will carry traffic of other
Diffserv BAs. The PCN-BA is Diffserv BAs. The PCN-BA is
distinguished by a combination of the Diffserv distinguished by a combination of the Diffserv
codepoint (DSCP) and ECN fields. 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 PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
admits (or terminates); the unit could be a single admits (or terminates); the unit could be a single
microflow (as defined in [RFC2474]) or some e2e microflow (as defined in [RFC2474]) or some
identifiable collection of microflows. identifiable collection of microflows.
Ingress-egress-aggregate (IEA): RSVP generic aggregated reservation: an RSVP reservation that is
identified by using the RSVP SESSION object
for generic RSVP aggregate 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 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 is identified by the egress-aggregate is identified by the
combination of (1) fields), (2) IP addresses of the combination of (1) fields), (2) IP addresses of the
specific pair of PCN-boundary-nodes used by a specific pair of PCN-boundary-nodes used by a
ingress-egress-aggregate. In this document the ingress-egress-aggregate. In this document one RSVP
ingress-egress-aggregate is associated with a RSVP generic aggregated reservation is mapped to only one
generic aggregated reservation state [RFC4860]. ingress-egress-aggregate, while one ingress-egress-
aggregate is mapped to either one 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 (PCN-ingress-node) for a given Decision Point for a given ingress-egress-aggregate
ingress-egress-aggregate based on PCN packet marking based on statistics about PCN-packet marking. The
statistics. The Decision Point decides to admit or Decision Point decides to admit or block new flows
block new flows offered to the aggregate based on offered to the aggregate based on the current value
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 collects statistics relating to PCN-traffic marking.
marking.
At the end of the interval the PCN-egress-node
calculates the values NM-rate, ThM-rate,
and ETM-rate as defined and sends a report to the
Decision Point, subject to the operation of the
Report suppression feature.
T-maxsuppress t_maxsuppress
A configurable time interval after which the PCN- A configurable time interval after which the
egress-node MUST send a report to the Decision PCN-egress-node MUST send a report to the Decision
Point for a given ingress-egress-aggregate Point for a given ingress-egress-aggregate regardless
regardless of the most recent values of the CLE. of the most recent values of the CLE. This
This mechanism provides the Decision Point with a mechanism provides the Decision Point with a periodic
Periodic confirmation of liveness when report confirmation of liveness when report suppression is
suppression is activated. activated.
T-fail t_fail
A configurable interval after which the Decision An interval after which the Decision Point concludes
Point Concludes that communication from a given PCN- That communication from a given PCN-egress-node has
egress-node has failed if it has received no reports failed if it has received no reports from the
from the PCN-egress-node during that interval. PCN-egress-node during that interval.
t-recvFail t_crit
A configurable interval used in the calculation of
T_fail.
t-recvFail
An ingress-egress-aggregate timer that is used at An ingress-egress-aggregate timer that is used at
The Decision point (in this document at the PCN- The Decision point (in this document at the PCN-
ingress-node) which when expires raises an alarm to ingress-node) which when expires raises an alarm to
management, and activates the PCN-ingress-node to management, and activates the PCN-ingress-node to
block the admission of new PCN-flows. This timer block the admission of new PCN-flows. This timer
expires when it value is equal to T-fail and is expires when it value is equal to T-fail and is
reset when a report, i.e., RSVP aggregated RESV reset when a report, i.e., RSVP aggregated RESV
message, is received for the ingress-egress- message, is received for a RSVP generic aggregated
aggregate. 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, an ingress-egress-aggregate ingress-egress-aggregates. In particular, one RSVP generic aggregated
matches to only one RSVP SESSION for generic aggregated reservations. reservation matches to only one ingress-egress-aggregate.
However, a RSVP SESSION for generic aggregated reservations can match However, one ingress-egress-aggregate matches to either
to one or more than one ingress-egress-aggregates. This can be one or to more than one RSVP generic aggregated reservations.
accomplished by using for the different ingress-egress-aggregates the In addition, in this document it is considered that the PCN-boundary
same combinations of ingress and egress identifiers, but with a nodes are able to distinguish and process (1) RSVP SESSIONS for
different PHB-ID value (see [RFC4860]). generic aggregated sessions and their messages according to
[RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205].
Furthermore, it is considered that 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].
-------------------------- --------------------------
/ 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
H--------/ |-----| |------| \-------->H H--------/ |-----| |------| \-------->H
| | | |
skipping to change at page 10, line 32 skipping to change at page 11, line 32
Deag = Deaggregator (PCN-egress-node) Deag = Deaggregator (PCN-egress-node)
I = Interior Router (PCN-interior-node) I = Interior Router (PCN-interior-node)
--> = E2E RSVP reservation --> = E2E RSVP reservation
==> = Aggregate RSVP reservation ==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations Figure 1 : Aggregation of E2E Reservations
over Generic Aggregate RSVP Reservations over Generic Aggregate RSVP Reservations
in PCN domains, based on [RFC4860] in PCN domains, based on [RFC4860]
In addition, in this document it is considered that the PCN-boundary
nodes are able to distinguish and process (1) RSVP SESSIONS for
generic aggregated sessions and their messages according to
[RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205].
Furthermore, it is considered that 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].
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 combination MUST support policies to initiate and maintain for each pair of
of the PCN-boundary-node and all other PCN-boundary-nodes of the same PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress-
PCN-domain one RSVP SESSION for generic aggregated reservations. Note aggregate and (2) either one or more RSVP generic aggregated
that RSVP SESSION for generic aggregated reservations can match to reservations. Note that one RSVP generic aggregated reservation
one or more than one ingress-egress-aggregates. This can be matches to only one ingress-egress-aggregate, while one ingress-
accomplished by using for the different ingress-egress-aggregates the egress-aggregate matches to either one or to more than one RSVP
same combinations of ingress and egress identifiers, but with a generic aggregated reservations. This can be accomplished by using
different PHB-ID value (see [RFC4860]). Depending on a policy the for the different RSVP generic aggregated reservations the same
Aggregator SHOULD be able to decide whether an e2e RSVP session can combinations of ingress and egress identifiers, but with a different
be mapped into one ingress-egress-aggregate maintained by the PHB-ID value (see [RFC4860]).
Aggregator (i.e., PCN-ingress-node). Depending on a policy the Aggregator SHOULD be able to decide whether
an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP
The RSVP SESSION object for generic aggregate reservations, maintains generic aggregated reservation and (2) one ingress-egress-aggregate
the mapping and association between the PCN ingress-egress-aggregate maintained by the Aggregator (i.e., PCN-ingress-node). Note that each
and the PCN-flows (e2e RSVP reservation session) that travel in one RSVP generic aggregated reservation is identified by using the RSVP
direction between the specific pair of PCN-boundary-nodes specified SESSION object [RFC4860]. The RSVP SESSION object for generic
by the ingress-egress-aggregate. Note that in this document the PCN aggregate reservations is based on the RSVP SESSION object specified
ingress-egress-aggregate is identified by using the RSVP SESSION in [RFC4860] augmented with the following information:
object for generic aggregate reservation, see [RFC4860], by using the
following:
o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4 o) the IPv4 DestAddress, IPv6 DestAddress SHOULD 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)
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)
2.1.1 PCN Marking and encoding and transport of pre-congestion 2.1.1 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 [RFC5696]. The PHB-ID (Per Hop congestion information is based [RFC5696]. 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.1.2. Traffic Classification Within The Aggregation Region
The PCN-traffic is marked using PCN-marking and is classified using The PCN-traffic is marked using PCN-marking and is classified using
The PCN-BA (i.e., combination of the DSCP and ECN fields). The PCN-BA (i.e., combination of the DSCP and ECN fields).
The PCN-traffic belonging to an PCN aggregated session can be The PCN-traffic (e.g., e2e microflows) belonging to an ingress-
classified only at the PCN-boundary-nodes using the combination of egress-aggregate can be classified only at the PCN-boundary-nodes
(1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP using the combination of (1) PCN-BA (i.e., combination of the DSCP
addresses of the specific pair of PCN-boundary-nodes used by a and ECN fields), (2) IP addresses of the specific pair of PCN-
ingress-egress-aggregate. boundary-nodes used by a ingress-egress-aggregate.
The method of classification and traffic conditioning of PCN-traffic The method of classification and traffic conditioning of PCN-traffic
and non-PCN traffic and PHB configuration is described in draft-ietf- and non-PCN traffic and PHB configuration is described in draft-ietf-
pcn-cl-edge-behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]. pcn-cl-edge-behaviour-15] and [draft-ietf-pcn-sm-edge-behaviour-12].
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
[RFC4860].
2.1.3. Deaggregator (PCN-egress-node) Determination 2.1.3. Deaggregator (PCN-egress-node) Determination
In this document it is considered that for the determination of the In this document it is considered that for the determination of the
Deaggregator, the same methods can be used as the ones described in Deaggregator, the same methods can be used as the ones described in
[RFC4860]. [RFC4860].
2.1.4. Mapping E2E Reservations Onto Aggregate Reservations 2.1.4. Mapping E2E Reservations Onto Aggregate Reservations
In this document it is considered that for the mapping of e2e In this document it is considered that for the mapping of e2e
reservations onto aggregate reservations, the same methods can be reservations onto aggregate reservations, the same methods can be
used as the ones described in [RFC4860], augmented by the following used as the ones described in [RFC4860], augmented by the following
rules: 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 estimate whether
an e2e RSVP reservation session associated with an e2e Path an e2e RSVP reservation session associated with an e2e Path
message that arrives at the external interface of the PCN-ingress- message that arrives at the external interface of the PCN-ingress-
node can be mapped onto an existing RSVP generic aggregation node can be mapped onto an existing RSVP generic aggregation
reservation state, i.e., PCN ingress-egress-aggregate. reservation state.
2.1.5. Size of Aggregate Reservations 2.1.5. Size of Aggregate Reservations
In this document it is considered that for the determination of the In this document it is considered that for the determination of the
size of the aggregate reservations, the same methods can be used as size of the RSVP generic aggregate reservations, the same methods can
the ones described in [RFC4860]. be used as the ones described in [RFC4860].
2.1.6. E2E Path ADSPEC update 2.1.6. E2E Path ADSPEC update
In this document it is considered that for the update of the e2e Path In this document it is considered that for the update of the e2e Path
ADSPEC, the same methods can be used as the ones described in ADSPEC, the same methods can be used as the ones described in
[RFC4860]. [RFC4860].
2.1.7. Intra-domain Routes 2.1.7. 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
skipping to change at page 13, line 14 skipping to change at page 13, line 53
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.
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 onto an existing RSVP generic aggregation ingress-node is mapped/matched onto an existing RSVP generic
reservation state (i.e., PCN ingress-egress-aggregate). aggregation reservation state.
o) If the timer t-recvFail expires for a given PCN-egress-node, the o) If the timer t-recvFail expires for a given PCN-egress-node, the
Decision Point (i.e., PCN-ingress-node) SHOULD NOT Decision Point (i.e., PCN-ingress-node) SHOULD NOT
allow the e2e RSVP flow to be admitted to that ingress-egress- allow the e2e microflow (i.e., PCN-flow) to be admitted to that
aggregate. This procedure is defined in detail in: RSVP generic aggregated reservation (which is matched to one
[draft-ietf-pcn-cl-edge-behaviour-12] and ingress-egress-aggregate). The admission or rejection procedure
[draft-ietf-pcn-sm-edge-behaviour-09]. of a PCN-flow into the PCN-domain is defined in detail in:
[draft-ietf-pcn-cl-edge-behaviour-15] and [draft-ietf-pcn-sm-
Depending on a local policy the Aggregator SHOULD decide edge-behaviour-12].
whether this situation is considered of being an error, or If the Aggregator is not able to admit the e2e microflow it
whether the e2e reservation session SHOULD be mapped to another SHOULD then generate an e2e PathErr message using standard e2e
ingress-egress-aggregate maintained by the same RSVP SESSION RSVP procedures [RFC4495]. This e2e PathErr message is sent to
for aggregated reservations. the originating sender of the e2e Path message. A new error code
"PCN-domain rejects e2e reservation" MUST be augmented to the
If the Aggregator is not able to map the requesting e2e RSVP RSVP error codes to inform the sender that a PCN domains rejects
session into another ingress-egress-aggregate, then the the e2e reservation request.
Aggregator SHOULD NOT admit the e2e RSVP session and it SHOULD
generate an e2e PathErr message using standard e2e RSVP
procedures [RFC2205]. This e2e PathErr message is sent to the
originating sender of the e2e Path message.
o) If the timer t-recvFail does NOT expire for a given PCN-egress- o) If the timer t-recvFail does NOT expire for a given PCN-egress-
node, then: node, then:
*) If 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 is "admit", aggregate associated with the received e2e Path and (2) the
the Decision Point (i.e., PCN-ingress-node) SHOULD allow new state for the selected RSVP generic aggregated reservation,
flows to be admitted to that aggregate. The e2e Path message see [RFC4860], are "admit", the Decision Point (i.e., PCN-
is then forwarded towards destination. ingress-node) SHOULD allow the new flow to be admitted to
that RSVP generic aggregated reservation. The e2e Path
message is then forwarded towards destination.
*) If the PCN-admission-state for the same PCN aggregation o) If for the same ingress-egress-aggregated and the same RSVP
state is "block", the Aggregator using the same policy as generic aggregated reservation then (1) the PCN-admission-
mentioned above SHOULD either map the incoming e2e RSVP state and/or (2) the state for the RSVP generic aggregated
session to another ingress-egress-aggregate associated with reservation are/is "block", the flow SHOULD NOT be
the same generic aggregated RSVP session, or the flow admitted by the Aggregator and an e2e PathErr message SHOULD
SHOULD NOT be admitted and an e2e PathErr message SHOULD be be generated, using standard e2e RSVP procedures
generated, using standard e2e RSVP procedures [RFC2205], [RFC4495]. This e2e PathErr message is sent to the
[RFC4495]. originating sender of the e2e Path message, using standard
This e2e PathErr message is sent to the originating sender e2e RSVP procedures [RFC2205], [RFC4495]. A new error code
of the e2e Path message, using standard e2e RSVP procedures "PCN-domain rejects e2e reservation" MUST be augmented to
[RFC2205], [RFC4495]. A new error code "PCN-domain rejects the RSVP error codes to inform the sender that a PCN domains
e2e reservation" MUST be augmented to the RSVP error codes rejects the e2e reservation request.
to inform the sender that a PCN domains rejects the e2e
reservation request.
The way of how the PCN-admission-state is maintained is specified in The way of how the PCN-admission-state is maintained is specified in
[draft-ietf-pcn-cl-edge-behaviour-12] and [draft-ietf-pcn-cl-edge-behaviour-15] and [draft-ietf-pcn-sm-edge-
[draft-ietf-pcn-sm-edge-behaviour-09]. behaviour-12]. The way of how the RSVP generic aggregated 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 The e2e Path messages traverse zero or more PCN-interior-nodes.
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. The e2e Path
messages are simply forwarded as normal IP datagrams. 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
(deaggregating router) performs main regular [RFC4860] procedures, (Deaggregator) performs main regular [RFC4860] procedures, augmented
augmented with the following rules, see also [draft-lefaucheur-rsvp- with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]:
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 In this document it is considered that for the initiation of the new
RSVP aggregated Path message by the PCN-ingress-node (Aggregation RSVP aggregated Path message by the PCN-ingress-node (Aggregator),
Router), the same methods can be used as the ones described in the same methods can be used as the ones described in [RFC4860].
[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. The
Aggregated Path messages are simply forwarded as normal IP datagrams. 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
Deaggregating router, 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. The e2e Resv
messages are simply forwarded as normal IP datagrams. 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 In this document it is considered that for the initiation of the new
RSVP aggregated Resv message by the PCN-ingress-node (Aggregation RSVP aggregated Resv message by the PCN-ingress-node (Aggregator),
Router), the same methods can be used as the ones described in the same methods can be used as the ones described in [RFC4860]
[RFC4860] augmented with the following rules: 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
[draft-ietf-pcn-cl-edge-behaviour-12], and [draft-ietf-pcn-cl-edge-behaviour-15], and
[draft-ietf-pcn-sm-edge-behaviour-09], the PCN-egress-node MUST [draft-ietf-pcn-sm-edge-behaviour-12], the PCN-egress-node MUST
include the new PCN object that will be sent to the associated include the new PCN object that will be sent to the associated
Decision Point (i.e., PCN-ingress-node). Decision Point (i.e., PCN-ingress-node).
The PCN object is specified in this document and is used to The PCN object is specified in this document and is used for the
report of the data measured by the PCN-egress-node, for a report of the data measured by the PCN-egress-node, for a
particular ingress-egress-aggregate, see [draft-ietf-pcn-cl- particular ingress-egress-aggregate, see [draft-ietf-pcn-cl-
edge-behaviour-12], and [draft-ietf-pcn-sm-edge-behaviour-09]. edge-behaviour-15], and [draft-ietf-pcn-sm-edge-behaviour-12].
The address of the PCN-ingress-node is the one specified in the The address of the PCN-ingress-node is the one specified in the
same ingress-egress-aggregate. same ingress-egress-aggregate.
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 The Aggregated Resv messages are simply forwarded as normal IP
datagrams. datagrams.
skipping to change at page 16, line 20 skipping to change at page 16, line 41
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) the Decision Point (i.e., the PCN-ingress-node) SHOULD use the
information carried by the PCN objects as specified in information carried by the PCN objects as specified in
[draft-ietf-pcn-cl-edge-behaviour-12], [draft-ietf-pcn-cl-edge-behaviour-15], [draft-ietf-pcn-sm-edge-
[draft-ietf-pcn-sm-edge-behaviour-09]. behaviour-12]. When the Aggregator (i.e., PCN-ingress-node)
When the Aggregator (i.e., PCN-ingress-node) needs to terminate needs to terminate an amount of traffic associated to one
an amount of traffic associated to one ingress-egress-aggregate ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of
(see bullet 2 in Section 3.3.2 of [draft-ietf-pcn-cl-edge- [draft-ietf-pcn-cl-edge-behaviour-15] and [draft-ietf-pcn-sm-
behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]), then edge-behaviour-12]), then several procedures of terminating
the following procedure is followed. Based on a local policy, e2e microflows can be deployed. The default procedure of
the Aggregator SHOULD select one of the following options: terminating e2e microflows (i.e., PCN-flows) is as follows, see
e.g., [draft-ietf-pcn-cl-edge-behaviour-15]. For the same
o) for the same ingress-egress-aggregate, select a number of e2e ingress-egress-aggregate, select a number of e2e microflows
RSVP sessions to be terminated in order to decrease the to be terminated in order to decrease the total incoming amount
total incoming amount of bandwidth associated with one of bandwidth associated with one ingress-egress-aggregate by the
ingress-egress-aggregate by the amount of traffic to be amount of traffic to be terminated, see above.
terminated, see above. In this situation the same mechanisms In this situation the same mechanisms for terminating an e2e
for terminating an e2e RSVP flow can be followed as specified microflow can be followed as specified in [RFC2205].
in [RFC4495]. However, based on a local policy, the Aggregator could use
other procedures of terminating microflows.
o) for the same ingress-egress-aggregate, select a number of e2e For example, for the same ingress-egress-aggregate, select a
RSVP sessions to be terminated or to reduce their reserved number of e2e microflows to be terminated or to reduce their
bandwidth in order to decrease the total incoming amount of reserved bandwidth in order to decrease the total incoming
bandwidth associated with one ingress-egress-aggregate by the amount of bandwidth associated with one ingress-egress-aggregate
amount of traffic to be terminated, see above. In this by the amount of traffic to be terminated. In this
situation the same mechanisms for terminating an e2e RSVP situation the same mechanisms for terminating an e2e microflow
flow or reducing bandwidth associated with an e2e RSVP or reducing bandwidth associated with an e2e microflow can be
flow can be followed as specified in [RFC4495]. followed as 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 In this document it is considered that for the removal of e2e
reservations, the same methods can be used as the ones described in reservations, the same methods can be used as the ones described in
[RFC4860] and [RFC4495]. [RFC4860] and [RFC4495].
3.13. Removal of Aggregate Reservation 3.13. Removal of Aggregate Reservation
In this document it is considered that for the removal of aggregated In this document it is considered that for the removal of RSVP
reservations, the same methods can be used as the ones described in generic aggregated reservations, the same methods can be used as the
[RFC4860]. ones described in [RFC4860].
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.1.1 and 2.1.3 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 [RFC4860], 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).
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 PCN objects, see o) An aggregated Resv message MUST carry one or more C-type PCN
Section 4.1, to report the data measured by an PCN-egress-node objects, see Section 4.1, to report the data measured by an
(i.e., Deaggregator). PCN-egress-node (i.e., Deaggregator).
o) As described in [draft-ietf-pcn-cl-edge-behaviour-12], o) As described in [draft-ietf-pcn-cl-edge-behaviour-15],
[draft-ietf-pcn-signaling-requirements-08], PCN reports [draft-ietf-pcn-signaling-requirements-08], PCN reports
from the PCN-egress-node (Deaggregator) to the decision point may from the PCN-egress-node (Deaggregator) to the decision point may
contain flow identifiers for individual flows within an contain flow identifiers for individual flows within an
ingress-egress-aggregate that have recently experienced ingress-egress-aggregate that have recently experienced
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)
Open issue:
==========
There are at least two possible options of carrying the
PCN objects of C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs:
o) Option 1: The PCN objects of C-Type:
RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by the
aggregated Resv message together with the other PCN object
C-Types. The advantage of this object is that no additional
message needs to be supported by this signaling protocol. The
drawback of this option is that the PCN objects of C-Type: RSVP-
AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs
can become larger than the maximum transmission unit (MTU) along
a path to the Aggregator.
o) Option 2: The PCN objects of C-Type:
RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by NOTIFY
messages, see [RFC3473]. In particular, the NOTIFY
<flow descriptor list> field could carry the flow IDs. The
advantage of this option is that the total list of the flow IDs
that need to be sent to the Aggregator can be divided in smaller
sets. Each of these sets can be then carried by one NOTIFY
message. The number of flow IDs that are included in such a set
MUST be such that the length of any NOTIFY message will not
become larger than the maximum transmission unit (MTU) along a
path to the Aggregator. The main disadvantage is the signaling
protocol needs to use an additional message type. If this option
is chosen then the format of the PCN objects of
C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs may need modifications. The
same holds for the procedures on handling the NOTIFY message by
the Interior nodes and by the Aggregator.
4.1 PCN object 4.1 PCN object
The PCN object reports data measured by an PCN-egress-node. The PCN object reports data measured by an PCN-egress-node. PCN
objects are defined for different PCN edge behavior drafts. This
PCN objects are defined for different PCN edge behavior drafts. This
document defines several types of PCN objects. document defines several 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | rate of not marked PCN-traffic (NM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of PCN-marked PCN-traffic (PM-rate) | | rate of PCN-marked PCN-traffic (PM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 20, line 46 skipping to change at page 20, line 35
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | rate of not marked PCN-traffic (NM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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
[draft-ietf-pcn-signaling-requirements-08.txt], [draft-ietf-pcn-cl- [draft-ietf-pcn-signaling-requirements-08.txt], [draft-ietf-pcn-cl-
edge-behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]: edge-behaviour-15] and [draft-ietf-pcn-sm-edge-behaviour-12]:
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;
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;
skipping to change at page 24, line 23 skipping to change at page 23, line 26
apply also to this document. apply also to this document.
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.
Error Value for "PCN-domain rejects e2e reservation "= To be
allocated by IANA
7. Acknowledgments 7. Acknowledgments
We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 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 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 initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would
like to thank Tom Taylor, Francois Le Faucheur and James Polk for the like to thank Tom Taylor, Philip Eardley, Michael Menth,
comments provided on the 00 version of this draft. Toby Moncaster, Francois Le Faucheur and James Polk for the provided
comments.
8. Normative References 8. Normative References
[draft-ietf-pcn-cl-edge-behaviour-12] T. Taylor, A, Charny, F. Huang, [draft-ietf-pcn-cl-edge-behaviour-15] T. Taylor, A, Charny, F. Huang,
G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the
Controlled Load (CL) Mode of Operation (Work in progress)", February Controlled Load (CL) Mode of Operation (Work in progress)", May
2012. 2012.
[draft-ietf-pcn-sm-edge-behaviour-09] A. Charny, J. Zhang, [draft-ietf-pcn-sm-edge-behaviour-12] A. Charny, J. Zhang,
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour
for the Single Marking (SM) Mode of Operation (Work in progress)", for the Single Marking (SM) Mode of Operation (Work in progress)",
February 2012. April 2012.
[draft-ietf-pcn-signaling-requirements-08] G. Karagiannis, T. Taylor, [draft-ietf-pcn-signaling-requirements-08] G. Karagiannis, T. Taylor,
K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-)
Congestion Information in a DiffServ Domain(Work in progress)", Congestion Information in a DiffServ Domain(Work in progress)",
February 2012. February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol
(RSVP)- Functional Specification", RFC 2205, September 1997. (RSVP)- Functional Specification", RFC 2205, September 1997.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le
Faucheur, "Per Hop Behavior Identification Codes", Faucheur, "Per Hop Behavior Identification Codes",
RFC 3140, June 2001. RFC 3140, June 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation
Protocol (RSVP) Extension for the Reduction of Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006. Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.
Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP)
Reservations", RFC4860, May 2007. Reservations", RFC4860, May 2007.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes",
RFC 5670, November 2009. RFC 5670, November 2009.
skipping to change at page 26, line 17 skipping to change at page 25, line 8
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.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
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
EMail: g.karagiannis@utwente.nl EMail: g.karagiannis@utwente.nl
Anurag Bhargava Anurag Bhargava
 End of changes. 79 change blocks. 
306 lines changed or deleted 302 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/