< draft-ietf-pcn-signaling-requirements-07.txt   draft-ietf-pcn-signaling-requirements-08.txt >
Internet Engineering Task Force G. Karagiannis Internet Engineering Task Force G. Karagiannis
Internet-Draft University of Twente Internet-Draft University of Twente
Intended status: Informational T. Taylor Intended status: Informational T. Taylor
Expires: January 03, 2012 K. Chan Expires: August 08, 2012 Huawei
Huawei Technologies K. Chan
Consultant
M. Menth M. Menth
University of Tuebingen University of Tuebingen
P. Eardley P. Eardley
BT BT
July 03, 2011 February 08, 2012
Requirements for Signaling of (Pre-) Congestion Information in a Requirements for Signaling of (Pre-) Congestion Information in a
DiffServ Domain DiffServ Domain
draft-ietf-pcn-signaling-requirements-07 draft-ietf-pcn-signaling-requirements-08
Abstract Abstract
Precongestion notification (PCN) is a means for protecting quality of Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The service for inelastic traffic admitted to a Diffserv domain. The
overall PCN architecture is described in RFC 5559. This memo overall PCN architecture is described in RFC 5559. This memo
describes the requirements for the signaling applied within the PCN describes the requirements for the signaling applied within the PCN
domain: (1) PCN-feedback-information is carried from the PCN-egress- domain: (1) PCN-feedback-information is carried from the PCN-egress-
node to the decision point;(2) the decision point may ask the PCN- node to the decision point;(2) the decision point may ask the PCN-
ingress-node to measure, and report back, the rate of sent PCN- ingress-node to measure, and report back, the rate of sent PCN-
traffic between that PCN-ingress-node and PCN-egress-node. The traffic between that PCN-ingress-node and PCN-egress-node. The
decision point may be either collocated with the PCN-ingress-node or decision point may be either collocated with the PCN-ingress-node or
a centralized node (in the latter case, (2) is not required). The a centralized node (in the first case, (2) is not required). The
signaling requirements pertain in particular to two edge behaviours, signaling requirements pertain in particular to two edge behaviors,
"controlled load (CL)" and "single marking (SM)" "controlled load (CL)" and "single marking (SM)".
[draft-ietf-pcn-cl-edge- behaviour-09],
[draft-ietf-pcn-sm-edge-behaviour-06].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 03, 2012. This Internet-Draft will expire on August 08, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling Requirements for Messages from the PCN-Egress-Nodes to 2. Signaling Requirements for Messages from the PCN-Egress-Nodes to
Decision Point(s) . . . . . . . . . . . . . . . . . . . . . . . . 3 Decision Point(s) . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Specification of PCN-Flow Identifiers . . . . . . . . . . . 4
3. Signaling Requirements for Messages between Decision Point(s) and 3. Signaling Requirements for Messages between Decision Point(s) and
PCN-Ingress-Nodes . . . . . . . . . . . . . . . . . . . . . . . . 5 PCN-Ingress-Nodes . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The main objective of Pre-Congestion Notification (PCN) is to support The main objective of Pre-Congestion Notification (PCN) is to support
the quality of service (QoS) of inelastic flows within a Diffserv the quality of service (QoS) of inelastic flows within a Diffserv
domain in a simple, scalable, and robust fashion. Two mechanisms domain in a simple, scalable, and robust fashion. Two mechanisms
skipping to change at page 3, line 26 skipping to change at page 3, line 26
certain configured rates are exceeded. These configured rates are certain configured rates are exceeded. These configured rates are
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). The PCN-egress-nodes measure the rates of congestion" notification). The PCN-egress-nodes measure the rates of
differently marked PCN traffic in periodic intervals and report these differently marked PCN traffic in periodic intervals and report these
rates to the decision points for admission control and flow rates to the decision points for admission control and flow
termination, based on which they take their decisions. The decision termination, based on which they take their decisions. The decision
points may be collocated with the PCN-ingress-nodes or their function points may be collocated with the PCN-ingress-nodes or their function
may be implemented in a centralized node. may be implemented in a centralized node.
For more details see [RFC5559], For more details see [RFC5559],
[draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-cl-edge-behaviour-11],
[draft-ietf-pcn-sm-edge-behaviour-06]. [draft-ietf-pcn-sm-edge-behaviour-08].
This memo specifies the requirements on signaling protocols: This memo specifies the requirements on signaling protocols:
o to carry reports from a PCN-egress-node to the decision point, o to carry reports from a PCN-egress-node to the decision point,
o to carry requests, from the decision point to a PCN-ingress-node, o to carry requests, from the decision point to a PCN-ingress-node,
that trigger the PCN-ingress-node to measure the PCN-sent-rate, that trigger the PCN-ingress-node to measure the PCN-sent-rate,
o to carry reports, from a PCN-ingress-node to the decision o to carry reports, from a PCN-ingress-node to the decision
point. point.
The latter two messages are only needed if the decision point and The latter two messages are only needed if the decision point and
PCN-ingress-node are not collocated. PCN-ingress-node are not collocated.
2. Signaling Requirements for Messages from the PCN-Egress-Nodes to 2. Signaling Requirements for Messages from the PCN-Egress-Nodes to
Decision Point(s) Decision Point(s)
The PCN-egress-node measures- per ingress-egress-aggregate the rates The PCN-egress-node measures per ingress-egress-aggregate the rates
of differently marked PCN-traffic in regular intervals. The of differently marked PCN-traffic in regular intervals. The
measurement intervals are recommended to take a fixed value between measurement intervals are recommended to take a fixed value between
100 ms and 500 ms, see [draft-ietf-pcn-cl-edge-behaviour-09], 100 ms and 500 ms, see [draft-ietf-pcn-cl-edge-behaviour-11],
[draft-ietf-pcn-sm-edge-behaviour-06]. At the end of each measurement [draft-ietf-pcn-sm-edge-behaviour-08]. At the end of each measurement
interval, the PCN-egress-node calculates the congestion-level- interval, the PCN-egress-node calculates the congestion-level-
estimate (CLE) based on these quantities. The PCN-egress-node MAY be estimate (CLE) based on these quantities.
configured to record a set of identifiers of PCN-flows for which it
received excess-traffic-marked packets during the last measurement The PCN-egress-node MAY be configured to record a set of identifiers
interval. The latter may be useful to perform flow termination in of PCN-flows for which it received excess-traffic-marked packets
networks with multipath routing. during the last measurement interval. The latter may be useful to
perform flow termination in networks with multipath routing.
At the end of each measurement interval, or less frequently if At the end of each measurement interval, or less frequently if
"optional report suppression" is activated, see "optional report suppression" is activated, see
[draft-ietf-pcn-cl-edge-behaviour-09], [draft-ietf-pcn-sm-edge- [draft-ietf-pcn-cl-edge-behaviour-11], [draft-ietf-pcn-sm-edge-
behaviour-06], the PCN-egress-node sends a report to the decision behaviour-08], the PCN-egress-node sends a report to the decision
point. point.
For the SM edge behaviour, the report MUST contain: For the SM edge behavior, the report MUST contain:
o identifier of the PCN-ingress-node and the identifier of the o identifier of the PCN-ingress-node and the identifier of the
PCN-egress-node (typically their IP addresses); together they PCN-egress-node (typically their IP addresses); together they
specify the ingress-egress-aggregate to which the report refers, specify the ingress-egress-aggregate to which the report refers,
o rate of not-marked PCN-traffic (NM-rate) in octets/second, o rate of not-marked PCN-traffic (NM-rate) in octets/second,
o rate of PCN-marked traffic (PM-rate) in octets/second, o rate of PCN-marked traffic (PM-rate) in octets/second,
o congestion-level-estimate, which is a number between zero and
one.
For the CL edge behaviour, the report MUST contain: For the CL edge behavior, the report MUST contain:
o identifier of the PCN-ingress-node and the identifier of the o identifier of the PCN-ingress-node and the identifier of the
PCN-egress-node (typically their IP addresses); together they PCN-egress-node (typically their IP addresses); together they
specify the ingress-egress-aggregate to which the report refers, specify the ingress-egress-aggregate to which the report refers,
o rate of not-marked PCN-traffic (NM-rate) in octets/second, o rate of not-marked PCN-traffic (NM-rate) in octets/second,
o rate of threshold-marked PCN traffic (ThM-rate) in o rate of threshold-marked PCN traffic (ThM-rate) in
octets/second, octets/second,
o rate of excess-traffic-marked traffic (ETM-rate) in octets/second, o rate of excess-traffic-marked traffic (ETM-rate) in octets/second,
o congestion-level-estimate, which is a number between zero and
one.
The number format and the rate units used by the signalling protocol The number format and the rate units used by the signaling protocol
will limit the maximum rate that PCN can use. If signalling space is will limit the maximum rate that PCN can use. If signaling space is
tight it might be reasonable to impose a limit, but any such limit tight it might be reasonable to impose a limit, but any such limit
may impose unnecessary constraints in future. may impose unnecessary constraints in future.
For both CL and SM edge behaviours, the report MAY also contain:
o a set of PCN-flow identifiers (see Section 2.1).
The signaling report can either be sent directly to the decision The signaling report can either be sent directly to the decision
point or it can "piggy-back", i.e., be included within some other point or it can "piggy-back", i.e., be included within some other
message that passes through the PCN-egress-node and then reaches the message that passes through the PCN-egress-node and then reaches the
decision point. decision point.
Signaling messages SHOULD have a higher priority than data packets to As described in [draft-ietf-pcn-cl-edge-behaviour-11], PCN reports
deliver them quickly and to avoid that they are dropped in case of from the PCN-egress-node to the decision point may contain flow
overload. 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."
Signaling messages SHOULD have a higher priority and a lower drop
precedence than PCN-packets, see [RFC5559], to deliver them quickly
and to avoid that they are dropped in case of overload.
The load generated by the signaling protocol SHOULD be minimized. We The load generated by the signaling protocol SHOULD be minimized. We
give three examples that may help to achieve that goal: give three examples that may help to achieve that goal:
o piggy-backing the reports by the PCN-egress-nodes to the decision o piggy-backing the reports by the PCN-egress-nodes to the decision
point(s) onto other signaling messages that are already in place, point(s) onto other signaling messages that are already in place,
o reducing the amount of reports to be sent by optional report o reducing the amount of reports to be sent by optional report
suppression, suppression,
o combining reports for different ingress-egress-aggregates in a o combining reports for different ingress-egress-aggregates in a
single message (if they are for the same decision point). single message (if they are for the same decision point).
As PCN reports are sent regularly, additional reliability mechanisms As PCN reports are sent regularly, additional reliability mechanisms
are not needed. This also holds in the presence of optional report are not needed. This also holds in the presence of optional report
suppression as reports are sent periodically if actions by the suppression as reports are sent periodically if actions by the
decision point(s) are needed, see [draft-ietf-pcn-cl-edge-behaviour- decision point(s) are needed, see [draft-ietf-pcn-cl-edge-behaviour-
-09], [draft-ietf-pcn-sm-edge-behaviour-06]. -11], [draft-ietf-pcn-sm-edge-behaviour-08].
2.1 Specification of PCN-Flow Identifiers
The representation of a PCN-flow identifier depends on the
surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
Examples of such PCN-flow identifier representations can be found in
[RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804].
In pure IP networks, the identifier may consist of a subset of the
following information:
o source IP address;
o destination IP address
o protocol identifier and higher layer (port) addressing
o flow label (typical for IPv6)
o SPI field for IPsec encapsulated data
o DSCP/TOS field
Note, where a PCN-flow consists of a collection of microflows, then
the PCN-flow is identified by the PCN-ingress-node's and PCN-egress-
node's identifiers (typically their IP addresses), which are already
part of the report.
3. Signaling Requirements for Messages between Decision Point(s) and 3. Signaling Requirements for Messages between Decision Point(s) and
PCN-Ingress-Nodes PCN-Ingress-Nodes
Through request-response signaling between the decision point and Through request-response signaling between the decision point and
PCN-ingress-node, the decision point requests and in response the PCN-ingress-node, the decision point requests and in response the
PCN-ingress-node measures and reports the PCN-sent-rate for a PCN-ingress-node measures and reports the PCN-sent-rate for a
specific ingress-egress-aggregate. Signaling is needed only if the specific ingress-egress-aggregate. Signaling is needed only if the
decision point and PCN-ingress-node are not collocated. decision point and PCN-ingress-node are not collocated.
skipping to change at page 6, line 8 skipping to change at page 5, line 35
rate. rate.
The report MUST contain: The report MUST contain:
o the PCN-sent-rate in octets/second, o the PCN-sent-rate in octets/second,
o the identifier of the PCN-ingress-node and the identifier of the o the identifier of the PCN-ingress-node and the identifier of the
PCN-egress-node. PCN-egress-node.
The request MUST be addressed to the PCN-ingress-node, and the report The request MUST be addressed to the PCN-ingress-node, and the report
MUST be addressed to the decision point that requested it. MUST be addressed to the decision point that requested it.
The request and the report SHOULD be sent with high priority and The request and the report SHOULD be sent with high priority, a lower
reliably, because they are sent only when flow termination is needed, drop precedence than PCN-packets, and reliably, because they are sent
which is an urgent action. only when flow termination is needed, which is an urgent action.
Note that a complete system description for a PCN domain with
centralized Decision Point includes the signaling from Decision Point
to the PCN-ingress-nodes to control flow admission and termination.
However, this is a known problem whose solutions were given by,
for example, [RFC3084] or [RFC5431], and it lies outside the scope of
the present document.
4. Security Considerations 4. Security Considerations
[RFC5559] provides a general description of the security [RFC5559] provides a general description of the security
considerations for PCN. This memo does not introduce additional considerations for PCN. This memo relies on the security related
security considerations. requirements on the PCN signaling, provided in [RFC5559]. In
particular, the signaling between the PCN-boundary-nodes must be
protected from attacks. For example, the recipient needs to
validate that the message is indeed from the node that claims to have
sent it. Possible measures include digest authentication and
protection against replay and man-in-the-middle attacks.
For the generic aggregate RSVP protocol, specifically, additional
protection methods against security attacks are described in
[RFC4860].
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Acknowledgements 6. Acknowledgments
We would like to acknowledge the members of the PCN working group for We would like to acknowledge the members of the PCN working group for
the discussions that generated the contents of this memo. the discussions that produced the contents of this memo.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] P., Eardley, "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[draft-ietf-pcn-cl-edge-behaviour-09] T. Taylor, A, Charny, [draft-ietf-pcn-cl-edge-behaviour-11] T. Taylor, A, Charny,
F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node
Behaviour for the Controlled Load (CL) Mode of Operation Behaviour for the Controlled Load (CL) Mode of Operation
(Work in progress)", June 2011. (Work in progress)", December 2011.
[draft-ietf-pcn-sm-edge-behaviour-06] A. Charny, J. Zhang, [draft-ietf-pcn-sm-edge-behaviour-08] A. Charny, J. Zhang,
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node
Behaviour for the Single Marking (SM) Mode of Operation Behaviour for the Single Marking (SM) Mode of Operation
(Work in progress)", June 2011. (Work in progress)", December 2011.
7.2. Informative References 7.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC3084] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS Usage
Functional Specification", RFC 2205, September 1997. for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Davenport, "Generic Aggregate Resource ReSerVation
Engineering (RSVP-TE) Extensions", RFC 3473, Protocol (RSVP) Reservations", RFC 4860, May 2007.
January 2003.
[RFC4804] F. Le Faucheur, "Aggregation of Resource ReSerVation [RFC5431] D. Sun, "Diameter ITU-T Rw Policy Enforcement Interface
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", Application", RFC 5431, March 2009.
RFC 4804, February 2007.
Authors' Addresses Authors' Addresses
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@ewi.utwente.nl EMail: g.karagiannis@utwente.nl
Tom Taylor Tom Taylor
Huawei Technologies Huawei Technologies
1852 Lorraine Ave. 1852 Lorraine Ave.
Ottawa, Ontario K1H 6Z8 Ottawa, Ontario K1H 6Z8
Canada Canada
Phone: +1 613 680 2675 Phone: +1 613 680 2675
Email: tom111.taylor@bell.net Email: tom.taylor.stds@gmail.com
Kwok Ho Chan Kwok Ho Chan
Huawei Technologies Consultant
125 Nagog Park
Acton, MA 01720 Email: khchan.work@gmail.com
USA
Email: khchan@huawei.com
Michael Menth Michael Menth
University of Tuebingen University of Tuebingen
Department of Computer Science Department of Computer Science
Chair of Communication Networks Chair of Communication Networks
Sand 13 Sand 13
72076 Tuebingen 72076 Tuebingen
Germany Germany
Phone: +49 7071 29 70505 Phone: +49 7071 29 70505
Email: menth@informatik.uni-tuebingen.de Email: menth@informatik.uni-tuebingen.de
 End of changes. 37 change blocks. 
105 lines changed or deleted 82 lines changed or added

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