draft-ietf-tsvwg-rsvp-pcn-00.txt   draft-ietf-tsvwg-rsvp-pcn-01.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: April 08, 2012 Cisco Systems, Inc. Expires: September 10, 2012 Cisco Systems, Inc.
October 08, 2011 March 10, 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-00 draft-ietf-tsvwg-rsvp-pcn-01
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 April 08, 2012. This Internet-Draft will expire on September 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of RSVP extensions and Operations . . . . . . . . . . . . . 2. Overview of RSVP extensions and Operations . . . . . . . . . . . . 9
2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . . . 2.1 Overview of RSVP Aggregation Procedures in PCN domains . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2. Traffic Classification Within The Aggregation Region . . . . . . 2.1.2. Traffic Classification Within The Aggregation Region . . . . 11
2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 2.1.3. Deaggregator (PCN-egress-node) Determination . . . . . . . . 11
2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 2.1.4. Mapping E2E Reservations Onto Aggregate Reservations . . . . 11
2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 2.1.5. Size of Aggregate Reservations . . . . . . . . . . . . . . . 12
2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 2.1.6. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . 12
2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . 2.1.7. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . 12
2.1.8. Inter-domain Routes 2.1.8. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . 12
2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . . 2.1.9. Reservations for Multicast Sessions . . . . . . . . . . . . . 12
2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 2.1.10. Multi-level Aggregation . . . . . . . . . . . . . . . . . . 12
2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . 2.1.11. Reliability Issues . . . . . . . . . . . . . . . . . . . . . 12
2.1.12. Message Integrity and Node Authentication . . . . . . . . . . 2.1.12. Message Integrity and Node Authentication . . . . . . . . . 12
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . . . 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) . . . . . . . . . . . . . . . . . . . . . . . (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . . . 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) . . . . . . . . . . . . . . . . . . . . . . (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 14
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) . . . . . . . . . . . . . . . . . . . . . 14
3.5. Handling Of new Aggregate Path Message By Interior Routers . . . . 3.5. Handling Of new Aggregate Path Message By Interior Routers . . 15
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . . . 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 15
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . . . 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 15
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router . 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 . . . . . . 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 16
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . . 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 16
3.11. Handling of Aggregated Resv Message by Aggregating Router . . . . 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 16
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . . 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 17
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . .
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . . .
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . . .
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . .
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Normative References . . . . . . . . . . . . . . . . . . . . . . . .
9. Informative References . . . . . . . . . . . . . . . . . . . . . . .
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . .
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 17
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 17
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24
9. Informative References . . . . . . . . . . . . . . . . . . . . . 25
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
below the rate of the link thus providing notification to boundary below the rate of the link thus providing notification to boundary
nodes about overloads before any congestion occurs (hence "pre- nodes about overloads before any congestion occurs (hence "pre-
congestion" notification). congestion" notification).
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], [draft-ietf-pcn-cl-edge-behaviour-09], For more details see[RFC5559], [draft-ietf-pcn-cl-edge-behaviour-12],
[draft-ietf-pcn-sm-edge-behaviour-06]. In this document it is [draft-ietf-pcn-sm-edge-behaviour-09]. In this document it is
Considered that the decision point is collocated with the PCN- Considered that the decision 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-06.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 behaviours as specified in [draft-ietf-pcn-cl-edge- of PCN edge behaviors as specified in [draft-ietf-pcn-cl-edge-
behaviour-09] and [draft-ietf-pcn-sm-edge-behaviour-06]. Moreover, behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]. 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 directly by end-systems attached to a Diffserv be used end-to-end 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-09], [draft-ietf-pcn-sm- [RFC5696],[draft-ietf-pcn-cl-edge-behaviour-12], [draft-ietf-pcn-sm-
edge-behaviour-06]. Furthermore, the PCN-boundary-nodes MUST support edge-behaviour-09]. 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-09], [RFC5670], [draft-ietf-pcn-cl-edge-behaviour-12],
[draft-ietf-pcn-sm-edge-behaviour-06]. [draft-ietf-pcn-sm-edge-behaviour-09].
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-09], and [draft-ietf-pcn-sm-edge-behaviour-06] are provided behaviour-12], and [draft-ietf-pcn-sm-edge-behaviour-09] 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
skipping to change at page 8, line 18 skipping to change at page 8, line 18
traffic as it leaves a PCN-domain. traffic as it leaves a PCN-domain.
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
Decision Point and aggregator. Decision Point and aggregator.
PCN-traffic, PCN-traffic,
PCN-packets, PCN-packets,
PCN-BA: a PCN-domain carries traffic of different Diffserv PCN-BA: a PCN-domain carries traffic of different Diffserv
behaviour 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.
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 microflow (as defined in [RFC2474]) or some
skipping to change at page 11, line 44 skipping to change at page 11, line 44
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 belonging to an PCN aggregated session can be
classified only at the PCN-boundary-nodes using the combination of classified only at the PCN-boundary-nodes using the combination of
(1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP
addresses of the specific pair of PCN-boundary-nodes used by a addresses of the specific pair of PCN-boundary-nodes used by a
ingress-egress-aggregate. 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-09] and [draft-ietf-pcn-sm-edge-behaviour-06]. pcn-cl-edge-behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09].
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
skipping to change at page 13, line 27 skipping to change at page 13, line 27
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 onto an existing RSVP generic aggregation
reservation state (i.e., PCN ingress-egress-aggregate). reservation state (i.e., PCN ingress-egress-aggregate).
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 RSVP flow to be admitted to that ingress-egress-
aggregate. This procedure is defined in detail in: aggregate. This procedure is defined in detail in:
[draft-ietf-pcn-cl-edge-behaviour-09] and [draft-ietf-pcn-cl-edge-behaviour-12] and
[draft-ietf-pcn-sm-edge-behaviour-06]. [draft-ietf-pcn-sm-edge-behaviour-09].
Depending on a local policy the Aggregator SHOULD decide Depending on a local policy the Aggregator SHOULD decide
whether this situation is considered of being an error, or whether this situation is considered of being an error, or
whether the e2e reservation session SHOULD be mapped to another whether the e2e reservation session SHOULD be mapped to another
ingress-egress-aggregate maintained by the same RSVP SESSION ingress-egress-aggregate maintained by the same RSVP SESSION
for aggregated reservations. for aggregated reservations.
If the Aggregator is not able to map the requesting e2e RSVP If the Aggregator is not able to map the requesting e2e RSVP
session into another ingress-egress-aggregate, then the session into another ingress-egress-aggregate, then the
Aggregator SHOULD NOT admit the e2e RSVP session and it SHOULD Aggregator SHOULD NOT admit the e2e RSVP session and it SHOULD
skipping to change at page 14, line 21 skipping to change at page 14, line 21
generated, using standard e2e RSVP procedures [RFC2205], generated, using standard e2e RSVP procedures [RFC2205],
[RFC4495]. [RFC4495].
This e2e PathErr message is sent to the originating sender This e2e PathErr message is sent to the originating sender
of the e2e Path message, using standard e2e RSVP procedures of the e2e Path message, using standard e2e RSVP procedures
[RFC2205], [RFC4495]. A new error code "PCN-domain rejects [RFC2205], [RFC4495]. A new error code "PCN-domain rejects
e2e reservation" MUST be augmented to the RSVP error codes e2e reservation" MUST be augmented to the RSVP error codes
to inform the sender that a PCN domains rejects the e2e to inform the sender that a PCN domains rejects the e2e
reservation request. 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-09] and [draft-ietf-pcn-cl-edge-behaviour-12] and
[draft-ietf-pcn-sm-edge-behaviour-06]. [draft-ietf-pcn-sm-edge-behaviour-09].
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. The
PCN-interior-nodes receive the e2e Path message on an interior 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)
skipping to change at page 15, line 34 skipping to change at page 15, line 34
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 (Aggregation
Router), the same methods can be used as the ones described in Router), the same methods can be used as the ones described in
[RFC4860] augmented with the following rules: [RFC4860] augmented with the following rules:
o) At the end of each t-meas measurement interval, or less o) At the end of each t-meas measurement interval, or less
frequently if "optional report suppression" is activated, see frequently if "optional report suppression" is activated, see
[draft-ietf-pcn-cl-edge-behaviour-09], and [draft-ietf-pcn-cl-edge-behaviour-12], and
[draft-ietf-pcn-sm-edge-behaviour-06], the PCN-egress-node MUST [draft-ietf-pcn-sm-edge-behaviour-09], 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 to
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-09], and [draft-ietf-pcn-sm-edge-behaviour-06]. edge-behaviour-12], and [draft-ietf-pcn-sm-edge-behaviour-09].
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 19 skipping to change at page 16, line 19
aggregation [RFC4860] procedures are used. aggregation [RFC4860] procedures are used.
3.11. Handling of Aggregated Resv Message by Aggregating Router 3.11. Handling of Aggregated Resv Message by Aggregating Router
When the Aggregated Resv message arrives at the interior interface of When the Aggregated Resv message arrives at the interior interface of
the Aggregating router, i.e., PCN-ingress-node, then standard RSVP the Aggregating router, i.e., PCN-ingress-node, then standard RSVP
aggregation [RFC4860] procedures are used, augmented with the aggregation [RFC4860] procedures are used, augmented with the
following rules: following rules:
o) the Decision Point (i.e., the PCN-ingress-node) SHOULD use the o) the Decision Point (i.e., the PCN-ingress-node) SHOULD use the
information carried by the PCN object as specified in information carried by the PCN objects as specified in
[draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-cl-edge-behaviour-12],
[draft-ietf-pcn-sm-edge-behaviour-06]. [draft-ietf-pcn-sm-edge-behaviour-09].
When the Aggregator (i.e., PCN-ingress-node) needs to terminate When the Aggregator (i.e., PCN-ingress-node) needs to terminate
an amount of traffic associated to one ingress-egress-aggregate an amount of traffic associated to one ingress-egress-aggregate
(see bullet 2 in Section 3.3.2 of [draft-ietf-pcn-cl-edge- (see bullet 2 in Section 3.3.2 of [draft-ietf-pcn-cl-edge-
behaviour-09] and [draft-ietf-pcn-sm-edge-behaviour-06]), then behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]), then
the following procedure is followed. Based on a local policy, the following procedure is followed. Based on a local policy,
the Aggregator SHOULD select one of the following options: the Aggregator SHOULD select one of the following options:
o) for the same ingress-egress-aggregate, select a number of e2e o) for the same ingress-egress-aggregate, select a number of e2e
RSVP sessions to be terminated in order to decrease the RSVP sessions to be terminated in order to decrease the
total incoming amount of bandwidth associated with one total incoming amount of bandwidth associated with one
ingress-egress-aggregate by the amount of traffic to be ingress-egress-aggregate by the amount of traffic to be
terminated, see above. In this situation the same mechanisms terminated, see above. In this situation the same mechanisms
for terminating an e2e RSVP flow can be followed as specified for terminating an e2e RSVP flow can be followed as specified
in [RFC4495]. in [RFC4495].
skipping to change at page 17, line 37 skipping to change at page 17, line 37
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 a PCN object to report o) An aggregated Resv message MUST carry one or more PCN objects, see
the data measured by an PCN-egress-node (i.e., Deaggregator). Section 4.1, to report the data measured by an PCN-egress-node
(i.e., Deaggregator).
o) As described in [draft-ietf-pcn-cl-edge-behaviour-12],
[draft-ietf-pcn-signaling-requirements-08], PCN reports
from the PCN-egress-node (Deaggregator) to the decision point may
contain flow identifiers for individual flows within an
ingress-egress-aggregate that have recently experienced
excess-marking. Hence, the PCN report messages used by the PCN CL
edge behavior MUST be capable of carrying sequences of octet
strings constituting such identifiers. When the PCN CL edge
behavior is used, the individual flow identifiers need to be
included in specific PCN objects, see Section 4.1
(C-Type = RSVP-AGGREGATE-IPv4-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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Congestion-Level-Estimate |
+-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) Single Marking (SM) PCN object, when IPv6 addresses are used: o) Single Marking (SM) PCN object, when IPv6 addresses are used:
Class = PCN Class = PCN
C-Type = RSVP-AGGREGATE-IPv6-PCN-SM C-Type = RSVP-AGGREGATE-IPv6-PCN-SM
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 18, line 37 skipping to change at page 19, line 35
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-egress-node Address (16 bytes) + + IPv6 PCN-egress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Congestion-Level-Estimate |
+-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) Controlled (CL) PCN object, IPv4 addresses are used: o) Controlled (CL) PCN object, IPv4 addresses are used:
Class = PCN Class = PCN
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL C-Type = RSVP-AGGREGATE-IPv4-PCN-CL
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Congestion-Level-Estimate |
+-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) Controlled (CL) PCN object, IPv6 addresses are used: o) Controlled (CL) PCN object, IPv6 addresses are used:
Class = PCN Class = PCN
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL C-Type = RSVP-AGGREGATE-IPv6-PCN-CL
skipping to change at page 19, line 39 skipping to change at page 20, line 37
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-egress-node Address (16 bytes) + + IPv6 PCN-egress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Congestion-Level-Estimate |
+-------------+-------------+-------------+-------------+
| 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-06.txt], [draft-ietf-pcn-cl- [draft-ietf-pcn-signaling-requirements-08.txt], [draft-ietf-pcn-cl-
edge-behaviour-09] and [draft-ietf-pcn-sm-edge-behaviour-06]: edge-behaviour-12] and [draft-ietf-pcn-sm-edge-behaviour-09]:
o the IPv4 or IPv6 address of the PCN-ingress-node and the 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;
o congestion-level-estimate, which is a number between zero and
one; its format is a 32-bit IEEE floating point number;
o rate of threshold-marked PCN traffic (ThM-rate) in o rate of threshold-marked PCN traffic (ThM-rate) in
octets/second; its format is a 32-bit IEEE floating point number; octets/second; its format is a 32-bit IEEE floating point number;
o rate of excess-traffic-marked traffic (ETM-rate) in o rate of excess-traffic-marked traffic (ETM-rate) in
octets/second; its format is a 32-bit IEEE floating point number; octets/second; its format is a 32-bit IEEE floating point number;
o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used:
Class = PCN
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ +
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o) Length (1 byte): the length of the
RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs object in units of 16 bytes.
This field is used to specify the number of IPv4 flow IDs
carried by this object. Each flow ID is represented by the
combination of each subsequent 5 tuple:
Source address, Destination address, Source Port,
Destination Port and Protocol number.
If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is
empty.
o) Source address (4 bytes): The IPv4 source address.
o) Destination address (4 bytes): The IPv4 destination address.
o) Protocol (1 byte): The IP protocol number. It refers to the
true upper layer protocol carried by the packets.
o) Source Port (2 bytes): contains the source port number.
o) Destination Port (2 bytes): contains the destination port
number.
o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used:
Class = PCN
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ +
| |
| Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o) Length (1 byte): the length of the
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object in units of 40 bytes.
This field is used to specify the number of flow IDs carried by
this object. Each flow ID is represented by the combination of
each subsequent 5 tuple fields:
Source address, Destination address, Source Port,
Destination Port and Protocol number.
If Length is 0 then the RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object
is empty.
o) Source address (16 bytes): The IPv6 source address.
o) Destination address (16 bytes): The IPv6 destination address.
o) Protocol (1 byte): The IP protocol number. It refers to the
true upper layer protocol carried by the packets.
o) Source Port (2 bytes): contains the source port number.
o) Destination Port (2 bytes): contains the destination port
number.
5. Security Considerations 5. Security Considerations
The same security considerations specified in [RFC4860] and [RFC5559] The same security considerations specified in [RFC4860] and [RFC5559]
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.
skipping to change at page 20, line 46 skipping to change at page 24, line 36
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, Francois Le Faucheur and James Polk for the
comments provided on the 00 version of this draft. comments provided on the 00 version of this draft.
8. Normative References 8. Normative References
[draft-ietf-pcn-cl-edge-behaviour-09] T. Taylor, A, Charny, F. Huang, [draft-ietf-pcn-cl-edge-behaviour-12] 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)", June Controlled Load (CL) Mode of Operation (Work in progress)", February
2011. 2012.
[draft-ietf-pcn-sm-edge-behaviour-06] A. Charny, J. Zhang, [draft-ietf-pcn-sm-edge-behaviour-09] 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)",
June 2011. February 2012.
[draft-ietf-pcn-signaling-requirements-06] 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)", July Congestion Information in a DiffServ Domain(Work in progress)",
2011. 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 22, line 32 skipping to change at page 26, line 28
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
Cisco Systems, Inc. Cisco Systems, Inc.
7100-9 Kit Creek Road
PO Box 14987
RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987
USA USA
Email: anuragb@cisco.com Email: anuragb@cisco.com
 End of changes. 41 change blocks. 
94 lines changed or deleted 249 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/