draft-ietf-tsvwg-rsvp-pcn-09.txt   draft-ietf-tsvwg-rsvp-pcn-10.txt 
Internet Engineering Task Force Georgios Karagiannis Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente Internet-Draft Huawei Technologies
Intended status: Experimental Anurag Bhargava Intended status: Experimental Anurag Bhargava
Expires: February 11, 2015 Cisco Systems, Inc. Expires: March 14, 2015 Cisco Systems, Inc.
August 11, 2014 September 14, 2014
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-09 draft-ietf-tsvwg-rsvp-pcn-10
Abstract Abstract
This document specifies extensions to Generic Aggregated RSVP This document specifies extensions to Generic Aggregated RSVP
RFC 4860 for support of the PCN Controlled Load (CL) and Single RFC 4860 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 February 11, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4 1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Organization of This Document . . . . . . . . . . . . . . . . 11 1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11
2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11 2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.2. PCN Marking and encoding and transport of pre-congestion 2.2. PCN Marking and encoding and transport of pre-congestion
Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Traffic Classification Within The Aggregation Region . . . . . . 13 2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13 2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13 2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13
2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14 2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 17 skipping to change at page 3, line 17
3.12. Handling of Aggregated Resv Message by Aggregating Router . . 18 3.12. Handling of Aggregated Resv Message by Aggregating Router . . 18
3.13. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19 3.13. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19
3.14. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19 3.14. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19
3.15. Handling of Data On Reserved E2E Flow by Aggregating Router . 19 3.15. Handling of Data On Reserved E2E Flow by Aggregating Router . 19
3.16. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19 3.16. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19
3.17. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19 3.17. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19
3.18. PCN based Flow Termination . . . . . . . . . . . . . . . . . 19 3.18. PCN based Flow Termination . . . . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24
9. Informative References . . . . . . . . . . . . . . . . . . . . . 25 9. Informative References . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 25 10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 26
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
1.1 Objective 1.1 Objective
Pre-Congestion Notification (PCN) can support the quality of service Pre-Congestion Notification (PCN) can support the quality of service
(QoS) of inelastic flows within a Diffserv domain in a simple, (QoS) of inelastic flows within a Diffserv domain in a simple,
scalable, and robust fashion. Two mechanisms are used: admission scalable, and robust fashion. Two mechanisms are used: admission
control and flow termination. Admission control is used to decide control and flow termination. Admission control is used to decide
whether to admit or block a new flow request, while flow termination whether to admit or block a new flow request, while flow termination
is used in abnormal circumstances to decide whether to terminate some is used in abnormal circumstances to decide whether to terminate some
skipping to change at page 4, line 51 skipping to change at page 4, line 51
PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However, PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However,
since (1) both PCN-egress-node and PCN-ingress-nodes are located on since (1) both PCN-egress-node and PCN-ingress-nodes are located on
the data path and (2) the admission control procedure needs to be the data path and (2) the admission control procedure needs to be
done at PCN-egress-node, a signaling protocol that follows the same done at PCN-egress-node, a signaling protocol that follows the same
path as the data path, like RSVP (Resource Reservation Protocol), is path as the data path, like RSVP (Resource Reservation Protocol), is
more suited for this purpose. In particular, this document specifies more suited for this purpose. In particular, this document specifies
extensions to Generic Aggregated RSVP [RFC4860] for support of the extensions to Generic Aggregated RSVP [RFC4860] for support of the
PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over
a Diffserv cloud using Pre-Congestion Notification. a Diffserv cloud using Pre-Congestion Notification.
This draft is intended to be published as Experimental in order to:
o) validate industry interest by allowing implementation and
deployment
o) gather operational experience, in particular around dynamic
interactions of RSVP signaling and PCN notification and
corresponding levels of performance.
1.2 Overview and Motivation 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
skipping to change at page 5, line 34 skipping to change at page 5, line 42
invoked by the DSCP. The primary benefit of Diffserv is its invoked by the DSCP. The primary benefit of Diffserv is its
scalability, since the need for per-flow state and per-flow scalability, since the need for per-flow state and per-flow
processing, is eliminated. processing, is eliminated.
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 (RBAC), Diffserv [RFC2998] including resource-based admission control (RBAC),
PBAC, assistance in traffic identification/classification, and PBAC, assistance in traffic identification/classification, and
traffic conditioning. Intserv over Diffserv can operate over a traffic conditioning. Intserv over Diffserv can operate over a
statically provisioned Diffserv region or RSVP aware. When it is RSVP statically provisioned or a RSVP aware Diffserv region. When it is
aware, several mechanisms may be used to support dynamic provisioning RSVP aware, several mechanisms may be used to support dynamic
and topology-aware admission control, including aggregate RSVP provisioning and topology-aware admission control, including
reservations, per-flow RSVP, or a bandwidth broker. [RFC3175] aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker.
specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to- [RFC3175] specifies aggregation of Resource ReSerVation Protocol
end reservations over aggregate RSVP reservations. In [RFC3175] the (RSVP) end-to-end reservations over aggregate RSVP reservations. In
RSVP generic aggregated reservation is characterized by a RSVP [RFC3175] the RSVP generic aggregated reservation is characterized by
SESSION object using the 3-tuple <source IP address, destination IP a RSVP SESSION object using the 3-tuple <source IP address,
address, Diffserv Code Point>. 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 [SIG-NESTED], IP address to a given destination IP address, see [SIG-NESTED],
[RFC4860]. For example, multiple generic aggregate reservations [RFC4860]. 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, it 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.
[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).
skipping to change at page 7, line 51 skipping to change at page 8, line 7
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
(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. It is document, it is also the PCN-ingress-node. It is
important to notice that in the context of this important to notice that in the context of this
document the Aggregator MUST be able to determine document the Aggregator must be able to determine
the Deaggregator using the procedures specified in the Deaggregator using the procedures specified in
Section 4 of [RFC4860] and in Section 1.4.2 of Section 4 of [RFC4860] and in Section 1.4.2 of
[RFC3175]. [RFC3175].
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
skipping to change at page 9, line 4 skipping to change at page 9, line 8
E2E microflow a microflow where its associated packets are being E2E microflow a microflow where its associated packets are being
forwarded on an E2E path. forwarded on an E2E path.
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
An identifier used in the SESSION that remains An identifier used in the SESSION that remains
constant over the life of the generic aggregate constant over the life of the generic aggregate
reservation. The length of this identifier is 32- reservation. The length of this identifier 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. IPv6 addresses are used.
A sender(or Aggregator) that wishes to narrow the A sender(or Aggregator) that wishes to narrow the
scope of a SESSION to the sender-receiver pair (or scope of a SESSION to the sender-receiver pair (or
Aggregator-Deaggregator pair) SHOULD place its IPv4 Aggregator-Deaggregator pair) should place its IPv4
or IPv6 address here as a network unique or IPv6 address here as a network unique
identifier. A sender (or Aggregator) that wishes to identifier. A sender (or Aggregator) that wishes to
use a common session with other senders (or use a common session with other senders (or
Aggregators) in order to use a shared reservation Aggregators) in order to use a shared reservation
across senders (or Aggregators) MUST set this field across senders (or Aggregators) must set this field
to all zeros. In this document, the Extended to all zeros. In this document, the Extended
vDstPort SHOULD contain the IPv4 or IPv6 address of vDstPort should contain the IPv4 or IPv6 address of
the Aggregator. the Aggregator.
ETM-rate ETM-rate
The rate of excess-traffic-marked PCN-traffic The rate of excess-traffic-marked PCN-traffic
received at a PCN-egress-node for a given ingress- received at a PCN-egress-node for a given ingress-
egress-aggregate in octets per second. egress-aggregate in octets per second.
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
skipping to change at page 9, line 45 skipping to change at page 9, line 48
Microflow: a single instance of an application-to-application Microflow: a single instance of an application-to-application
(from [RFC2474]) flow of packets which is identified by source (from [RFC2474]) flow of packets which is identified by source
address, destination address, protocol id, and address, destination address, protocol id, and
source port, destination port (where applicable). source port, destination port (where applicable).
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 within the domain; includes the PCN-
the PCN-egress-nodes, which measure these egress-nodes, which measure these PCN-marks, and the
PCN-marks, and the PCN-ingress-nodes. PCN-ingress-nodes.
PCN-boundary-node: a PCN-node that connects one PCN-domain to a node PCN-boundary-node: a PCN-node that connects one PCN-domain to a node
either in another PCN-domain or in a non-PCN-domain. either in another PCN-domain or in a non-PCN-domain.
PCN-interior-node: a node in a PCN-domain that is not a PCN- PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node. boundary-node.
PCN-node: a PCN-boundary-node or a PCN-interior-node. PCN-node: a PCN-boundary-node or a PCN-interior-node.
PCN-egress-node: a PCN-boundary-node in its role in handling PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain. In this traffic as it leaves a PCN-domain. In this
document the PCN-egress-node operates also as a document the PCN-egress-node operates also as a
Decision Point and Deaggregator. Decision Point and Deaggregator.
PCN-ingress-node: a PCN-boundary-node in its role in handling PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain. In this traffic as it enters a PCN-domain. In this
document the PCN-ingress-node operates also as a document the PCN-ingress-node operates also as a
Aggregator. Aggregator.
PCN-traffic, PCN-traffic,
skipping to change at page 10, line 48 skipping to change at page 10, line 50
PCN-sent-rate PCN-sent-rate
The rate of PCN-traffic received at a PCN-ingress- The rate of PCN-traffic received at a PCN-ingress-
node and destined for a given ingress-egress- node and destined for a given ingress-egress-
aggregate in octets per second. aggregate in octets per second.
PHB-ID (Per Hop Behavior Identification Code) PHB-ID (Per Hop Behavior Identification Code)
A 16-bit field containing the Per Hop Behavior A 16-bit field containing the Per Hop Behavior
Identification Code of the PHB, or of the set of Identification Code of the PHB, or of the set of
PHBs, from which Diffserv resources PHBs, from which Diffserv resources
are to be reserved. This field MUST be encoded as are to be reserved. This field must be encoded as
specified in Section 2 of [RFC3140]. specified in Section 2 of [RFC3140].
RSVP generic aggregated reservation: an RSVP reservation that is RSVP generic aggregated reservation: an RSVP reservation that is
identified by using the RSVP SESSION object identified by using the RSVP SESSION object
for generic RSVP aggregated reservation. This RSVP for generic RSVP aggregated reservation. This RSVP
SESSION object is based on the RSVP SESSION object SESSION object is based on the RSVP SESSION object
specified in [RFC4860] augmented with the following specified in [RFC4860] augmented with the following
information: information:
o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be o) the IPv4 DestAddress, IPv6 DestAddress should be
set to the IPv4 or IPv6 destination addresses, set to the IPv4 or IPv6 destination addresses,
respectively, of the Deaggregator (PCN-egress- respectively, of the Deaggregator (PCN-egress-
node) node)
o) PHB-ID (Per Hop Behavior Identification Code) o) PHB-ID (Per Hop Behavior Identification Code)
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)
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that A 16-bit identifier used in the SESSION that
remains constant over the life of the generic remains constant over the life of the generic
aggregate reservation. aggregate reservation.
1.4. Organization of This Document 1.4. Organization of This Document
skipping to change at page 23, line 39 skipping to change at page 23, line 39
format is a 32-bit IEEE floating point number; The PCN-sent-rate format is a 32-bit IEEE floating point number; The PCN-sent-rate
is specified in [RFC6661] and [RFC6662] and it represents the is specified in [RFC6661] and [RFC6662] and it represents the
estimate of the rate at which the PCN-ingress-node (Aggregator) estimate of the rate at which the PCN-ingress-node (Aggregator)
is receiving PCN-traffic that is destined for the given is receiving PCN-traffic that is destined for the given
ingress-egress-aggregate. ingress-egress-aggregate.
5. Security Considerations 5. Security Considerations
The same security considerations specified in [RFC2205], [RFC4230], The same security considerations specified in [RFC2205], [RFC4230],
[RFC4860], [RFC5559] and [RFC6411]. [RFC4860], [RFC5559] and [RFC6411].
In particular, the security considerations within the PCN domain come
from the Trust Assumption Section 6.3.1, of [RFC5559] i.e., that all
PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering
and PCN-marking.
In the PCN domain environments addressed by this document, Generic
Aggregate Resource ReSerVation Protocol (RSVP)messages specified in
[RFC4860] are used for support of the PCN Controlled Load (CL) and
Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Similar, to [RFC4860], [RFC2747] and
[RFC3097] may be used to protect RSVP message integrity hop-
by hop and provide node authentication as well as replay protection,
thereby protecting against corruption and spoofing of RSVP messages
and PCN feedback.
Based on these assumptions, it is considered that this document is
NOT introducing any additional security concerns/issues compared to
[RFC5559] and/or [RFC4860].
6. IANA Considerations 6. IANA Considerations
IANA has modified the RSVP parameters registry, 'Class Names, IANA has modified the RSVP parameters registry, 'Class Names,
Class Numbers, and Class Types' subregistry, to add a new Class Numbers, and Class Types' subregistry, to add a new
Class Number and assign 4 new C-Types under this new Class Class Number and assign 4 new C-Types under this new Class
Number, as described below, see Section 4.1: Number, as described below, see Section 4.1:
Class Class
Number Class Name Reference Number Class Name Reference
skipping to change at page 24, line 14 skipping to change at page 24, line 34
reference for the above 5 items to that published RFC (and the RFC reference for the above 5 items to that published RFC (and the RFC
Editor should remove this sentence). Editor should remove this sentence).
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 Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor,
Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott
Bradner and Lixia Zhang for the provided comments. In particular, we Bradner, Lixia Zhang and Robert Sparks for the provided comments. In
would like to thank Francois Le Faucheur for contributing in addition particular, we would like to thank Francois Le Faucheur for
to comments also to a significant amount of text. contributing in addition to comments also to a significant amount of
text.
8. Normative References 8. Normative References
[RFC6661] T. Taylor, A, Charny, F. Huang, [RFC6661] 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", July Controlled Load (CL) Mode of Operation", July
2012. 2012.
[RFC6662] A. Charny, J. Zhang, [RFC6662] A. Charny, J. Zhang,
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour
skipping to change at page 24, line 58 skipping to change at page 25, line 25
[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.
[RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information", RFC 6660, Encoding and Transport of Pre-Congestion Information", RFC 6660,
July 2012. July 2012.
9. Informative References 9. Informative References
[draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A.,
Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions
for Admission Control over Diffserv using Pre-congestion for Admission Control over Diffserv using Pre-congestion
skipping to change at page 25, line 34 skipping to change at page 25, line 56
Service, September 1997 Service, September 1997
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS Field) in the "Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998. IPv4 and IPv6 Headers", RFC 2474, December 1998.
[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.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for
Policy-based Admission Control", January 2000.
[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.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication
-- Updated Message Type Value", RFC 3097, April 2001.
[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",
RFC 4230, December 2005. 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 [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of
Keying Methods for RSVP Security", RFC 6411, October 2011. 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, July 2007. Virtual Private Network", Work in Progress, July 2007.
[RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for
Policy-based Admission Control", January 2000.
10. Appendix A: Example Signaling Flow 10. Appendix A: Example Signaling Flow
This appendix is based on the appendix provided in [RFC4860]. In This appendix is based on the appendix provided in [RFC4860]. In
particular, it provides an example signaling flow of the particular, it provides an example signaling flow of the
specification detailed in Section 3 and 4. specification detailed in Section 3 and 4.
This signaling flow assumes an environment where E2E reservations are This signaling flow assumes an environment where E2E reservations are
aggregated over generic aggregate RSVP reservations and applied over aggregated over generic aggregate RSVP reservations and applied over
a PCN domain. In particular the Aggregator (PCN-ingress-node) and a PCN domain. In particular the Aggregator (PCN-ingress-node) and
Deaggregator (PCN-egress-node) are located at the boundaries of the Deaggregator (PCN-egress-node) are located at the boundaries of the
PCN domain. The PCN-interior-nodes are located within the PCN-domain, PCN domain. The PCN-interior-nodes are located within the PCN-domain,
between the PCN-boundary nodes, but are not shown in this Figure. It between the PCN-boundary nodes, but are not shown in this Figure. It
illustrates a possible RSVP message flow that could take place in the illustrates a possible RSVP message flow that could take place in the
successful establishment of a unicast E2E reservation that is the successful establishment of a unicast E2E reservation that is the
first between a given pair of Aggregator/Deaggregator. first between a given pair of Aggregator/Deaggregator.
skipping to change at page 28, line 25 skipping to change at page 29, line 14
object conveying the selected mapping onto GApcn (and hence onto object conveying the selected mapping onto GApcn (and hence onto
the PCN PHB-ID). the PCN PHB-ID).
(9) The Aggregator records the mapping of the E2E Resv onto GApcn (9) The Aggregator records the mapping of the E2E Resv onto GApcn
(and onto the PCN PHB-ID). The Aggregator removes the SOI object (and onto the PCN PHB-ID). The Aggregator removes the SOI object
and forwards the E2E Resv towards the sender. and forwards the E2E Resv towards the sender.
11. Authors' Address 11. Authors' Address
Georgios Karagiannis Georgios Karagiannis
University of Twente Huawei Technologies
P.O. Box 217 Hansaallee 205,
7500 AE Enschede, 40549 Dusseldorf,
The Netherlands Germany
EMail: g.karagiannis@utwente.nl Email: Georgios.Karagiannis@huawei.com
Anurag Bhargava Anurag Bhargava
Cisco Systems, Inc. Cisco Systems, Inc.
7100-9 Kit Creek Road 7100-9 Kit Creek Road
PO Box 14987 PO Box 14987
RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987
USA USA
Email: anuragb@cisco.com Email: anuragb@cisco.com
 End of changes. 29 change blocks. 
45 lines changed or deleted 77 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/