PCN K. Chan
Internet-Draft Nortel
Intended status: Informational T. Moncaster
Expires: August 10, 2008 BT Research
M. Menth
University of Wurzburg
G. Karagiannis
University of Twente
P. Eardley
B. Briscoe
BT Research
February 7, 2008
Pre-Congestion Notification Encoding Comparison
draft-chan-pcn-encoding-comparison-02
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 August 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Chan, et al. Expires August 10, 2008 [Page 1]
Internet-Draft Document February 2008
Abstract
A number of mechanisms have been proposed to support differential
Qualiy of Service for packets in the Internet. DiffServ is an
example of such a mechanism. However, the level of assurance that
can be provided with DiffServ without substantial over-provisioning
is limited. Pre-Congestion Notification (PCN) uses path congestion
information across a PCN region to enable per-flow admission control
to provide the required service guarantees for the admitted traffic.
While admission control will protect the QoS under normal operating
conditions, an additional flow termination mechanism is necessary to
cope with extreme events (e.g. route changes due to link or node
failure).
In order to allow the PCN mechanisms to work it is necessary for IP
packets to be able to carry the pre-congestion information to the PCN
egress nodes. This document explores different ways in which this
information can be encoded into IP packets. This document does not
choose the encoding but provide guidance and recommendation based on
different criteria.
Chan, et al. Expires August 10, 2008 [Page 2]
Internet-Draft Document February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Encoding Requirements . . . . . . . . . . . . . . . . . . . . 5
2.1. Encoding States . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Non PCN Capable Packet Encoding State . . . . . . . . 6
2.1.2. Nonce Encoding State . . . . . . . . . . . . . . . . . 7
2.2. Encoding Selection Criteria . . . . . . . . . . . . . . . 7
3. Encoding Options . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Encoding Using ECN and DSCP Fields . . . . . . . . . . . . 9
3.1.1. Benefits of Using DSCP and ECN Fields . . . . . . . . 10
3.1.2. Drawbacks of Using DSCP and ECN Fields . . . . . . . . 11
3.1.3. Comparing DSCP and ECN Fields Encoding Options . . . . 11
3.1.4. Concerns on Alternate Semantics for the ECN Field . . 11
3.1.5. Encoding Choice Considerations . . . . . . . . . . . . 14
3.2. Encoding Using DSCP Field . . . . . . . . . . . . . . . . 14
3.2.1. Benefits of Using DSCP Field . . . . . . . . . . . . . 15
3.2.2. Drawbacks of Using DSCP Field . . . . . . . . . . . . 15
3.2.3. Comparing DSCP Field Encoding Options . . . . . . . . 15
4. Encoding Recommendations . . . . . . . . . . . . . . . . . . . 16
5. Security Implications . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Encoding Using ECN Field . . . . . . . . . . . . . . 17
Appendix A.1. Benefits of Using ECN Field . . . . . . . . . . . . 18
Appendix A.2. Drawbacks of Using ECN Field . . . . . . . . . . . . 19
Appendix A.3. Concerns on Alternate Semantics for the ECN Field . 19
Appendix A.4. Encoding Choice Considerations . . . . . . . . . . . 22
Appendix B. Out-of-Band Channel as Encoding Transport . . . . . 22
Appendix B.1. Benefits of Using Out-Of-Band Channel . . . . . . . 23
Appendix B.2. Drawbacks of Using Out-Of-Band Channel . . . . . . . 23
Appendix C. Current PCN Detection, Marking and Transport
Mechanisms . . . . . . . . . . . . . . . . . . . . . 23
Appendix C.1. Detection, Marking and Transport Mechanisms in
CL-PHB . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C.2. Detection, Marking and Transport Mechanisms in
Three State Marking . . . . . . . . . . . . . . . . 23
Appendix C.3. Detection, Marking and Transport Mechanisms in
Single Marking . . . . . . . . . . . . . . . . . . . 24
Appendix C.4. Detection, Marking and Transport Mechanisms in
Load Control Marking . . . . . . . . . . . . . . . . 24
8. Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Chan, et al. Expires August 10, 2008 [Page 3]
Internet-Draft Document February 2008
1. Introduction
This document examines the ways to encode pre-congestion notification
(PCN) [1] information in IP packets for transporting the information
from the PCN interior nodes to the PCN egress nodes. Using the
examination results to assist the selection of PCN encoding in IP
packets.
This document first discuss the PCN information that is required to
be transported. Then investigate the different fields in the IP
header for transporting the required PCN information. Followed with
the encoding choices, discussions, and recommendations, when specific
field(s) of the IP header is/are used to transport the PCN
information.
The main goal of this document is a survey and comparison of several
encoding methods that are required to encode the pre-congestion
information and to transport it from the PCN interior nodes to the
PCN egress nodes. In order to accomplish this comparison, a number
of criteria are developed. For transporting using data packet (IP)
header, the encoding methods investigated are:
1. Encoding using the combination of the ECN and DSCP bits of a data
packet header
2. Encoding using only the DSCP bits of a data packet header
We have also considered:
1. Encoding using only the ECN bits of a data packet header
2. Encoding and transport using a different channel than data
packets
But these have been considered out of scope for the current PCN
Charter and hence moved to the Appendix sections. Keeping them for
this version of the document to not loose our understanding of them
and for completeness of the survey.
The rest of this document is organized as follows:
o Section 2 describes the encoding requirements indicated by
currently known detection and marking mechanisms that can be used
within the PCN-domain.
o Section 3 describes the encoding options, organized based on the
IP header field(s) used for the encoding.
Chan, et al. Expires August 10, 2008 [Page 4]
Internet-Draft Document February 2008
o Section 4 provides a summary on the encoding options
recommendation.
2. Encoding Requirements
The internal PCN encoding requirements are based on the functionality
of PCN [1], and possibly how the PCN Marking Algorithms achieve the
functionality. There may be external requirements depending on the
environment in which PCN operates, for example co-existence with ECN
as indicated by RFC 4774 [22]. These are discussed secondary to the
internal PCN encoding requirements because we have limited the PCN
operational environment in the PCN WG's first phase charter. But we
also need to take into consideration of the encoding standard should
not need to be modified for PCN to work in both current charter's
environment and when current charter's environment is expanded.
2.1. Encoding States
Currently, there are a number of proposals for Pre-Congestion
Detection Algorithms. The authors of the different PCN Algorithm
documents have agreed to use the notion of Encoding States to
represent the information each algorithm wants to export, and hence
to be carried from the interior nodes to the edge nodes for flow
admission control and flow termination decisions. These Encoding
States form the fundamental functional requirements for the encoding
choices.
Please notice the number of "Encoding State" can be different from
the number of encoding bit patterns. For example more than two
"Encoding States" may be carried by two encoding bit pattern when the
multiple "Encoding States" can be modulated/ multiplexed over some
time domains.
For simplicity purpose, we indicate the main required encoding states
for PCN capable packets:
o Not PreCongested Marking for PCN traffic (PCN), for indication of
No Pre-Congestion Indication for PCN capable traffic
o Admission Marking (AM), for indication of Flow Admission
Information
o Termination Marking (TM), for indication of Flow Termination
Information
o Affected Marking (AfM), for ECMP Information.
Chan, et al. Expires August 10, 2008 [Page 5]
Internet-Draft Document February 2008
A total of four main required encoding states for PCN capable
packets.
There are also encoding states that may be required, depending on the
environment assumptions made, these encoding states are described in
the following sub sections together with their environmental
considerations.
2.1.1. Non PCN Capable Packet Encoding State
Non PCN Capable packet encoding, for separation from PCN Capable
packet. This encoding allows the PCN nodes to provide the PCN
treatments to only the PCN Capable packets. Allowing separation
between PCN Capable and Non PCN Capable packets.
The Working Group assumes the PCN traffic will be identified by the
DSCP codepoint it carries. But the precise meaning of this is not
entirely clear. There is a question whether:
1. a DSCP is meant to only represent a scheduling behaviour and
(pre-)congestion marking behaviour is an optional addition that
needs to be turned on or off within each existing DSCP (as for
RFC3168 ECN), or
2. we redefine the meaning of the DSCP field to represent a
combination of scheduling and marking behaviour.
If the first approach is used, for certain PHBs (e.g. EF [rfc3246])
PCN marking would be the congestion marking behaviour turned on by
the setting of another field (e.g. the ECN field). Then there would
be a need to further distinguish PCN from Not-PCN packets, both using
the same DSCP. Requiring a Non PCN Capable Encoding State
represented by a bit pattern using bits outside of the DSCP field.
In the second approach, for each scheduling behaviour needing to be
combined with PCN marking, a new paired DSCP would need to be
defined. Then both DSCPs would map to the same scheduling behaviour
but one will and one will not receive PCN treatment. For this
approach, the DSCP provides the indication of PCN Capable packets.
Hence the decision of taking approach one or approach two will
indicate if Non PCN Capable Packet Encoding State will be necessary.
When the Non PCN Capable Packet Encoding State is needed, we use the
encoding of Not-PCN Capable (Not-PCN) to represent this state. The
use of the other required PCN Encoding States will indicate this is a
PCN Capable Packet.
Chan, et al. Expires August 10, 2008 [Page 6]
Internet-Draft Document February 2008
Superficially, the proposed new DSCP for capacity-admitted traffic
[6] seems like it could turn on PCN marking with EF scheduling
(approach 2). In this document an early version of PCN is given as
an example of schemes that might need to use the new voice-admit
codepoint. But the proposed new DSCP for capacity-admitted traffic
[6] is really intended to distinguish EF traffic that is admission
controlled per flow at the edge of a Diffserv domain from EF traffic
merely policed in bulk. The new codepoint is not really intended to
switch on a new marking behaviour like PCN.
2.1.2. Nonce Encoding State
The ECN nonce RFC 3540 [19] for end-to-end ECN is used to protect the
sender from cheating by the receiver and/or by other down stream
nodes. PCN may or may not need a mechanism like the ECN nonce.
However single bit nonce schemes such as the ECN nonce require in-
order, reliable data delivery to function correctly. As PCN operates
at the IP layer, in-order delivery cannot be guaranteed. If PCN
needs a nonce functionality, it may need to think beyond the current
ECN nonce mechanism. And this is beyond the scope of this document.
Currently, the PCN work we are doing assumes the trust relationship
between all the functional entities are already established. If this
assumption is not true, the trust relationships will need to be
addressed, but may or may not involve the needing of additional
encoding states or the use of the ECN nonce mechanism.
2.2. Encoding Selection Criteria
Two possible locations within the IP header have been identified as
suitable for encoding PCN. These are the 2 bit ECN field whose
default meaning is defined in RFC 3168 [16] and the 6 bit DSCP field
defined in RFC 2474 [11] and RFC 2475 [12]. It is already accepted
that PCN traffic will be distinguished according to which DSCP
codepoint it carries. The implications of this decision were
discussed in section 2.1.1 above. The current assumption is that PCN
will need to be specified as the marking behaviour through definition
of a new PCN DSCP.
There are a number of other potential issues that might affect the
exact choice of encoding to be used. The key ones are:
1. The support of the required encoding states to satisfy the
functional requirement of PCN.
2. Compliance with RFC 4774 [22] if the ECN field is to be re-used
for PCN encoding.
Chan, et al. Expires August 10, 2008 [Page 7]
Internet-Draft Document February 2008
3. Compliance with the requirements for specifying DSCPs and DSCP
per-hop-behaviour groups [11].
Each of these are examined in further details in encoding option
sections describing their usage.
RFC 4774 [22] have also required one to give consideration to what
harm might be caused by the leaking of PCN traffic into a non-PCN
domain. The following looks at each ECN codepoint and shows what
harm, if any, would be caused were that codepoint to leak from the
PCN domain:
o '00': The leak should be safe in all circumstances. RFC 3168
compliant routers will believe such packets to be not-ECN capable
and as such will drop them if the router is congested. This
codepoint may be suitable for different use by PCN.
o '01' and '10': RFC 3168 compliant routers will believe these
packets are from an ECN capable flow. If the routers are
congested they will mark these packets '11' (CE) instead of
dropping them. If the endpoints are not ECN capable then this is
not good for congestion control. The use of '01' and '10' by PCN
can be a potential issue. To be completely safe, it would be best
to avoid giving any PCN semantics to these codepoints.
o '11': If the packet was already part of an ECN capable flow then
receivers will believe this was an indication of congestion on the
path. They will thus inform their source of this and the source
will perform a congestion response. This codepoint may be
suitable for different use by PCN, the degree of suitability may
depend on the exact PCN encoding and the metering and marking
algorithm using the encoding.
More detailed consideration of these points are provided in the
sections describing the encoding options.
Additional criterion of handling ECN packets traversing the PCN
domain brings up the notion of tunneling in the PCN domain. As
indicated earlier, the working group is using a different DSCP to
indicate a PHB for PCN packets. We can take the view of using such
DSCP, hence the PCN PHB, as handling the PCN packets in its own
tunnel. And the other non-PCN packets are in one or more other
tunnels. Taking this view allows us to totally separate the PCN and
non-PCN (including ECN) traffic using DiffServ. Allowing an easy
solution for ECN packets traversing the PCN domain. With violation
of such traffic separation be considered leakage of other traffic
into the PCN domain and leakage of PCN traffic out of the PCN domain.
Chan, et al. Expires August 10, 2008 [Page 8]
Internet-Draft Document February 2008
With the above discussion, in additon to the criteria indicated so
far, we should give higher preference to encoding options that:
o Minimize problems if there are packet leakage by the PCN domain.
o Is safest for wider deployment of PCN, when the current chartered
environment restriction is relaxed.
3. Encoding Options
There are couple of methods to carry the encoding states. The method
used affects the encoding options. Hence when we describe the
different encoding options in this section, we group them based on
how the encoding states are carried.
The encoding transport methods considered are:
o using the combination of the ECN and DSCP bits of a data packet
header
o using only the ECN bits of a data packet header
o using only the DSCP bits of a data packet header
We discuss the encoding options for each of the encoding transport
methods separately in their own subsections. For shorter reading, we
have moved the encoding choices the working group have agreed to not
consider (Using only ECN field, Out-of-Band Channel) sections to the
Appendix.
3.1. Encoding Using ECN and DSCP Fields
The use of both DSCP and ECN fields is following the second approach
indicated in section 2.1.1. This approach allows a clean traffic
treatment separation of PCN Capable traffic and Non PCN Capable
traffic. This natural use of the DSCP field, to provide treatment
differentiation of packets using different DSCP encoding, is one way
of providing the "PCN Capable Transport Marking" encoding state. The
using of this approach allows us to focus on encoding the four
required PCN Encoding States indicated in section 2.1 using the two
ECN bits.
Chan, et al. Expires August 10, 2008 [Page 9]
Internet-Draft Document February 2008
-----------------------------------------------------------------------
| ECN Bits || 00 | 01 | 10 | 11 || DSCP |
|==============++==========+==========+==========+==========++==========|
| RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA |
|==============++==========+==========+==========+==========++==========|
| Option 1 || AM | PCN | PCN | TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 2 || AfM | PCN | PCN | AM/TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 3 || PCN | NA | NA | AM/TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 4 || PCN | NA | NA | AM || PCN 1 |
| || | | | TM || PCN 2 |
|--------------++----------+----------+----------+----------++----------|
| Option 5 || AM | TM | PCN | NA || PCN |
-----------------------------------------------------------------------
Notes: NA means Not Applicable. PCN, PCN 1, PCN 2 under the DSCP
column denotes specific DSCPs used for PCN capable packets. AM/TM
means the two encoding states are sharing the same encoding bit
pattern.
Figure 1: Encoding of PCN Information Using DSCP and ECN Fields
In Figure 1, we listed the fundamental options when both DSCP and ECN
fields are used. There are couple of variations of the theme
provided by these options. For example, the "01" and "10" encoding
can be interpreted as PCN(A) and PCN(T) instead of just PCN. Using
the PCN(A) and PCN(T) variation provides the additional information
of the ratio of packets AM marked to packets Not AM marked, and the
ratio of packets TM marked to packets Not TM marked. Having these
ratios being independent from one another. Another variation on the
theme is the use of an extra DSCP value to represent the TM encoding
state for Option 2. Doing so will eliminate the need to modulate
both AM and TM using the single "11" encoding.
Notice the Affected Mark encoding state is not directly carried by
the ECN bits in Option 1. A variation of Option 1 is to represent
the Affected Mark encoding state using '01'. But this may result in
interference by RFC 3168 ECN routers when there is mis-configuration,
please see section 3.1.4 on discussion of RFC 4774 Concern 2 for more
details.
3.1.1. Benefits of Using DSCP and ECN Fields
A major feature of using both DSCP and ECN fields is the ability to
use the inherent nature of DiffServ for traffic class separation to
allow PCN treatment be applied to PCN traffic, without concerns of
Chan, et al. Expires August 10, 2008 [Page 10]
Internet-Draft Document February 2008
applying PCN treatment to none PCN traffic and vise versa. This
feature frees this approach for PCN encoding from some of the
concerns raised by RFC 4774 [22]. This feature will also keep none
PCN Capable traffic out of the PCN treatment mechanisms, allowing the
PCN treatment mechanisms focus on their respective PCN tasks.
This approach also leaves the ECN field available totally for PCN
encoding states purposes. Removing the need to carry the Not-PCN
Encoding in the ECN field.
3.1.2. Drawbacks of Using DSCP and ECN Fields
The use of both DSCP and ECN fields will require the setting aside of
one (or possibly two) DSCP for use by PCN. This may add complexity
to the PCN encoding standardization effort.
3.1.3. Comparing DSCP and ECN Fields Encoding Options
Here we discuss the differences between the different encoding
options when both DSCP and ECN fields are used. There are many
encoding options, we have provided the ones we think are favorable in
Figure 1.
When DSCP is used to differentiate between PCN capable and Not-PCN
capable traffic, the encoding of "Not-PCN" in the ECN field is not
required. This is the motivation for Option 1 in Figure 1, where the
encoding "00" for "Not-ECT" is being used for "AM" (Admission
Marking) encoding state. The encodings "01" and "10" for "ECT(1)"
and "ECT(0)" supports the required encoding states for "Not Pre-
Congested Marking" (PCN), and reserving them for any "Nonce Marking"
if necessary. With the possible additional encoding of "PCN(A)" and
"PCN(T)" in place of "ECT(1)" and "ECT(0)" for indicating percentage
of Admission Marked traffic and percentage of Termination Marked
traffic when the algorithm benefits from such additional information.
Option 2 in Figure 1 uses the "00" encoding for "AfM". With '01' and
'10' encoding the same as for Option 1, requiring the use of "11"
encoding for both "AM" (Admission Mark) and "TM" (Termination Mark)
states or requiring the allocation of a DSCP for encoding the "TM"
state.
3.1.4. Concerns on Alternate Semantics for the ECN Field
Section 2 of RFC 4774 [22] raised couple of concerns for usage of
alternate semantics for the ECN field. We try to address each of the
concerns in this section.
Chan, et al. Expires August 10, 2008 [Page 11]
Internet-Draft Document February 2008
1. Section 3.1 of RFC 4774 [22] discusses Concern 1: "How routers
know which ECN semantics to use with which packets." This use of
DSCP and ECN for encoding PCN states address this by following
the recommendation of RFC 4774 [22] on using a diffserv codepoint
to identify the packets using the alternate ECN semantics. This
diffserv codepoint may possibly be a new diffserv codepoint to
minimize the possible confusion between using the old per hop
behavior of the codepoint and the using of the alternate ECN
semantics per hop behavior of the codepoint.
2. Section 4 of RFC 4774 [22] discusses Concern 2: "How does the
possible presence of old routers affect the performance of the
alternate ECN connections." With the notion of old routers
meaning routers that performs RFC 3168 ECN processing instead of
PCN processing. The easy answer is the environment using the
alternate ECN semantics is envisioned to be within a single
administrative domain. With the ability to ensure that all
routers along the path understand and agree to the use of the
alternate ECN semantics for the traffic identified by the use of
a diffserv codepoint. This uses option 2 indicated in section
4.2 of RFC 4774 [22]. But incase there is mis-configuration, the
choice of encoding may make a difference:
* With encoding Option 1, the old routers will interprete:
+ '00' encoding as Not-ECT, and will drop AM marked packets.
The PCN edge nodes should not admit traffic that it does
not receive, hence the PCN admission functionality should
be OK.
+ '01' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
The RFC 3168 ECN CE encoding have the same functionality as
the PCN TM encoding, to reduce the offered traffic load.
Hence the PCN termination functionality should be OK.
+ '10' encoding as ECT(0). The discussion for '01' above
applies equally to this encoding.
+ '11' encoding as CE. The old router should use this
encoding to reduce the offered traffic load and should not
remark this to any other ECN encoding, the same
functionality the PCN TM encoding requires, hence should be
OK for PCN.
The above discussion for Option 1 applies equally for PCN
traffic leaked out of the PCN domain and interpreted by RFC
3168 ECN nodes.
Chan, et al. Expires August 10, 2008 [Page 12]
Internet-Draft Document February 2008
* With encoding Option 2, the old routers will interprete:
+ '00' encoding as Not-ECT, and will drop AfM marked packets.
This may possibly affect the efficiency of the Affected
Marking functionality.
+ '01' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
The RFC 3168 ECN CE encoding have the same functionality as
the PCN TM encoding, to reduce the offered traffic load.
Depending on the PCN algorithm on how AM and TM share the
same '11' encoding, this may or may not affect the
functionality of PCN.
+ '10' encoding as ECT(0). The discussion for '01' above
applies equally to this encoding.
+ '11' encoding as CE. The old router should use this
encoding to reduce the offered traffic load and should not
remark this to any other ECN encoding. Depending on the
PCN algorithm on how AM and TM share the same '11'
encoding, this may or may not affect the functionality of
PCN.
The above discussion for Option 2 applies equally for PCN
traffic leaked out of the PCN domain and interpreted by RFC
3168 ECN nodes.
3. Concern 3: "How does the possible presence of old routers affect
the coexistence of the alternate ECN traffic with competing
traffic on the path." Within the PCN domain, the PCN (alternate
ECN) traffic is separated from the other traffic using diffserv.
If by mis-configuration, an old routers that does not understand
PCN handles PCN traffic, the PCN traffic will get the per hop
behavior as the other traffic, hence not receiving the benefits
of PCN at the old router, but will not affect the coexistence of
the PCN and the other traffic. If the old router uses RFC 3168
ECN congestion treatment, then the discussion for Concern 2 above
applies.
4. Concern 4: "How well does the alternate ECN traffic perform."
The performance of the different proposed PCN (alternate ECN)
metering and marking algorithms are currently under study with
their simulation and study results described by their respective
documents.
The environment using the alternate ECN semantics is envisioned to be
within a single administrative domain. With the ability to ensure
Chan, et al. Expires August 10, 2008 [Page 13]
Internet-Draft Document February 2008
that all routers along the path understand and agree to the use of
the alternate ECN semantics for the traffic identified by the use of
a diffserv codepoint. This uses option 2 indicated in section 4.2 of
RFC 4774 [22].
3.1.5. Encoding Choice Considerations
o If three encoding states need to be separately represented, Option
1 is recommended.
o If two encoding states need to be separately represented, for
example the marking algorithm allows the AM and TM encoding states
be represented using the same bit pattern, Options 2 and 3 are
recommended.
o If RFC 4774 [22] concerns need to be addressed by PCN encoding,
then Option 1 is recommended, please see section 3.1.4 for the
detail discussion. Options 2 and 3 may be able to address the RFC
4774 [22] concerns, but a heavier burden is placed on the metering
and marking algorithms to differentiate between TM and AM meaning
of the '11' encoding when a RFC 3168 ECN router sets the '11'
encoding.
o If the metering and marking algorithm requires the use of Affected
Marking encoding state, Option 2 is recommended. Alternatively
one of the bit patterns of '01' or '10' may be used for the AfM
purpose. But using '01' or '10' bit patterns for AfM may increase
the interference between RFC 3168 ECN and PCN encodings, please
see section 3.1.4 for the detail discussion.
o If Option 1 is used and the functionality of Affected Marking
encoding state is required, the metering and marking algorithms
will need to provide this functionality without the use of the
Affected Marking encoding state.
3.2. Encoding Using DSCP Field
In this type of encoding and transport method the congestion and
precongestion information is encoded into the 6 DSCP bits that are
transported in the IP header of the data packets. Four possible
alternatives can be distinguished, as can be seen in Figure 3, with
details provided by draft-westberg-pcn-load-control-02.txt [4].
Option 7 needs 2 additional DSCP values, Options 8 and 9 need three
additional DSCP values and Option 10 needs four additional DSCP
values. Note that all additional and experimental DSCP values are
representing and are associated with the same PHB. The 1st, 2nd,
3rd, and 4th DSCP values are representing DSCP values that are
assigned by IANA as DSCP experimental values, see RFC 2211 [9].
Chan, et al. Expires August 10, 2008 [Page 14]
Internet-Draft Document February 2008
-----------------------------------------------------------------------
| DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 |
|===========++==========+===========+===========+===========+===========|
| Option 6 || Not-PCN | PCN | AM/TM | NA | NA |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 7 || Not-PCN | PCN | AM/TM | AfM | NA |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 8 || Not-PCN | PCN | AM | TM | NA |
|-----------++----------+-----------+-----------+-----------+-----------|
| Option 9 || Not-PCN | PCN | AM | TM | AfM |
-----------------------------------------------------------------------
Notes: Not-PCN means the packet is not PCN capable.
Figure 2: Encoding of PCN Information Using DSCP Field
3.2.1. Benefits of Using DSCP Field
The main benefit of using the DSCP field is that it is not affecting
the end-to-end ECN semantics and therefore the issues and concerns
raised in RFC 4774 [22] are not applicable for this encoding scheme.
Another benefit is related to the fact that all 4 DSCP encoding
options depicted in Figure 3 can support the PCN capable not
congested (PCN) indication, the admission control (AM) and flow
termination (TM) encoding states. In addition Option 8 and 10 can
support the ECMP solution.
3.2.2. Drawbacks of Using DSCP Field
This type of encoding needs to use per PHB, in addition to the
original DSCP and depending on the encoding option used, one, two,
three, or four DSCP values, respectively. These additional DSCP
values can be taken from the DSCP values that are not defined by
standards action, see RFC 2211 [9]. Note that all the additional
DSCP values are representing and are associated with one PHB. The
value of this DSCP/PHB can either follow a standards action or use a
value that is applied for experimental or local use. It is important
to note that the number of the DSCP values used for local or
experimental use is restricted and therefore the number of different
PHBs supported in the PCN domain will also be restricted.
3.2.3. Comparing DSCP Field Encoding Options
Option 6 can support the basic encoding states, i.e,.not PCN, not
congested PCN (PCN), and the AM/TM encoding states. Option 7 can
support the basic encoding states supported by Option 6, but in
addition it can support the AfM state. Option 8 can support the
following basic encoding states: not PCN, not congested PCN(PCN), AM
Chan, et al. Expires August 10, 2008 [Page 15]
Internet-Draft Document February 2008
and TM states. Option 9 can support the states supported by Option
8, but in addition it can support the AfM state.
4. Encoding Recommendations
5. Security Implications
Packets from normal precedence and higher precedence sessions [24]
aren't distinguishable by PCN Interior Nodes. This prevents an
attacker specifically targeting, in the data plane, higher precedence
packets (perhaps for DoS or for eavesdropping). However, PCN End
Nodes can access this information to help decide whether to admit or
terminate a flow. The separation of network information provided by
the Interior Nodes and the precedence information at the PCN End
Nodes allows simpler, easier and better focused security enforcement.
PCN End Nodes police packets to ensure a flow sticks within its
agreed limit. This is similar to the existing IntServ behaviour.
Between them the PCN End Nodes must fully encircle the PCN-Region,
otherwise packets could enter the PCN-Region without being subject to
admission control, which would potentially destroy the QoS of
existing flows.
It is assumed that all the Interior Nodes and PCN End Nodes run PCN
and trust each other (ie the PCN-enabled Internet Region is a
controlled environment). For instance a non-PCN router wouldn't be
able to alert that it's suffering pre-congestion, which potentially
would lead to too many calls being admitted (or too few being
terminated). Worse, a rogue router could perform attacks such as
marking all packets so that no flows were admitted.
So security requirements are focussed at specific parts of the PCN-
Region:
The PCN End Nodes become the trust points. The degree of trust
required depends on the kinds of decisions it has to make and the
kinds of information it needs to make them. For example when the
PCN End Node needs to know the contents of the sessions for making
the decisions, when the contents are highly classified, the
security requirements for the PCN End Nodes involved will also
need to be high.
PCN-marking by the Interior Nodes along the packet forwarding path
needs to be trusted, because the PCN End Nodes rely on this
information.
Chan, et al. Expires August 10, 2008 [Page 16]
Internet-Draft Document February 2008
6. IANA Considerations
To be completed.
7. Acknowledgements
To be completed.
Appendix A. Encoding Using ECN Field
This section takes the approach 1 option indicated in section 2.1.1.
Which the DSCP field only indicates the packet forwarding behavior,
for which both PCN Capable and Non PCN Capable traffic use/share the
same DSCP. This approach requires the use of the Not PCN Capable
Encoding State to be encoding using the ECN bits. Hence this section
describes the encoding options that uses only the ECN field (without
the DSCP field) available in the IP header of the data packets to
encode the PCN states.
The use of the same DSCP for both PCN Capable and Non PCN Capable
also opens the question of having PCN and RFC 3168 ECN traffic using
the same DSCP. Which increases the importance of satisfying the
concerns indicated in RFC 4774.
-----------------------------------------------------------------------
| ECN Bits || 00 | 01 | 10 | 11 || DSCP |
|==============++==========+==========+==========+==========++==========|
| RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA |
|==============++==========+==========+==========+==========++==========|
| Option 10 || Not-PCN | AM | PCN | TM || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 11 || Not-PCN | PCN | PCN | AM/TM || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 12 || Not-PCN | AfM | PCN | AM/TM || NA |
-----------------------------------------------------------------------
Figure 3: Encoding of PCN Information Using ECN Field
In Figure 2, we listed the fundamental options when only the ECN
field is used. Like in Figure 1, there are variations of the theme
provided by these options. For example, when both "01" and "10"
encoding are used for NPM in Option 4, they can be interpreted as
PCN(A) and PCN(T) instead of just PCN. Using the PCN(A) and PCN(T)
variation provides the additional information of the ratio of packets
AM marked to packets Not AM marked, and the ratio of packets TM
Chan, et al. Expires August 10, 2008 [Page 17]
Internet-Draft Document February 2008
marked to packets Not TM marked. Having these ratios being
independent from one another.
For Option 10, the use of '01' for AM and '10' for PCN can be swapped
and provide the same functionality. For Option 12, the use of '01'
for AfM and '10' for PCN can also be swapped without change of
functionality.
Appendix A.1. Benefits of Using ECN Field
The using of only the ECN field for encoding PCN encoding states
allow more efficient use of the DSCP field, not requiring the
allocation of PCN specific DSCP values.
This approach also opens the question of possibly having both PCN and
ECN traffic using the same DSCP.
When the same treatment can be provided to both ECN and PCN traffic
to achieve each of ECN and PCN purpose, then not having DiffServ as
separation between ECN and PCN traffic may be a benefit. Under such
circumstances, having the same encoding between ECN and PCN may be
desireable. But this can only be true if the requirement set forth
in RFC 4774 [22] for alternate ECN semantics can be satisfied.
If the same treatment can be applied to both ECN and PCN traffic,
then:
o The first issue of RFC 4774 [22]: "How routers know which ECN
semantics to use with which packets." may be solved because there
are no difference in the treatments of ECN and PCN packets, hence
they can use the same semanics.
o The second and third issues of RFC 4774 [22]: "How does the
possible presence of old routers affect the performance of the
alternate ECN connections." and "How does the possible presence of
old routers affect the coexistence of the alternate ECN traffic
with competing traffic on the path." are also solved because there
are no difference in the treatment of ECN and PCN packets.
o The forth issue of RFC 4774 [22]: "How well does the alternate ECN
traffic perform." are dependent on the algorithm used, and should
be provided by the respective algorithm document, and not in the
scope of this document.
Chan, et al. Expires August 10, 2008 [Page 18]
Internet-Draft Document February 2008
Appendix A.2. Drawbacks of Using ECN Field
Notice this group of encoding options does not use DiffServ code
points for PCN encoding. With this group of encoding options, the
required states of "PCN Capable Transport"/"None PCN Capable
Transport" must be encoded using the ECN field. Leaving less
encoding real estate to carry the remaining required PCN encoding
states. Another drawback is without the protection/separation
capability provided by DiffServ, it is typically harder to satisfy
the requirement set forth in RFC 4774 [22] for alternate ECN
semantics.
Appendix A.3. Concerns on Alternate Semantics for the ECN Field
Section 2 of RFC 4774 [22] raised couple of concerns for usage of
alternate semantics for the ECN field. We try to address each of the
concerns in this section.
1. Section 3.1 of RFC 4774 [22] discusses Concern 1: "How routers
know which ECN semantics to use with which packets." When this
group of PCN encodings are used without the use of DSCP, routers
can not distinguished PCN encoded packets from RFC 3168 ECN
encoded packets. Hence there needs to be some kind of
differentiation between PCN and RFC 3168 ECN packets, may be
using PCN for real-time traffic types (with specific DSCP) and
ECN for elastic traffic (with specific DSCP). And only
distinguishing PCN Capable and Non-PCN Capable packets in real-
time traffic. Only distinguishing ECT and Not-ECT packets in
elastic traffic. But not having PCN and ECN traffic together.
2. Section 4 of RFC 4774 [22] discusses Concern 2: "How does the
possible presence of old routers affect the performance of the
alternate ECN connections." With the notion of old routers
meaning routers that performs RFC 3168 ECN processing instead of
PCN processing, or drop packets instead of encoding the
congestion information. The easy answer is the environment using
the alternate ECN semantics is envisioned to be within a single
administrative domain. With the ability to ensure that all
routers along the path understand and agree to the use of the
alternate ECN semantics for the traffic identified to be PCN
Capable. This uses option 2 indicated in section 4.2 of RFC 4774
[22]. But incase there is mis-configuration, the choice of
encoding may make a difference:
* With encoding Option 10, the old routers will interprete:
+ '00' encoding as Not-ECT, and will drop Not-PCN marked
packets when congestion is detected. With '00' the
Chan, et al. Expires August 10, 2008 [Page 19]
Internet-Draft Document February 2008
encoding for Not-PCN, requiring the same functionality as
Not-ECT, the presence of old routers will not affect the
performance of PCN functionality.
+ '01' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
For Option 3, the old router can possibly remark AM to TM.
This puts a burden on the metering and marking algorithms
to treat TM encoded packets to indicate stop admission.
This may or may not be acceptable, depending on the
algorithm.
+ '10' encoding as ECT(0), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
The RFC 3168 ECN CE encoding have the same functionality as
the PCN TM encoding, to reduce the offered traffic load.
Hence the PCN termination functionality should be OK.
+ '11' encoding as CE. The old router should use this
encoding to reduce the offered traffic load and should not
remark this to any other ECN encoding, the same
functionality the PCN TM encoding requires, hence should be
OK for PCN.
The above discussion for Option 10 applies equally for PCN
traffic leaked out of the PCN domain and interpreted by RFC
3168 ECN nodes.
* With encoding Option 11, the old routers will interprete:
+ '00' encoding as Not-ECT, and will drop Not-PCN marked
packets when congestion is detected. With '00' the
encoding for Not-PCN, requiring the same functionality as
Not-ECT, the presence of old routers will not affect the
performance of PCN functionality.
+ '01' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
The RFC 3168 ECN CE encoding have the same functionality as
the PCN TM encoding, to reduce the offered traffic load.
Depending on the PCN algorithm on how AM and TM share the
same '11' encoding, this may or may not affect the
functionality of PCN.
+ '10' encoding as ECT(0). The discussion for '01' above
applies equally to this encoding.
Chan, et al. Expires August 10, 2008 [Page 20]
Internet-Draft Document February 2008
+ '11' encoding as CE. The old router should use this
encoding to reduce the offered traffic load and should not
remark this to any other ECN encoding. Depending on the
PCN algorithm on how AM and TM share the same '11'
encoding, this may or may not affect the functionality of
PCN.
The above discussion for Option 11 applies equally for PCN
traffic leaked out of the PCN domain and interpreted by RFC
3168 ECN nodes.
* With encoding Option 12, the old routers will interprete:
+ '00' encoding as Not-ECT, and will drop Not-PCN marked
packets when congestion is detected. With '00' the
encoding for Not-PCN, requiring the same functionality as
Not-ECT, the presence of old routers will not affect the
performance of PCN functionality.
+ '01' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
For Option 5, the old router can possibly remark AfM to TM.
This may or may not be acceptable, depending on the
algorithm's Affected Marking functionality.
+ '10' encoding as ECT(1), which indicates ECN capable and
can be remarked to '11' to indicate congestion experienced.
The RFC 3168 ECN CE encoding have the same functionality as
the PCN TM encoding, to reduce the offered traffic load.
Depending on the PCN algorithm on how AM and TM share the
same '11' encoding, this may or may not affect the
functionality of PCN.
+ '11' encoding as CE. The old router should use this
encoding to reduce the offered traffic load and should not
remark this to any other ECN encoding. Depending on the
PCN algorithm on how AM and TM share the same '11'
encoding, this may or may not affect the functionality of
PCN.
The above discussion for Option 12 applies equally for PCN
traffic leaked out of the PCN domain and interpreted by RFC
3168 ECN nodes.
3. Concern 3: "How does the possible presence of old routers affect
the coexistence of the alternate ECN traffic with competing
traffic on the path." If RFC 3168 ECN and PCN traffic are to be
treated within a single DiffServ PHB, because with these encoding
Chan, et al. Expires August 10, 2008 [Page 21]
Internet-Draft Document February 2008
there is no way to differentiate between the ECN packets from the
PCN traffic, the metering and marking algorithm used must be
totally friendly between ECN and PCN traffic, else they will
affect each other in possibly non-acceptable ways. These
encoding will work OK with traffic besides ECN because of the use
of 'Not-PCN' encoding.
4. Concern 4: "How well does the alternate ECN traffic perform."
The performance of the different proposed PCN (alternate ECN)
metering and marking algorithms are currently under study with
their simulation and study results described by their respective
documents.
Appendix A.4. Encoding Choice Considerations
o If three encoding states need to be separately represented, Option
10 is recommended.
o If the marking algorithm allows the AM and TM encoding states be
represented using the same bit pattern, Option 11 is recommended.
o If the marking algorithm requires the use of Affected Marking
encoding state, Option 12 is recommended. For Option 12,
alternative NPM bit patterns ('01' or '10') may be used for the
AfM purpose.
Appendix B. Out-of-Band Channel as Encoding Transport
In this type of encoding and transport method the congestion and
precongestion information can be encoded using the IPFIX protocol RFC
3955 [18], that is normally used to carry flow-based IP traffic
measurements from an observation point to a collecting point. Note
that this encoding scheme is denoted in this document as "IPFIX
channel". An observation point is a location in a network where IP
packets can be observed and measured. A collecting point can be a
process or a node that receives flow records from one or more
observation points. In the PCN case, each PCN-interior-node will be
an IPFIX observation point and the PCN-egress-node will be the IPFIX
collecting point.
The PCN-interior-node will support the metering process and the flow
records. Note that in this case each flow record can be associated
with the record of the congestion and pre-congestion metering
information associated with each PHB. The PCN-egress-node will then
support the IPFIX collecting process, which will receive flow records
from one or more congested and pre-congested PCN-interior-nodes.
Using this encoding method the encoding modes/states can be
Chan, et al. Expires August 10, 2008 [Page 22]
Internet-Draft Document February 2008
aggregated and transported to the egress node by using the flow
records at regular intervals or at the moment that a congestion and
pre-congestion situation occurs. The used transport channel in this
case is not the data path but a signaling protocol.
Appendix B.1. Benefits of Using Out-Of-Band Channel
This encoding scheme does not use the data path for encoding and
transport, but it is able to transport the congestion and pre-
congestion information associated with the encoding states by using a
separate signaling channel. Another benefit of using this encoding
scheme is that it is not affecting the end-to-end ECN semantics and
therefore the issues and concerns raised in RFC 4774 are not
applicable for this encoding scheme.
Appendix B.2. Drawbacks of Using Out-Of-Band Channel
The "IPFIX channel" encoding mode needs a separate signaling channel
for the transport of the congestion and precongestion information
from the PCN-interior-nodes towards the PCN-egress-node. The
requirement of using an additional channel increases the complexity
and influences negatively the performance of the PCN-interior-nodes
since each PCN-interior-node needs to support in addition to the data
path a separate channel.
Appendix C. Current PCN Detection, Marking and Transport Mechanisms
This appendix indicates the different available PCN based mechanisms
that can be used for congestion and pre-congestion detection and
marking used at interior nodes. The requirements and characteristics
of such algorithms may influence the encoding and transport of the
PCN encoding states.
Appendix C.1. Detection, Marking and Transport Mechanisms in CL-PHB
Please see draft-briscoe-tsvwg-cl-phb-03.txt [5] for details on the
Controlled-Load PHB Algorithm.
Appendix C.2. Detection, Marking and Transport Mechanisms in Three
State Marking
Please see draft-babiarz-pcn-3sm-01.txt [2] for details on the Three
State Marking Algorithm.
Chan, et al. Expires August 10, 2008 [Page 23]
Internet-Draft Document February 2008
Appendix C.3. Detection, Marking and Transport Mechanisms in Single
Marking
Please see draft-charny-pcn-single-marking-03.txt [3] for details on
the Single Marking Algorithm.
Appendix C.4. Detection, Marking and Transport Mechanisms in Load
Control Marking
Please see draft-westberg-pcn-load-control-02.txt [4] for details on
the Load Control Algorithm.
8. Informative References
[1] Eardley, P., "Pre-Congestion Notification Architecture",
draft-ietf-pcn-architecture-03 (work in progress),
February 2008.
[2] Babiarz, J., Liu, X., Chan, K., and M. Menth, "Three State PCN
Marking", draft-babiarz-pcn-3sm-01 (work in progress),
November 2007.
[3] Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
Congestion Notification Using Single Marking for Admission and
Termination", draft-charny-pcn-single-marking-03 (work in
progress), November 2007.
[4] Westberg, L., "LC-PCN: The Load Control PCN Solution",
draft-westberg-pcn-load-control-02 (work in progress),
November 2007.
[5] Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006.
[6] Baker, F., Polk, J., and M. Dolly, "DSCPs for Capacity-Admitted
Traffic", draft-ietf-tsvwg-admitted-realtime-dscp-03 (work in
progress), December 2007.
[7] Baker, F. and J. Polk, "MLEF Without Capacity Admission Does
Not Satisfy MLPP Requirements",
draft-ietf-tsvwg-mlef-concerns-00 (work in progress),
February 2005.
[8] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[9] Wroclawski, J., "Specification of the Controlled-Load Network
Chan, et al. Expires August 10, 2008 [Page 24]
Internet-Draft Document February 2008
Element Service", RFC 2211, September 1997.
[10] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[11] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[12] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[13] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[14] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[15] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation over
Diffserv Networks", RFC 2998, November 2000.
[16] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[17] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[18] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002.
[19] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC 3540,
June 2003.
[20] Leinen, S., "Evaluation of Candidate Protocols for IP Flow
Chan, et al. Expires August 10, 2008 [Page 25]
Internet-Draft Document February 2008
Information Export (IPFIX)", RFC 3955, October 2004.
[21] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[22] Floyd, S., "Specifying Alternate Semantics for the Explicit
Congestion Notification (ECN) Field", BCP 124, RFC 4774,
November 2006.
[23] "Supporting Real-Time Applications in an Integrated Services
Packet Network: Architecture and Mechanisms", Proceedings of
SIGCOMM '92 at Baltimore MD, August 1992.
[24] "Multilevel Precedence and Pre-emption Service (MLPP)", ITU-T
Recommendation I.255.3, 1990.
[25] "Economics and Scalability of QoS Solutions", BT Technology
Journal Vol 23 No 2, April 2005.
Authors' Addresses
Kwok Ho Chan
Nortel
600 Technology Park Drive
Billerica, MA 01821
USA
Email: khchan@nortel.com
Toby Moncaster
BT Research
B54/70, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
Email: toby.moncaster@bt.com
Chan, et al. Expires August 10, 2008 [Page 26]
Internet-Draft Document February 2008
Michael Menth
University of Wurzburg
Institute of Computer Science
Room B206
Am Hubland, Wuerzburg D-97074
Germany
Email: menth@informatik.uni-wuerzburg.de
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
Email: g.karagiannis@ewi.utwente.nl
Philip Eardley
BT Research
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
Email: philip.eardley@bt.com
Bob Briscoe
BT Research
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
Email: bob.briscoe@bt.com
Chan, et al. Expires August 10, 2008 [Page 27]
Internet-Draft Document February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chan, et al. Expires August 10, 2008 [Page 28]