draft-ietf-tsvwg-rsvp-pcn-04.txt   draft-ietf-tsvwg-rsvp-pcn-05.txt 
Internet Engineering Task Force Georgios Karagiannis Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente Internet-Draft University of Twente
Intended status: Experimental Anurag Bhargava Intended status: Experimental Anurag Bhargava
Expires: August 23, 2013 Cisco Systems, Inc. Expires: January 14, 2014 Cisco Systems, Inc.
February 23, 2013 July 14, 2013
Generic Aggregation of Resource ReSerVation Protocol (RSVP) Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains for IPv4 And IPv6 Reservations over PCN domains
draft-ietf-tsvwg-rsvp-pcn-04 draft-ietf-tsvwg-rsvp-pcn-05
Abstract Abstract
This document specifies extensions to Generic Aggregated RSVP This document specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of the PCN Controlled Load (CL) and Single [RFC4860] for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre- Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Congestion Notification.
Status of this Memo Status of this Memo
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 August 23, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 17 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 17
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 17 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 17
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 17 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 17
3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 18 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 18
3.11. Handling of Aggregated Resv Message by Aggregating Router . . 18 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 18
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 19 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 19
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 19 3.16. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . . . 26 9. Informative References . . . . . . . . . . . . . . . . . . . . . 26
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
1.1 Objective 1.1 Objective
skipping to change at page 4, line 35 skipping to change at page 4, line 35
centralized node. For more details see [RFC5559], [RFC6661], and centralized node. For more details see [RFC5559], [RFC6661], and
[RFC6662]. [RFC6662].
The main objective of this document is to specify the signalling The main objective of this document is to specify the signalling
protocol that can be used within a Pre-Congestion Notification (PCN) protocol that can be used within a Pre-Congestion Notification (PCN)
domain to carry reports from a PCN-egress-node to a PCN Decision domain to carry reports from a PCN-egress-node to a PCN Decision
point, considering that the PCN decision Point and PCN-ingress-node point, considering that the PCN decision Point and PCN-ingress-node
are collocated. are collocated.
If the PCN decision point is not collocated with the PCN-ingress-node If the PCN decision point is not collocated with the PCN-ingress-node
then additional signalling procedures are required that are out of then additional signalling procedures are required that are out of
the scope of this document. the scope of this document. Moreover, as mentioned above this
architecture conforms with PBAC when decision point is located in a
centralized node [RFC2753].
Several signaling protocols can be used to carry reports from a PCN- Several signaling protocols can be used to carry reports from a PCN-
egress-node to a PCN-ingress-nodes. However, since both PCN-egress- egress-node to a PCN-ingress-nodes. However, since both PCN-egress-
node and PCN-ingress-nodes are located on the data path, a signaling node and PCN-ingress-nodes are located on the data path, a signaling
protocol that follows the same path as the data path, like RSVP protocol that follows the same path as the data path, like RSVP
(Resource Reservation Protocol), is more suited for this purpose. In (Resource Reservation Protocol), is more suited for this purpose. In
particular, this document specifies extensions to Generic particular, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
and Single Marking (SM) edge behaviors over a Diffserv cloud using and Single Marking (SM) edge behaviors over a Diffserv cloud using
Pre-Congestion Notification. Pre-Congestion Notification.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
one of a small number of aggregated flows or "classes", based on the one of a small number of aggregated flows or "classes", based on the
Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv
router, packets are subjected to a "per-hop behavior" (PHB), which is router, packets are subjected to a "per-hop behavior" (PHB), which is
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, Diffserv [RFC2998] including resource-based admission control (RBAC),
policy-based admission control, assistance in traffic policy-based admission control (PBAC), 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.
[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
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify
the PHB, or set of PHBs, from which the Diffserv resources are to be the PHB, or set of PHBs, from which the Diffserv resources are to be
reserved. reserved.
The RSVP like signaling protocol required to carry reports from a The RSVP like signaling protocol required to carry reports from a
PCN-egress-node to a PCN-ingress-node needs to follow the PCN PCN-egress-node to a PCN-ingress-node needs to follow the PCN
signaling requirements defined in [RFC6663]. In addition to signaling requirements defined in [RFC6663]. In addition to
that the signalling protocol functionality supported by the PCN- that the signalling protocol functionality supported by the PCN-
ingress-nodes and PCN-egress-nodes needs to maintain logical ingress-nodes and PCN-egress-nodes needs to maintain logical
aggregate constructs (i.e. ingress-egrees-aggregate state) and be aggregate constructs (i.e. ingress-egress-aggregate state) and be
able to map e2e reservations to these aggregate constructs. Moreover, able to map e2e reservations to these aggregate constructs. Moreover,
no actual reservation state is needed to be maintained inside the PCN no actual reservation state is needed to be maintained inside the PCN
domain, i.e., the PCN-interior-nodes are not maintaing any domain, i.e., the PCN-interior-nodes are not maintaining any
reservation state. reservation state.
This can be accomplished by two possible approaches: This can be accomplished by two possible approaches:
Approach (1): Approach (1):
o) adapting the RFC 4860 aggregation procedures to fit the PCN o) adapting the RFC 4860 aggregation procedures to fit the PCN
requirements with as little change as possible over the RFC 4860 requirements with as little change as possible over the RFC 4860
functionality functionality
skipping to change at page 7, line 10 skipping to change at page 7, line 10
o) hence not performing aggregate RSVP signaling o) hence not performing aggregate RSVP signaling
o) piggy-backing of the PCN information inside the e2e RSVP o) piggy-backing of the PCN information inside the e2e RSVP
signaling. signaling.
Both approaches are probably viable, however, since the RFC 4860 Both approaches are probably viable, however, since the RFC 4860
operations have been thoroughly studied and implemented, it can be operations have been thoroughly studied and implemented, it can be
considered that the RFC 4860 solution can better deal with the more considered that the RFC 4860 solution can better deal with the more
challenging situations (rerouting in the PCN domain, failure of an challenging situations (rerouting in the PCN domain, failure of an
PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a
different edge, etc.). This is also the reason of chossing Approach different edge, etc.). This is also the reason of choosing Approach
(1) for the specification of the signaling protocol used to carry PCN (1) for the specification of the signaling protocol used to carry PCN
information from the PCN-egress-node to the PCN-ingress-node. In information from the PCN-egress-node to the PCN-ingress-node.
particular, this document specifies extensions to Generic
In particular, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
and Single Marking (SM) edge behaviors over a Diffserv cloud using and Single Marking (SM) edge behaviors over a Diffserv cloud using
Pre-Congestion Notification. Pre-Congestion Notification.
This document follows the PCN signaling requirements defined in This document follows the PCN signaling requirements defined in
[RFC6663] and specifies extensions to Generic Aggregated RSVP [RFC6663] and specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of PCN edge behaviors as specified in [RFC4860] for support of PCN edge behaviors as specified in
[RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP
aggregation can be used to setup and maintain: (1) Ingress Egress aggregation can be used to setup and maintain: (1) Ingress Egress
Aggregate (IEA) states at Ingress and Egress nodes and (2) generic Aggregate (IEA) states at Ingress and Egress nodes and (2) generic
skipping to change at page 10, line 30 skipping to change at page 10, line 31
o) Extended vDstPort SHOULD be set to the IPv4 or o) Extended vDstPort SHOULD be set to the IPv4 or
IPv6 destination addresses, of the Aggregator IPv6 destination addresses, of the Aggregator
(PCN-ingress-node) (PCN-ingress-node)
Ingress-egress-aggregate (IEA): Ingress-egress-aggregate (IEA):
The collection of PCN-packets from all PCN-flows The collection of PCN-packets from all PCN-flows
that travel in one direction between a specific pair that travel in one direction between a specific pair
of PCN-boundary-nodes. An ingress-egress-aggregate of PCN-boundary-nodes. An ingress-egress-aggregate
is identified by the combination of (1) PCN-BA is identified by the combination of (1) PCN-BA
(i.e., combination of the DSCP and ECN fields),(2) (i.e., combination of the DSCP and ECN fields),(2)
IP addresses of the specific pair of IP addresses of the specific pair of PCN-boundary-
PCN-boundary-nodes used by the -nodes used by the ingress-egress-aggregate. In
ingress-egress-aggregate. In this document one RSVP this document one RSVP generic aggregated
generic aggregated reservation is mapped to only one reservation is mapped to only one ingress-egress-
ingress-egress-aggregate, while one -aggregate, while one ingress-egress-aggregate is
ingress-egress-aggregate is mapped to either one mapped to either one or to more than one RSVP
or to more than one RSVP generic aggregated generic aggregated reservations.
reservations.
PCN-admission-state: PCN-admission-state:
The state ("admit" or "block") derived by the The state ("admit" or "block") derived by the
Decision Point for a given ingress-egress-aggregate Decision Point for a given ingress-egress-aggregate
based on statistics about PCN-packet marking. The based on statistics about PCN-packet marking. The
Decision Point decides to admit or block new flows Decision Point decides to admit or block new flows
offered to the aggregate based on the current value offered to the aggregate based on the current value
of the PCN-admission-state. of the PCN-admission-state.
Congestion level estimate (CLE): Congestion level estimate (CLE):
skipping to change at page 11, line 7 skipping to change at page 11, line 7
and is also used by the report suppression procedure and is also used by the report suppression procedure
if report suppression is activated. if report suppression is activated.
t-meas: t-meas:
A configurable time interval that defines the A configurable time interval that defines the
measurement period over which the PCN-egress-node measurement period over which the PCN-egress-node
collects statistics relating to PCN-traffic marking. collects statistics relating to PCN-traffic marking.
t-fail: t-fail:
An interval after which the Decision Point (i.e., An interval after which the Decision Point (i.e.,
PCN-ingress-node) concludes that communication from a PCN-ingress-node in this document) concludes that
given PCN-egress-node has failed if it has received communication from a given PCN-egress-node has failed
no reports from the PCN-egress-node during that if it has received no reports from the
interval. PCN-egress-node during that interval.
t-recvFail: t-recvFail:
A timer per ingress-egress-aggregate that the A timer per ingress-egress-aggregate that the
Decision point (i.e., PCN-ingress-node) sets every Decision point (i.e., PCN-ingress-node) sets every
time it receives an RSVP Aggregated RESV message for time it receives an RSVP Aggregated RESV message for
that ingress-egress-aggregate. When its value that ingress-egress-aggregate. When its value
reaches t-fail it is assumed that the PCN-ingress- reaches t-fail it is assumed that the PCN-ingress-
node has lost contact with the PCN-egress-node. node has lost contact with the PCN-egress-node.
Therefore the PCN-ingress-node blocks admission of Therefore the PCN-ingress-node blocks admission of
new PCN-flows into that aggregate and raises a new PCN-flows into that aggregate and raises a
skipping to change at page 11, line 36 skipping to change at page 11, line 36
RSVP extensions and operations. The elements of the used procedures RSVP extensions and operations. The elements of the used procedures
are specified in Section 3. Section 4 describes the protocol are specified in Section 3. Section 4 describes the protocol
elements. The security considerations are given in section 5 and the elements. The security considerations are given in section 5 and the
IANA considerations are provided in Section 6. IANA considerations are provided in Section 6.
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
2.1 Overview of RSVP Aggregation Procedures in PCN domains 2.1 Overview of RSVP Aggregation Procedures in PCN domains
The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
generic aggregated reservations [RFC4860], which are depending on generic aggregated reservations {RFC4860], which are depending on
ingress-egress-aggregates. In particular, one RSVP generic aggregated ingress-egress-aggregates. In particular, one RSVP generic aggregated
reservation matches to only one ingress-egress-aggregate. reservation matches to only one ingress-egress-aggregate.
However, one ingress-egress-aggregate matches to either However, one ingress-egress-aggregate matches to either
one or to more than one RSVP generic aggregated reservations. one or more than one RSVP generic aggregated reservations.
In addition, to comply with this specification it is considered that In addition, to comply with this specification it is considered that
the PCN-boundary nodes are able to distinguish by usng the addresses the PCN-boundary nodes are able to distinguish by using the addresses
that the RSVP messages are addressed to, and process (1) RSVP that the RSVP messages are addressed to, and process (1) RSVP
SESSIONS for generic aggregated sessions and their messages according SESSIONS for generic aggregated sessions and their messages according
to [RFC4860], (2) e2e RSVP sessions and messages according to to [RFC4860], (2) e2e RSVP sessions and messages according to
[RFC2205]. Furthermore, it is considered that by configuration the [RFC2205]. Furthermore, it is considered that by configuration the
PCN-interior-nodes are not able to distinguish neither RSVP generic PCN-interior-nodes are not able to distinguish neither RSVP generic
aggregated sessions and their associated messages [RFC4860], nor e2e aggregated sessions and their associated messages [RFC4860], nor e2e
RSVP sessions and their associated messages [RFC2205]. RSVP sessions and their associated messages [RFC2205].
-------------------------- --------------------------
/ PCN-domain \ / PCN-domain \
skipping to change at page 13, line 33 skipping to change at page 13, line 33
information information
The method of PCN marking within the PCN domain is based on The method of PCN marking within the PCN domain is based on
[RFC5670]. In addition, the method of encoding and transport of pre- [RFC5670]. In addition, the method of encoding and transport of pre-
congestion information is based [RFC6660]. The PHB-ID (Per Hop congestion information is based [RFC6660]. The PHB-ID (Per Hop
Behavior Identification Code) used SHOULD be set equal Behavior Identification Code) used SHOULD be set equal
to PCN-compatible Diffserv codepoint(s). to PCN-compatible Diffserv codepoint(s).
2.3. Traffic Classification Within The Aggregation Region 2.3. Traffic Classification Within The Aggregation Region
The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., combination The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination
of the DSCP and ECN fields), which interior nodes use to of the DSCP and ECN fields), which interior nodes use to
classify PCN-traffic. The PCN-traffic (e.g., e2e microflows) classify PCN-traffic. The PCN-traffic (e.g., e2e microflows)
belonging to an ingress-egress-aggregate can be classified only at belonging to an ingress-egress-aggregate can be classified only at
the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e.,
combination of the DSCP and ECN fields), (2) IP addresses of the combination of the DSCP and ECN fields), (2) IP addresses of the
specific pair of PCN-boundary-nodes used by a ingress-egress- specific pair of PCN-boundary-nodes used by a ingress-egress-
aggregate. The method of classification and traffic conditioning of aggregate. The method of classification and traffic conditioning of
PCN-traffic and non-PCN traffic and PHB configuration is described in PCN-traffic and non-PCN traffic and PHB configuration is described in
[RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e [RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e
microflows) belonging to a RSVP generic aggregated reservation can be microflows) belonging to a RSVP generic aggregated reservation can be
skipping to change at page 15, line 30 skipping to change at page 15, line 30
To comply with this specification it is considered that for message To comply with this specification it is considered that for message
integrity and node authentication, the same methods can be used as integrity and node authentication, the same methods can be used as
the ones described in Section 4 of [RFC4860] and [RFC5559]. the ones described in Section 4 of [RFC4860] and [RFC5559].
3. Elements of Procedure 3. Elements of Procedure
This section describes the procedures used to implement the This section describes the procedures used to implement the
aggregated RSVP procedure over PCN. It is considered that the aggregated RSVP procedure over PCN. It is considered that the
procedures for aggregation of e2e reservations over generic aggregate procedures for aggregation of e2e reservations over generic aggregate
RSVP reservations are the same as the procedures specified in Section RSVP reservations are same as the procedures specified in Section
4 of [RFC4860]. 4 of [RFC4860]. Please refer to [RFC4860] for all the below error
cases:
o) Incomplete message
o) Unexpected objects
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
skipping to change at page 18, line 45 skipping to change at page 18, line 45
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) If the Decision Point is not collocated with the PCN-ingress- o) If the Decision Point is not collocated with the PCN-ingress-
node, then other procedures need to be specified of handling the node, then other procedures need to be specified of handling the
Aggregated Resv Message by the Aggregating router, i.e., PCN- Aggregated Resv Message by the Aggregating router, i.e., PCN-
ingress-node. These procedures are out of the scope of this ingress-node. Even though these procedures are out of the scope
document. of this document, the PCN-ingress-node can refer to a central
decision point which can respond to the PCN ingress as per
[RFC2753]
o) If the Decision point is collocated with the PCN-ingress-node, o) If the Decision point is collocated with the PCN-ingress-node,
then the PCN-ingress-node (i.e. Aggregator) SHOULD use the then the PCN-ingress-node (i.e. Aggregator) SHOULD use the
information carried by the PCN objects as specified in information carried by the PCN objects as specified in
[RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress- [RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress-
node) needs to terminate an amount of traffic associated with node) needs to terminate an amount of traffic associated with
one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of
[RFC6661] and [RFC6662]), then several procedures of terminating [RFC6661] and [RFC6662]), then several procedures of terminating
e2e microflows can be deployed. The default procedure of e2e microflows can be deployed. The default procedure of
terminating e2e microflows (i.e., PCN-flows) is as follows, see terminating e2e microflows (i.e., PCN-flows) is as follows, see
e.g., [RFC6661]. e.g., [RFC6661].
skipping to change at page 19, line 43 skipping to change at page 19, line 43
be used as the ones described in Section 4 of [RFC4860] and Section be used as the ones described in Section 4 of [RFC4860] and Section
2.10 of [RFC3175]. In particular, should an aggregate reservation go 2.10 of [RFC3175]. In particular, should an aggregate reservation go
away (presumably due to a configuration change, route change, or away (presumably due to a configuration change, route change, or
policy event), the e2e reservations it supports are no longer active. policy event), the e2e reservations it supports are no longer active.
They must be treated accordingly. They must be treated accordingly.
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router
The handling of data on the reserved e2e Flow by Aggregating Router The handling of data on the reserved e2e Flow by Aggregating Router
is using the procedures described in [RFC4860] augmented with: is using the procedures described in [RFC4860] augmented with:
o) Regarding, PCN marking and traffic classification the procedures o) Regarding, PCN marking and traffic classification the procedures
defined in Section 2.2 and 2.4 of this document are used. defined in Section 2.2 and 2.4 of this document are used.
3.15. Procedures for Multicast Sessions 3.15. Procedures for Multicast Sessions
In this document no multicast sessions are considered. In this document no multicast sessions are considered.
3.16. Misconfiguration of PCN-node
In an event where a PCN-node is misconfigured within a PCN-domain,
the desired behavior is same as described in Section 3.9. Therefore,
the Aggregated Resv messages are simply forwarded as normal IP
datagrams.
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 Section 4 [RFC4860] and Section 3 of [RFC3175] elements defined in Section 4 [RFC4860] and Section 3 of [RFC3175]
augmented with the following rules: 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), see [RFC6661] and [RFC6662]. aggregator), see [RFC6661] and [RFC6662].
o) the DSCP value included in the SESSION object, SHOULD be set equal o) the DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint. to a PCN-compatible Diffserv codepoint.
o) An aggregated Resv message MUST carry one or more C-type PCN o) An aggregated Resv message MUST carry one or more C-type PCN
objects, see Section 4.1, to report the data measured by an objects, see Section 4.1, to report the data measured by an
PCN-egress-node (i.e., Deaggregator). PCN-egress-node (i.e., Deaggregator).
o) As described in [RFC6661], [RFC6663], PCN reports o) As described in [RFC6661], [RFC6663], PCN reports
from the PCN-egress-node (Deaggregator) to the decision point may from the PCN-egress-node (Deaggregator) to the decision point may
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)
4.1 PCN object 4.1 PCN object
The PCN object reports data measured by a PCN-egress-node and The PCN object reports data measured by a PCN-egress-node and
carried by the generic aggregated RESV messages specified in carried by the generic aggregated RESV messages specified in
[RFC4860]. PCN objects are defined for different PCN edge behavior [RFC4860]. PCN objects are defined for different PCN edge behavior
drafts. This document defines six types of PCN objects: drafts. This document defines six types of PCN objects:
o) Single Marking (SM) PCN object, when IPv4 addresses are used: o) Single Marking (SM) PCN object, when IPv4 addresses are used:
skipping to change at page 20, line 49 skipping to change at page 20, line 55
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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------|
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
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-ingress-node Address (16 bytes) + + IPv6 PCN-ingress-node Address (16 bytes) +
skipping to change at page 25, line 31 skipping to change at page 25, line 31
o allocate a new Object Class (PCN Object), see Section 4.1. o allocate a new Object Class (PCN Object), see Section 4.1.
o allocate a "PCN-domain rejects e2e reservation" Error Code that o allocate a "PCN-domain rejects e2e reservation" Error Code that
may appear only in e2e PathErr messages, see Section 3.1. may appear only in e2e PathErr messages, see Section 3.1.
7. Acknowledgments 7. Acknowledgments
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, Philip Eardley, Michael Menth, like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor,
Toby Moncaster, Francois Le Faucheur and James Polk for the provided Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur,
comments. James Polk and Lixia Zhang for the provided comments.
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 27, line 15 skipping to change at page 27, line 15
[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, February 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. 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
 End of changes. 26 change blocks. 
60 lines changed or deleted 76 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/