One document matched: draft-karagiannis-pcn-signaling-requirements-00.txt
Internet Engineering Task Force G. Karagiannis
Internet-Draft University of Twente
Intended status: Informational T. Taylor
Expires: April 19, 2010 K. Chan
Huawei Technologies
M. Menth
University of Wurzburg
October 19, 2009
Requirements for Signaling of (Pre-) Congestion Information in a
DiffServ Domain
draft-karagiannis-pcn-signaling-requirements-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Karagiannis, et al. Expires April 19, 2010 [Page 1]
Internet-Draft PCN Signaling requirements October 2009
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The
overall PCN architecture is described in RFC 5559. This memo
describes the requirements for the signaling applied within the PCN
domain, to carry PCN content from the PCN-egress-node towards either
the PCN-ingress-node or towards the centralised decision point.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for signaling from PCN-egress-nodes to PCN-ingress-
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 PCN Reporting Frequency . . . . . . . . .. . . . . . . . . . . 4
2.2 PCN Content requirements . . . . . . . . . . . . . . . . . . . 4
2.2.1 Admission control . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Flow Termination . . . . . . . . . . . . . . . . . . . . . 5
2.3 Signaling requirements . . . . . . . . . . . . . . . . . . . . 6
2.3.1 General signaling requirements . . . . . . . . . . . . . . 6
2.3.2 Admission control signaling requirements . . . . . . . . . 6
2.3.3 Flow Termination signaling requirements . . . . . . . . . 7
2.4. Filter specifications . . . . . . . . . . . . . . . . . . . . 7
3. Requirements for PCN-egress-node to centralized decision point
signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 PCN Reporting Frequency . . . . . . . . .. . . . . . . . . . . 8
3.2 PCN Content requirements. . . . . . . . . . . . . . . . . . . 8
3.2.1 Admission control . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Flow Termination . . . . . . . . . . . . . . . . . . . . . 8
3.3 Signaling requirements . . . . . . . . . . . . . . . . . . . . 8
3.3.1 General signaling requirements . . . . . . . . . . . . . . 9
3.3.2 Admission control signaling requirements . . . . . . . . . 9
3.3.3 Flow Termination signaling requirements . . . . . . . . . 9
3.4. Filter specifications . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . .
Karagiannis, et al. Expires April, 19, 2010 [Page 2]
Internet-Draft PCN Signaling Requirements October 2009
1. Introduction
The main objective of Pre-Congestion Notification (PCN) is to support
the quality of service (QoS) of inelastic flows within a Diffserv
domain, in a simple, scalable, and robust fashion. Two mechanisms
are used: admission control and flow termination. Admission control
is used to decide whether to admit or block a new flow request, while
flow termination is used in abnormal circumstances to decide
whether to terminate some of the existing flows. To support these
two features the overall rate of PCN-traffic is metered on every link
in the domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. These configured rates are below the
rate of the link thus providing notification to boundary nodes about
overloads before any congestion occurs (hence "pre-congestion"
notification). The level of marking allows boundary nodes to make
decisions about whether to admit or terminate. For more details see
[RFC5559].
Signaling is needed to transport PCN admission control and flow
termination related PCN content from PCN-egress-nodes towards
either PCN-ingress-nodes or a centralised decision point, see
[RFC5559]. This memo briefly describes this PCN content and it
specifies the requirements that have to be satisfied by the signaling
protocol needed to transport this PCN content.
Currently, only the CL [draft-ietf-pcn-cl-edge-behaviour-00] and SM
[draft-ietf-pcn-sm-edge-behaviour-00] PCN edge behaviour drafts are
PCN working group drafts. Therefore, the current version of this memo
is only referring to the signaling requirements imposed by these
drafts. If other PCN edge behaviour drafts, e.g.,
[draft-karagiannis-pcn-hose-edge-behaviour-00],
[I-D.Piggybacked-Edge-Behaviour] will become PCN working group
drafts, then a new version of this memo will also incorporate the
signaling requirements imposed by these new PCN edge behaviour
drafts.
1.1. Terminology
In addition to the terms defined in [RFC5559], this document uses the
following terms:
Tbd.
Karagiannis, et al. Expires April, 19, 2010 [Page 3]
Internet-Draft PCN Signaling Requirements October 2009
2. Requirements for signaling from PCN-egress-nodes to PCN-ingress-
nodes
This section describes the PCN information and the requirements that
apply to signaling protocols used for the transport of PCN
content from PCN-egress-nodes to PCN-ingress-nodes.
2.1 PCN Reporting Frequency
For the CL [draft-ietf-pcn-cl-edge-behaviour-00] and SM
[draft-ietf-pcn-sm-edge-behaviour-00] the content described in the
next section is reported at regular intervals, as new measurements
become available. An interval of the order of 100 to 300 ms is
suggested in the edge behaviour drafts.
2.2 PCN Content requirements
This section describes the PCN content, i.e., PCN information, that
has to be transported by a signaling protocol from a PCN-egress-node
to a PCN-ingress-node. Different types of content can be
distinguished depending on the used PCN edge behaviour in use and on
whether the PCN content is used during admission control or flow
termination. It is important to note that the description of the PCN
contents in the CL and SM edge behaviors is not yet stable. This
means that the PCN contents associated with Cl and SM edge behaviours
draft might change. Future versions of this memo will encompass these
changes.
2.2.1 Admission control
This subsection describes which PCN contents are required to be
transported from the PCN-egress-node to the PCN-ingress-node
during PCN admission control. Furthermore, for each PCN content, it
specifies which edge behaviours is using it.
2.2.1.1 Admission Control state
The CL [draft-ietf-pcn-cl-edge-behaviour-00] and SM
[draft-ietf-pcn-sm-edge-behaviour-00] edge behaviours need to
transmit a computed admission state to the point where the flow
decision is made. The "Admission control state" PCN content is a
boolean that uses the following values:
o admit (Boolean TRUE); this PCN content value is
used to notify the PCN-ingress-node that the admission
control process at the PCN-ingress-node should continue.
o block (Boolean FALSE); this PCN content value is used
to notify the PCN-ingress-node that the admission control
process at the PCN-ingress-node should stop.
Karagiannis, et al. Expires April, 19, 2010 [Page 4]
Internet-Draft PCN Signaling Requirements October 2009
This PCN content can be reported by the PCN-egress-
node using one of the following ways:
1) report all periodically generated PCN content (at the end of
each measurement interval)
2) report only when PCN content changes, unless either ThM packets
(for CL) or ETM packets (for SM) are observed. Then all
periodically (per each measurement interval) must be reported.
2.2.2 Flow Termination
This subsection describes which PCN contents are required to be
transported from the PCN-egress-node to the PCN-ingress-node
during PCN flow termination. Furthermore, for each PCN content, it
specifies which edge behaviour is using it.
2.2.2.1 Traffic rate
The CL and SM edge behaviours both need to send a traffic rate to the
decision point when flow termination may be required. This rate is
calculated in both cases as the number of octets per second of PCN
traffic carried in packets that are not excess-marked. The CL edge
behaviour calls this the estimated edge-to-edge supportable rate,
while the SM edge behaviour calls it the sustainable admission rate.
The processing of this rate at the decision point differs between the
two edge behaviours. According to the CL edge behaviour, this rate is
required (flow termination may be necessary) only when the PCN-
egress-node has observed excess-marked packets in the ingress-egress
aggregate being reported. The SM edge behaviour requires reporting of
the traffic rate whenever the admission control state is "block".
2.2.2.2 List with flow IDs
In the case where Equal Cost Multipath (ECMP) routing is being used,
if flow termination may be necessary, the CL, provide a list of flow
identifiers (e.g., IP five-tuples) to the decision point. These flow
identifiers indicate flows which are candidates for termination
because excess-marked packets have been received within those flows.
The representation of a flow ID depends on the surrounding
environment, e.g., "pure IP", MPLS, GMPLS, etc. For the
representation of a flow ID in a "pure IP" surrounding environment,
see Section 2.3. This "List with flow IDs" PCN content can be sent
when the PCN-egress-node is operating in flow termination:
o either regularly at the end of each measurement interval;
o or when the list, compared to previous measurement intervals, is
being modified.
Karagiannis, et al. Expires April, 19, 2010 [Page 5]
Internet-Draft PCN Signaling Requirements October 2009
2.3 Signaling requirements
This section describes the requirements for signaling protocols that
are used to carry the PCN content from PCN-egress-nodes to PCN-
ingress-nodes.
2.3.1 General signaling requirements
This section describes the signaling requirements that are valid for
both admission control and flow termination features.
2.3.1.1 Priority of signaling messages
Signaling messages SHOULD have a higher priority than data packets.
This is needed to avoid as much as possible the situations that
during severe overload cases the signaling messages are dropped
within the PCN domain.
2.3.1.2 Local information exchange
Signaling messages MUST be able to carry the PCN contents from the
PCN-egress-node to the PCN-ingress-node.
2.3.1.3 Carry identification of PCN edge nodes
The signaling protocol MUST be able to carry identification
(address information) of the PCN edge nodes. However, the
identification of the PCN edge nodes MUST NOT be visible outside
the PCN domain.
2.3.1.4 Signaling load
The load generated by the signaling protocol to carry the PCN content
from the PCN-egress-nodes to the PCN-ingress-node SHOULD be minimized
as much as possible.
2.3.2 Admission control signaling requirements
This subsection describes the signaling requirements for admission
control purposes.
2.3.2.1 Reliability
There are situations that PCN contents need to be sent in a reliable
way, meaning that the PCN-egress-node MUST be acknowledged that the
sent PCN content is successfully received by the PCN-ingress-node. It
is considered that the PCN contents that are sent in a regular
fashion do not need to be sent reliably.
Karagiannis, et al. Expires April, 19, 2010 [Page 6]
Internet-Draft PCN Signaling Requirements October 2009
The signaling requirements associated with each PCN content that is
sent by the PCN-egress-node during admission control are described
below:
o "Admission control state": The signaling protocol MUST be able to
carry this PCN content, which MAY be carried reliably from
the PCN-egress-node to the PCN-ingress-node.
2.3.3 Flow Termination signaling requirements
This subsection describes the signaling requirements for flow
termination purposes.
2.3.3.1 Reliability
This section describes which PCN contents used during flow
termination have to be sent reliably:
o "Traffic rate": The signaling protocol MUST be
able to carry this PCN content, which MAY be carried reliably
from the PCN-egress-node to the PCN-ingress-node.
o "List with flow IDs": The signaling protocol SHOULD be
able to carry this PCN content. Moreover, this PCN contents
MUST be sent reliably.
2.4. Filter specifications
The filter specification at the PCN-egress-nodes depends on the
surrounding environment, e.g., pure IP, MPLS, GMPLS. In this
document, only the pure IP filter spec is given as an example. In
this case the filter spec should be able to identify a flow using
(all 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.
o IP address of PCN-ingress-node
Karagiannis, et al. Expires April, 19, 2010 [Page 7]
Internet-Draft PCN Signaling Requirements October 2009
3. Requirements for PCN-egress-node to centralised decision point
signaling
This section describes the PCN information and the requirements that
apply to signaling protocols used for the transport of PCN
content from PCN-egress-nodes to centralised decision points.
3.1 PCN Reporting Frequency
The reporting frequeny required for this type of scenario is similar
to the one described in Section 2.1. The only difference is the fact
that these PCN contents need to be sent from the PCN-egress-node to
the centralised decision point.
3.2 PCN Content requirements
This section describes the PCN content, i.e., PCN information, that
has to be transported by a signaling protocol from a PCN-egress-node
to a centralized decision point. Different types of content can be
distinguished depending on the PCN edge behaviour used and on
whether the PCN content is used during admission control or flow
termination.
3.2.1 Admission control
The same PCN contents and the same method of transmission described
in Section 2.2.1 applies for this case. The only difference is the
fact that these PCN contents need to be sent from the PCN-egress-node
to the centralised decision pont.
3.2.2 Flow Termination
The same PCN contents and the same method of transmission described
in Section 2.2.2 applies for this case. The only difference is the
fact that these PCN contents need to be sent from the PCN-egress-node
to the centralised decision point.
3.3 Signaling requirements
This section describes the requirements for signaling protocols that
are used to carry the PCN content from PCN-egress-nodes to
centralized decision points.
Karagiannis, et al. Expires April, 19, 2010 [Page 8]
Internet-Draft PCN Signaling Requirements October 2009
3.3.1 General signaling requirements
The general signaling requirements specified in Section 2.3.1 apply
also for this case. The following general signaling requirements are
different.
3.3.1.1 Local information exchange
Signaling messages MUST be able to carry the PCN contents from the
PCN-egress-node to centralised decision point.
3.3.1.2 Carry identification of PCN edge nodes
The signaling protocol MUST be able to carry identification
(address information) of the PCN edge nodes and centralised decision
point. However, the identification of the PCN edge nodes and the
centralised decision points MUST NOT be visible outside the PCN
domain.
3.3.1.3 Signaling load
The load generated by the signaling protocol to carry the PCN content
from the PCN-egress-nodes to the centralized decision point SHOULD be
minimized as much as possible.
3.3.2 Admission control signaling requirements
The same admission control signaling requirements described in
Section 2.3.2 apply for this case. The only difference is the fact
that these signaling requirements apply for signaling messages that
have to be sent from a PCN-egress-node to a centralised decision
point.
3.3.3 Flow Termination signaling requirements
The same flow termination signaling requirements described in
Section 2.3.3 apply for this case. The only difference is the fact
that these signaling requirements apply for signaling messages that
have to be sent from a PCN-egress-node to a centralised decision
point.
Karagiannis, et al. Expires April, 19, 2010 [Page 9]
Internet-Draft PCN Signaling Requirements October 2009
3.4. Filter specifications
The filter specification at the PCN-egress-nodes depends on the
surrounding environment, e.g., pure IP, MPLS, GMPLS. The filter
specifications at a PCN-egress-node described in Section 2.4 apply
also for this case. The main difference is the fact that the filter
specification, in this case, should be able to identify in addition
to the set of parameters listed in Section 2.4, also the "IP address
of the centralised decision point".
4. Security Considerations
[RFC5559] provides a general description of the security
considerations for PCN. This memo introduces no new considerations.
5. IANA Considerations
This memo includes no request to IANA.
6. Acknowledgements
Tbd.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[draft-karagiannis-pcn-hose-edge-behaviour-00] G. Karagiannis,
L. Westberg, G. Apostolopoulos, "PCN Boundary Node
Behaviour for the HOSE Mode of Operation (Work in
progress)", October 2009.
[draft-ietf-pcn-cl-edge-behaviour-00] T. Taylor, A, Charny,
F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node
Behaviour for the Controlled Load (CL) Mode of Operation
(Work in progress)", July 2009.
Karagiannis, et al. Expires April, 19, 2010 [Page 10]
Internet-Draft PCN Signaling Requirements October 2009
[draft-ietf-pcn-sm-edge-behaviour-00] A. Charny, J. Zhang,
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node
Behaviour for the Single Marking (SM) Mode of Operation
(Work in progress)", July 2009.
7.2. Informative References
Authors' Addresses
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom111.taylor@bell.net
Kwok Ho Chan
Huawei Technologies
125 Nagog Park
Acton, MA 01720
USA
Email: khchan@huawei.com
Michael Menth
University of Wurzburg
Institute of Computer Science
Room B206
Am Hubland, Wuerzburg D-97074
Germany
Email: menth@informatik.uni-wuerzburg.de
Karagiannis, et al. Expires April 19, 2010 [Page 11]
Internet-Draft PCN Signaling Requirements October 2009
| PAFTECH AB 2003-2026 | 2026-04-24 07:22:54 |