Internet Engineering Task Force R. Geib
Internet-Draft Deutsche Telekom
Intended status: Informational September 19, 2008
Expires: March 23, 2009
Signaling 3 PCN states with baseline encoding
draft-geib-baseline-encoding-3state-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 March 23, 2009.
Abstract
Layer 2 transport services like MPLS offer only 2 states to encode
ECN state, if DiffServ based Class of Service is operated. Still, a
mechanism by which PCN egress nodes can differentiate between the
normal behaviour state, admission stop state control state and flow
termination state, by using PCN marking of packets is desirable.
This document describes how threshold and excess marking can be
combined with PCN baseline encoding. A minimalistic approach like
the one described in the following has some obvious shortcomings.
These shortcomings are also presented and discussed. Currently, the
aim of this document is to trigger experimentation feasability
studies. Standardisation will be pursued in the future based on the
results of the studies.
Geib Expires March 23, 2009 [Page 1]
Internet-Draft 3state signaling with baseline encoding September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Signaling 3 PCN states with baseline encoding . . . . . . . . 3
3.1. Three state signaling with PCN baseline encoding . . . . . 4
3.2. Benefits of three state signaling with PCN baseline
encoding . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Simple experimental deployment . . . . . . . . . . . . . . 7
3.4. Known issues of three state signalling with PCN
baseline encoding . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Geib Expires March 23, 2009 [Page 2]
Internet-Draft 3state signaling with baseline encoding September 2008
1. Introduction
DiffServ and MPLS are state of the art technologies operated in many
carrier backbones. Following RFC 5129 [RFC5129], only PCN baseline
encoding [pcn-baseline-encoding] is applicable within MPLS networks.
Still, it may be desirable to differentiate operation of a pre
congested PCN domain interface in the admission stop state from
operation in the termination state at the egress and do so without
any extra signaling but "M/CE" marked PCN packets.
This draft proposes a method to combine threshold and excess marking
with PCN baseline encoding. As the PCN egress node must infer the
operational state of a domain's pre-congested PCN interface(s) by
marking patterns, shortcomings of the proposed method are obvious.
They will be discussed briefly in this document. The intent of this
draft is to start experimentation rather than standardisation. Any
form of standardisation will only be started, if experiments show,
that the known drawbacks of the proposed two state marking with PCN
baseline encoding can be overcome without introducing complex
solutions.
1.1. 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].
2. Terminology
This draft does not introduce any new functionalities. The
terminology in this document follows the one used by the PCN WG at
the time of writing, in detail:
o draft-ietf-pcn-architecture-06 [pcn-architecture],
o draft-moncaster-pcn-baseline-encoding-02 [pcn-baseline-encoding],
o draft-eardley-pcn-marking-behaviour-01 [pcn-marking-behaviour],
and
o draft-menth-pcn-psdm-encoding-00 [pcn-psdm-encoding].
3. Signaling 3 PCN states with baseline encoding
PCN based admission control functions best with threshold marking.
This means, that once PCN traffic is above a links PCN-threshold-
Geib Expires March 23, 2009 [Page 3]
Internet-Draft 3state signaling with baseline encoding September 2008
rate, all PCN packets passing this link are marked. With baseline
encoding, only two codepoints are available to signal a links pre-
congestion state. As all PCN traffic is marked with the single
available codepoint to indicate any (pre) congestion state, there's
little solution space to further differentiate crossing of the PCN-
excess-rate by a codepoint or by excess marking (the latter being the
more suitable marking behaviour to indicate that a links PCN load
reached termination state).
3.1. Three state signaling with PCN baseline encoding
Admission control is realised by threshold marking of PCN traffic,
once the PCN traffic is above a links PCN-treshold-rate. If PSDM
[pcn-psdm-encoding] is applied, no PCN egress measurement
functionalities need to be supported to operate admission control.
Admission control is thus operated as suggested by combining
mechanisms already proposed for standardisation.
Assuming that the PCN rate is strictly limited above the PCN-excess-
rate by the links physical bandwidth or by a policer and further
assuming this PCN rate limit to be, say, no more than 10% above the
PCN-excess-rate, then excess marking would result in no more than 10%
of the packets above PCN-excess-rate to be marked. If admission
control is applied to path coupled signaling packets with a
piggybacked probing functionality between PCN boundary nodes (which
consists of setting the ECN field of that signaling packet), starting
to mark only packets above the PCN-excess-rate as "M/CE" once the
latter is passed doesn't result in desirable operational conditions.
As only a small percentage of traffic is marked, most PSDM coded
admission requests have a good chance to pass the pre-congested link
without being marked and lead to admission of new PCN traffic. If
however the operational regime of the excess rate marker is
"inverted", and the percentage of traffic excessing the PCN-excess-
rate is left unmarked (i.e. "NM" coded), then PSDM admission control
will prevent admission of 90% or more of the user sessions requesting
admission. Please note, that the threshold marker still continues to
mark all packets crossing the link and so the excess marker would
indeed have to unmark packets again (if marking is realised eg. by
sequential single rate token buckets).
The marking behaviour as described in pcn-marking-behaviour
[pcn-marking-behaviour] has to further be changed in the following
way to support the functionalities specified by this document.
Two encoding states are available:
Geib Expires March 23, 2009 [Page 4]
Internet-Draft 3state signaling with baseline encoding September 2008
o one for "PCN-marked"
o one for "not PCN-marked".
The metering and marking function MUST be implemented to support the
following threshold and excess-traffic marking functions:
All PCN packets MUST be counted by the PCN meter.
Threshold marking MUST be executed prior to (or simultaneously with)
excess traffic marking.
To threshold mark a packet, its PCN mark is set to "PCN-marked" (M/CE
following pcn-baseline-encoding [pcn-baseline-encoding]).
To excess-traffic mark a packet, its PCN mark is set to "not PCN-
marked" (NM/ECT0 following pcn-baseline-encoding
[pcn-baseline-encoding]).
Additionally, this document has outlined already, that two marking
behaviours are combined with PCN baseline encoding and this so far
isn't part of pcn-marking-behaviour [pcn-marking-behaviour].
The concept is illustrated by Figure 1.
Geib Expires March 23, 2009 [Page 5]
Internet-Draft 3state signaling with baseline encoding September 2008
Rate of ^
PCN-traffic on |
bottleneck link | (as below and also)
| (as below) Drop some PCN-pkts
|
scheduler rate -| -----------------------------------------------
(for PCN-traffic)|
| Some pkts Terminate some
| "not PCN-marked" admitted flows
| & &
| Rest of pkts Block most new flows
| "PCN-marked"
|
PCN-excess-rate -|------------------------------------------------
|
| All pkts Block new flows
| "PCN-marked"
|
PCN-threshold-rate -|------------------------------------------------
|
| All pkts Admit new flows
| "not PCN-marked"
Schematic of how PCN's baseline encoding-3state admission control and
flow termination mechanisms kick in as the rate of PCN-traffic
increases, for a PCN-domain with three encoding states (modified from
[architecture]). pcn-architecture [pcn-architecture].
Figure 1
A way to further increase the probability of blocking new flows
requesting admission, while a PCN interface reached termination state
is to generally "unmark" only a known share of the excess traffic
(say 50% or 10% of the packets to be unmarked at the excess rate
instead of all of them). This however may make it more difficult for
an egress node to correctly determine the termination rate of a small
PCN aggregate that has passed a link in termination state.
3.2. Benefits of three state signaling with PCN baseline encoding
If the behaviour exposed in the case of termination marking allows an
egress node to non ambiguously identify termination state for an
aggregate, then it can request the sources to terminate (or reduce)
their traffic.
As only a single code point is used to signal pre congestion states
and two different marking behaviours indicate the pre-congestion
status, this solution may be deployed within MPLS networks, where
Geib Expires March 23, 2009 [Page 6]
Internet-Draft 3state signaling with baseline encoding September 2008
only 8 Codepoints are available to support DiffServ and ECN.
Finally, it should be noted that by support of PSDM no rate
measurements are required for admission control and that for
termination, the egress node is able to measure traffic rates and
take decisions on termination without having to provide feedback to
another PCN node within its PCN domain.
3.3. Simple experimental deployment
Experimental simulation may not require the development of new code
for policers if egress and ingress policers can be simulated on both
ends of a PCN link. The egress policer of the PCN egress interface
operates the threshold policer at the PCN-threshold-rate. The
ingress policer of the ingress interface of the PCN node connected by
the link is set to meter packets marked as "PCN/CE". Operated in
"excess mode", it starts to mark packets as "PCN/NM", once the rate
of PCN/CE marked packets crosses the "PCN-excess-rate" which it is
configured for. Obviously, the termination threshold MUST be bigger
or equal to the admissible rate configured at the other end of the
link.
Routers supporting ingress and egress policing could also be used,
which would allow experiments with real equipment, if desired.
3.4. Known issues of three state signalling with PCN baseline encoding
The question, whether it is at all possible to infer the current
operational state of one or more pre-congested interface(s) of a PCN
domain by interpretation of the marking behaviour observed by the PCN
egress nodes can't be answered yet. This section lists a few
operational conditions under which the proposed two state marking
three state signaling method must work reliably or reasonably stable,
respectively.
o Differing oscillating "admission"/"admission stop" state from
termination state. This operational condition is likely to be
present and the egress node MUST be able to reliably differ
admission stop state from termination, if such oscillating
"admission"/"admission stop" state is occurring.
o Admission of sessions during termination state. As a certain
percentage of packets will pass the pre congested interface
unmarked during termination state, a number of new sessions will
be admitted while others are terminated. The egress nodes MUST be
able to terminate more traffic swiftly to push the PCN traffic
rate below the PCN-excess-rate despite admission of new sessions
while this link is in termination state.
Geib Expires March 23, 2009 [Page 7]
Internet-Draft 3state signaling with baseline encoding September 2008
o If traffic that has passed a PCN interface in termination state
later on passes a PCN interface in admission stop state, an end
node will no longer be able to recognise the termination state of
the prior PCN node, as all packets passing the interface in
admission stop state will be "PCN-marked".
o If traffic that has passed a PCN interface in termination state
later on passes another PCN interface in termination state, an end
node will only recognise the termination state of the last PCN
node by the relation of "not PCN-marked" to "PCN-marked" packets
as created by the last interface in termination mode.
4. Acknowledgements
Thanks to Ana Charney, Bob Briscoe and Joe Babiarz for brief
discussions on the idea and thanks to Steven Blake for the
opportunity to present 3 slides on the idea. Thanks also to Mayutan
Arumaithurai of University of Goettingen for a review of this draft.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The security section of pcn-architecture [pcn-architecture] applies
also to this draft. It does not introduce additional security
issues.
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.
7.2. Informative References
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008.
[pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture",
draft -ietf-pcn-architecture-05, (work in progress),
Geib Expires March 23, 2009 [Page 8]
Internet-Draft 3state signaling with baseline encoding September 2008
August 2008.
[pcn-baseline-encoding]
Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
draft -moncaster-pcn-baseline-encoding-02, (work in
progress), July 2008.
[pcn-marking-behaviour]
Eardley, P., "Marking behaviour of PCN-nodes", draft -
eardley-pcn-marking-behaviour-01 (work in progress),
June 2008.
[pcn-psdm-encoding]
Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe,
"PCN Encoding for Packet-Specific Dual Marking (PSDM)",
draft -menth-pcn-psdm-encoding-00 (work in progress),
July 2008.
Author's Address
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt, 64295
Germany
Phone: +49 6151 628 2747
Email: Ruediger.Geib@telekom.de
Geib Expires March 23, 2009 [Page 9]
Internet-Draft 3state signaling with baseline encoding September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Geib Expires March 23, 2009 [Page 10]