One document matched: draft-babiarz-tsvwg-rtecn-03.txt
Differences from draft-babiarz-tsvwg-rtecn-02.txt
TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: August 22, 2005 Nortel Networks
V. Firoiu
BAE Systems
February 18, 2005
Congestion Notification Process for Real-Time Traffic
draft-babiarz-tsvwg-rtecn-03
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies the usage of Explicit Congestion Notification
(ECN) markings for real-time inelastic flows such as voice, video
conferencing, and multimedia streaming. We build on the principles
of RFC 3168, "The Addition of Explicit Congestion Notification to
Babiarz, et al. Expires August 22, 2005 [Page 1]
Internet-Draft Document February 2005
IP", and apply them to real-time inelastic traffic in DiffServ
networks. The method specified in this document has the requirement
that these real-time inelastic flows can be distinguished from other
flows and may receive separate treatment from the network.
We introduce new ECN semantics that provide information for two
levels of experienced congestion along the path for real-time
inelastic flows. This document describes how network nodes perform
ECN marking for real-time inelastic flows when congestion is
experienced, but it is left up to the application designers to define
how end-systems should react to ECN bit marking. For illustration
purposes, an example is provided showing how ECN for real-time UDP
flows can be used for admission control of VoIP flows.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2 Applicability and Operating Environment . . . . . . . . . 4
1.3 Network with DiffServ and Real-Time ECN Support . . . . . 4
2. General Principles . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Congestion for Real-Time Traffic . . . . . . . . 6
3.1 Avoiding Congestion for Real-Time Traffic . . . . . . . . 7
3.2 Congestion Detection for Real-Time Traffic . . . . . . . . 8
3.3 Behavior of Meter and Marker . . . . . . . . . . . . . . . 9
3.4 Marking for Congestion Notification . . . . . . . . . . . 9
3.4.1 Congestion Notification for Real-Time Traffic . . . . 10
3.4.2 ECN Marking of Real-Time Inelastic Flows . . . . . . . 11
3.4.3 ECN Semantics for Real-Time Traffic . . . . . . . . . 11
4. Detection of Inappropriate Changes to the ECN Field . . . . . 12
5. Example of ECN usage for Admission Control . . . . . . . . . . 14
6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Issues List . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1 Normative References . . . . . . . . . . . . . . . . . . . 17
11.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
A. Meter Example . . . . . . . . . . . . . . . . . . . . . . . . 18
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 19
A.2 Meter Configuration . . . . . . . . . . . . . . . . . . . 19
A.3 Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 20
A.4 Marking . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.5 Summary of the Behavior . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
Babiarz, et al. Expires August 22, 2005 [Page 2]
Internet-Draft Document February 2005
1. Introduction
This document summarizes the recommended method for providing
end-to-end Explicit Congestion Notification (ECN) for real-time
inelastic flows such as voice, video conferencing, and multimedia
streaming. RFC 3168 [6] specifies the incorporation of ECN for IP,
including ECN's use of two bits in the IP header. This document
builds on the concepts of RFC 3168, "The Addition of Explicit
Congestion Notification to IP", and applies them to real-time
inelastic flows in DiffServ enabled networks.
To address a wider usage of this mechanism, it is necessary to
introduce new semantics for the ECN field of the IP header (bits 6
and 7 of the TOS byte) that can provide two levels of congestion
indication for real-time inelastic flows. There are applications and
services that need to provide different treatment at the application
level based on the importance of the flow for a given level of
congestion experienced. For example, higher importance flows within
a service class used for real-time traffic may need to get priority
access to the network resources over regular traffic. This document
specifies the required behavior of network nodes that are configured
to provide ECN-capability for real-time flows.
The operating environment is discussed first, and then functions are
defined that need to be performed in the network for real-time flows.
Specifically, this includes (1) congestion detection through the use
of flow measurement and (2) marking of ECN bits in the IP header of
real-time packets for a given DSCP-marked service class. Since
real-time inelastic flows like voice and video conferencing are very
delay sensitive, a different method than what is specified in RFC
3168 for determining levels of congestion needs to be used.
The proposal is to use ECN as a method to notify the application that
packets flowing on this path are above the engineered capacity of the
service class that is used for real-time traffic in the network.
Based on this information, the application may take action to reduce
its sending rate by whatever means is appropriate; for example stop
sending packets, or reduce its rate, or not admit new flows while the
path remains congested. The reaction or decision taken by the
application to the ECN marking is not specified in this document as
it will depend on the application. It is left up to application
designers to define how applications in end-systems should react to
ECN bit marking that is performed in the network. It is expected
that application specific documents will be produced to explain the
application's usage of this real-time ECN mechanism. For
illustration purposes, a high level example of a procedure that may
be used for admission of VoIP flows based on ECN marking within a
service class in the network is provided. The details of this
Babiarz, et al. Expires August 22, 2005 [Page 3]
Internet-Draft Document February 2005
example is provided by Admission Control Use Case for Real-time ECN
[7].
1.1 Requirements Notation
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 [3].
1.2 Applicability and Operating Environment
Networks that need to support real-time inelastic services may need
to provide a controlled environment that allows for a high level of
guarantees on the quality of service to be honored. We suggest the
use of DiffServ service classes to separate the real-time inelastic
traffic from the other traffic for such a controlled environment, and
applying the Real-Time ECN process discussed in this document.
This document addresses the use of the ECN markings in a DiffServ
controlled environment, with ECN marking both as defined herein and
in RFC 3168 [6] co-existing in the same network but in different
service classes. As well, there may be network segments that do not
deploy any ECN processing at all. These operating environments are
explored and discussed herein. But in all cases, DiffServ separation
of the real-time inelastic traffic from the other traffic should be
supported. With the basic rules of:
o no mixing of Real-Time ECN and RFC 3168 ECN marking in the same
service class
o no mixing of traffic from Real-Time ECN capable end-systems and
from Real-Time ECN un-capable end-systems into the same service
class
o allowed mixing of traffic from ECN and non ECN capable end-systems
at points where congestion is not possible
1.3 Network with DiffServ and Real-Time ECN Support
The real-time ECN process requires that the real-time inelastic
traffic is separated from the other traffic. Within a DiffServ
network, it is perfectly fine to deploy RFC 3168 ECN marking for
service classes that are used for elastic TCP traffic and to deploy
Real-Time ECN marking as defined herein for service classes that are
used for inelastic real-time traffic. DiffServ is used to separate
the real-time traffic from the other traffic flows, and Real-Time ECN
processing is applied to this separated traffic to provide control
Babiarz, et al. Expires August 22, 2005 [Page 4]
Internet-Draft Document February 2005
within the service class. Under this condition, the most optimal
deployment is to have all network segments support DiffServ, with
Real-Time ECN marking capability on selected nodes where congestion
within the real-time service class is likely. Over time, as traffic
levels within the real-time service class become complex and/or the
network topology becomes more complex, it may be preferable that
Real-Time ECN capability is extended to all or most network nodes.
This notion of traffic separation into different service classes also
applies to end-systems supporting Real-Time ECN processing. Traffic
from end-systems that do not support Real-Time ECN processing
(reaction to ECN marking) should not be placed into the same DiffServ
service class as traffic that does. If it were, the end-systems that
do not support the Real-Time ECN processing would not "back off" on
onset of congestion conditions and would impact flows from
end-systems that support Real-Time ECN processing.
This approach allows for specific network nodes where congestion is
very unlikely to occur not to require DiffServ or Real-Time ECN
processing to be deployed.
2. General Principles
In this section, some of the important design principles and
assumptions guiding the development of this proposal are described.
o Because ECN for real-time flows is likely to be adopted gradually
and selectively in nodes, accommodating migration and selective
deployment is essential. Some nodes may not be able to detect
congestion or mark the ECN bits within IP packet headers. Also
there may be parts of the network where congestion is very
unlikely and therefore there is no need for an ECN function. The
most viable strategy is one that accommodates selective or
incremental deployment in a network with both ECN-capable and
non-ECN-capable nodes.
o Asymmetric routing is likely to be a normal occurrence within IP
networks. That is, the path (the sequence of links and nodes)
taken by forward and reverse packet flows may be different.
o Many nodes process the "regular" header in IP packets more
efficiently than they process the header information in IP
options. This suggests that the ideal approach is to keep
"congestion experienced" information in the regular header of an
IP packet.
o A specific DiffServ service class would be implemented exclusively
for real-time traffic flows from ECN-capable end-systems. A
Babiarz, et al. Expires August 22, 2005 [Page 5]
Internet-Draft Document February 2005
different DiffServ service class is used to identify real-time
flows that are not ECN-capable. Hence, the ECT(0) or ECT(1)
indicators defined in RFC 3168 [6] are not needed. The assumption
is that a signaling protocol (SIP, H.323, MGCP, H.248, etc.) will
be used to determine if the end-systems are capable of
understanding ECN bit marking and thus, are willing to participate
in congestion control prior to usage of the specific ECN-enabled
service class.
o Furthermore, it is desirable that real-time traffic flows from
ECN-capable and non-ECN-capable end-systems does not use the same
DiffServ service class. Mixing the two may cause the flows that
are non-ECN-capable to generate congestion and to introduce delay
and/or packet drop to both ECN-capable and non-ECN-capable flows.
o The proposed real-time ECN mechanism assumes end-to-end usage of
DiffServ in order to allow differentiation of real-time ECN
capable traffic from all other traffic on the network. For the
real-time ECN capable traffic, the ECT(0) and ECT(1) states
defined in RFC 3168 [6] are not used in the network. This is
reasonable as the proposed mechanism is meant for managed IP
networks.
o Flow measurement and marking of ECN bits is defined herein to be
performed on flows that are mapped to a set of ECN-enable service
classes, and is performed only on selected node links in the
network where congestion is likely to occur. Other traffic flows
are not affected by this function. Nodes that do not support this
function forward packets without modifying bit 6 and 7 in the ECN
field of the IP header.
o ECN procedure as defined in RFC 3168 [6] may also be applied to
DiffServ service classes in the IP network. Both methods may
co-exist in the network, but in different DiffServ service
classes.
3. Definition of Congestion for Real-Time Traffic
Real-time traffic generated by applications such as voice, video
conferencing, and multimedia streaming have different performance
requirements when compared with non-real-time applications that use a
protocol such as TCP. One such requirement is that end-to-end delay
be bounded by a small value, and that packets should not be dropped.
It is generally accepted that such performance requirements can be
achieved when the real-time flows are serviced by the nodes in their
path through a real-time service class such as one based on the EF
Babiarz, et al. Expires August 22, 2005 [Page 6]
Internet-Draft Document February 2005
PHB treatment. This treatment can be provided only when the
real-time service class is not overloaded (i.e., when the aggregate
of input traffic never exceeds the class' capacity, and thus no
congestion condition occurs). It should also be noted that when the
overloaded condition occurs, all real-time traffic flows within the
real-time service class at the congestion point will be affected, not
just the offending traffic flow. Hence, it is desirable to avoid the
overloaded condition as much as possible.
With the above performance requirements for real-time inelastic
traffic in mind, "congestion of real-time inelastic traffic" is
defined to be the network condition when aggregated packet flows
within the service class exceed an engineered traffic level. The
engineering of the network is such that traffic exceeding this
engineered traffic level by a defined and limited amount does not
generally cause an increase in packet queuing or packet dropping
(service class overload) in the network. Instead, the ECN field is
used to provide an indication that traffic is above the engineered
traffic level. This can be viewed as explicit notification to
prevent congestion. However, uncontrolled or prolonged increase in
traffic above the defined amount may result in an increase in packet
queuing and/or packet dropping, and therefore may cause overload of
the real-time service class.
3.1 Avoiding Congestion for Real-Time Traffic
Congestion (ECN) notification can be utilized in a flow admission
control scheme to ensure sufficient forwarding resources (bandwidth).
In this scheme, a continuous process at selected link(s)/node(s)
measures the traffic going through a specified real-time service
class and indicates a level of congestion (such as "not congested",
"mildly congested" or "severely congested"). This congestion
indication as described in Section 3.4.3 is then used by the
application to select the action that will be taken by the
application controlling the service. The action could be to admit or
not to admit a new flow into that real-time service class in the
network, or have the sending rate of ECN marked flows reduced or
stopped, or terminate a flow. All with the effect of reducing level
of offered traffic. Based on the performance requirements of
real-time traffic, it is desirable that the measurement process
indicate congestion of real-time traffic before any significant
packet accumulation in the queue occurs. This is such that no
significant queuing delay is added to existing real-time flows'
end-to-end delay.
An alternative method to avoid the overloaded condition of a service
class is through resource reservation and admission control: a
(centralized or distributed) database maintains a record of available
Babiarz, et al. Expires August 22, 2005 [Page 7]
Internet-Draft Document February 2005
resources (bandwidth) for the real-time service class on each link in
the network and a new flow is admitted only if there are enough
resources on the links in its path so that the overloaded condition
is avoided. Checking for available resources can be done with a
reservation protocol or through a policy based protocol. An
important issue is that the maintenance and per-flow querying of the
resource database in conjunction with the routing database is an
important overhead that is undesirable in many implementations.
The present proposal of using ECN for congestion indication on
real-time flows enables measurement-based solutions for congestion
avoidance that do not have such scalability problems associated with
resource databases.
3.2 Congestion Detection for Real-Time Traffic
One of the goals is to keep the amount of processing that is
performed in the network to be very small and not require any other
computations or state information to be kept in network nodes. One
way to achieve this is through monitoring the aggregate rate of
traffic in the specified real-time service class and to indicate
congestion when a certain traffic threshold is exceeded. Hence the
network nodes only need to perform flow measurement of packets marked
with the defined DSCP value(s) and set the ECN bit(s) when that
traffic rate exceeds the defined level. The application monitors the
ECN field, and takes an appropriate action based on the marking.
Figure 1 below shows a block diagram of the traffic measurement and
ECN marking function.
The Meter meters each packet within the real-time service class and
passes the packet and the metering result to the ECN Marker:
+------------+
| Result |
| V
+-------+ +--------+
| | | ECN |
Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
| | | |
+-------+ +--------+
Figure 1: Block Diagram of Meter and Marker Function
The Marker sets the ECN bit values for each packet within the
real-time service class based on the results of the Meter.
The traffic rate of the specified service class may be measured with
a simple token bucket meter, an exponentially weighted moving average
Babiarz, et al. Expires August 22, 2005 [Page 8]
Internet-Draft Document February 2005
meter, or other methods. The goals of a rate measuring method are
simplicity and minimum or no added delay to traffic forwarding.
The specification of the traffic measurement mechanism is outside the
scope of this document. The intention is that an existing traffic
measurement mechanism may be used. In Appendix A, an example of a
simple token bucket method for measurement and marking is provided.
3.3 Behavior of Meter and Marker
When the measured rate exceeds the engineered traffic level (for
example, when token bucket runs out of tokens), the Meter sets its
result flag and passes it to the Marker. The Marker, sets the
appropriate ECN value for all packets belonging to the service class
that is measured until the result flag from the Meter is cleared.
When the measured traffic rate is equal to, or is reduced below the
engineered rate (the token bucket becomes full) the Meter clears the
result flag if set. The clearing of the result flag output from the
Meter stops marking ECN bits by the Marker. The metering function
has built-in hysteresis for setting and clearing the result flag.
The amount of hysteresis is controlled by the configuration
parameters of the traffic measurement mechanism and should be
configured to meet the characteristics of the real-time inelastic
traffic that is being measured.
3.4 Marking for Congestion Notification
Marking for Explicit Congestion Notifications is done through the use
of the two ECN bits in the IP header.
0 1 2 3 4 5 6 7
----+----+----+----+----+----+----+----
| DS FIELD, DSCP |ECN FIELD|
----+----+----+----+----+----+----+----
DSCP: Differentiated Services Codepoint
ECN: Explicit Congestion Notification
Figure 2: DS and ECN Fields in IP Header
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6,
and the ECN field is defined identically in both cases. The
definitions for the IPv4 TOS octet RFC 791 [1] and the IPv6 Traffic
Class octet have been superseded by the six-bit Differentiated
Services (DS) field RFC 2474 [4], RFC 2780 [5]. Bits 6 and 7 are
listed in RFC 2474 [4] as Currently Unused, and are specified in RFC
2780 as approved for experimental use for ECN. Finally, RFC 3168 [6]
Babiarz, et al. Expires August 22, 2005 [Page 9]
Internet-Draft Document February 2005
standardized the use of the ECN bits.
3.4.1 Congestion Notification for Real-Time Traffic
Proposed is an usage of the ECN bits in addition to RFC 3168 [6] for
indicating two levels of congestion for real-time inelastic packet
flows in DiffServ capable networks. The selected nodes in the
network are configured to measure real-time traffic that is
classified and marked via a DS codepoint as requiring congestion
control.
We would like to keep the amount of processing that is performed in
the network elements to be minimal and not require any flow state
information to be kept in network nodes. The network nodes only need
to perform flow measurement of ECN-Capable Transport (ECT) marked
packets for the defined DSCP value(s) and set the ECN bit to
indicated congestion experienced when that traffic rate exceeds the
defined level.
Figure 3 defines the new ECN semantics for two levels of congestion
experienced marking as they apply to real-time inelastic flows. This
ECN marking was selected to keep some commonality with the marking
and naming in RFC 3168 [6]. RFC 3168 [6] defined ECN marking for a
single level of congestion with two ECT codepoints '10' ECT(0) and
'01' ECT(1) to provide one-bit ECN nonce for detection of cheaters.
Since many application that posses real-time inelastic traffic
characteristics require two levels of congestion notification, we
have redefined ECN codepoint '01' to represent congestion experienced
at 2nd level CE(2). Also, ECN codepoint '11' is renamed from
congestion experienced (CE) to congestion experienced at 1st level
CE(1). See Section 4 for a procedure that may be used to detect
cheaters.
The targeted applications have a requirement that the network provide
real-time transport with very low packet loss and delay. When mixing
flows from ECN-capable and non-ECN-capable end-systems into the same
service class and using ECT for providing treatment differentiation
(dropping or ECN marking), policing (metering and dropping) of
Not-ECT marked packets SHOULD be performed so that the service class
is not oversubscribed. Oversubscription may result in
non-ECN-capable end-systems continuing to offer traffic at the
current level or possibly even increase the offered rate, therefore
causing queue buildup (delay) and eventually introducing packet loss
to flows from ECN-capable end-systems.
We prefer to take a gradual or incremental approach for deployment of
ECN-capable nodes in the network and use the DiffServ architecture
for flow differentiation. Therefore, this new functionality needs
Babiarz, et al. Expires August 22, 2005 [Page 10]
Internet-Draft Document February 2005
only to be deployed in selected nodes, where congestion is likely to
occur. The premise is that different traffic types are separated
using Differentiated Services into two or more service classes with
different polices for each traffic type. However, both methods as
described in RFC 3168 and as documented herein for real-time
inelastic traffic can co-exist in the network, using independent
DiffServ service classes.
3.4.2 ECN Marking of Real-Time Inelastic Flows
Marking of ECN bits for real-time inelastic flows is defined so that
nodes in the path only need to perform an ECN set function when an
engineered rate is exceeded. With this approach there is no need to
perform a test of ECT marked packets to determine at what level of
congestion experienced that packet is marked. Other approaches could
be used, but for simplicity we have chosen this one.
Nodes that are configured to support congestion notification for
real-time flows need to provide the following capabilities:
o Congestion detection of ECT marked packets SHOULD be performed
using a real-time measurement mechanism (e.g., flow metering).
o At a minimum, one flow congestion detection mechanism is REQUIRED
to be associated to a link where congestion measurement is
performed.
o When the flow rate exceeds configured rate "A" (i.e., the first
level of congestion), ECN bit 7 of ECT market packets is set to
'1'.
o When the flow rate exceeds configured rate "B" (i.e., the second
level of congestion), ECN bits 6 and 7 of ECT market packets are
set to '01'.
o Measured rate "B" SHOULD be greater than rate "A".
Nodes in the IP network MAY be configured to support one or two
congestion detection levels.
3.4.3 ECN Semantics for Real-Time Traffic
Some real-time applications or services need the indication of two
levels of congestion experienced, CE(1) and CE(2), for first and
second level respectively. Other applications may only need the
indication of a single level of congestion experienced. To address a
wide range of usage, we have selected the following ECN semantics for
real-time inelastic traffic.
Babiarz, et al. Expires August 22, 2005 [Page 11]
Internet-Draft Document February 2005
ECN Marking:
Bits 6 and 7 values
0 0 Not-ECT - Endpoints are Not ECN-Capable
0 1 CE(2) - Congestion Experienced at 2nd level
1 0 ECT(0) - Endpoints are ECN-Capable
1 1 CE(1) - Congestion Experienced at 1st level
Figure 3: ECN Semantics for Real-Time Flows
Specific applications may take different action(s) in response to
congestion being experienced in the network. Depending on the
application, one possible outcome may be for the application to stop
initiating new real-time inelastic flows at the 1st level of
congestion, and if the offered load in the selected service class
reaches the 2nd level of congestion, the application in the
end-system stops sending packets. Most likely, different
applications will take various independent actions. The various
independent actions taken by the applications are out of scope of
this document.
4. Detection of Inappropriate Changes to the ECN Field
This section discusses in detail possible inappropriate changes to
the ECN field in the network, such as falsely reporting no
congestion, by erasing the ECN congestion indication.
In the implementation of a Real-Time ECN mechanism in the network,
the network administrator through the use of policies or through the
use of signaling/control protocols such as SIP can verify the
capabilities and conformance of the end-systems. As stated earlier,
only end-systems that are capable and conformant to Real-Time ECN
mechanism may use it. End-systems that are not Real-Time ECN capable
or conformant are mapped into a different service class (a service
class that is configured not to use Real-Time ECN) or are not allowed
access to the network through a deployment of a filter policy at the
network edge.
The Real-Time ECN mechanism provides two levels of congestion
indication; therefore, the cheating detection mechanism as defined in
RFC 3168 that uses ECT(0) and ECT(1) state can not be used. Instead,
the following procedure may be used to catch cheaters, network nodes,
software drivers or plug-ins that are not part of the certified
application in the end-system, altering ECN bit marking. The
outlined procedure may be executed under the control of the
application prior to admission of a new real-time flow or
periodically to verify the conformance of ECN marking. The testing
for conformance is between the two ECN capable and conformant
Babiarz, et al. Expires August 22, 2005 [Page 12]
Internet-Draft Document February 2005
applications running in the end-systems referred to as sender and
responder.
Prior to admission of a new real-time flow, the following procedure
can be used to detect cheaters. Note that this procedure is
independent of an actual admission control procedure.
o Under the control of the application, the sender generates and
sends a single test packet referred to as a Request Probe Packet.
The packet's ECN field is distinctly marked with the value 01,
which an ECN-capable router and the responder will perceive as
CE(2).
o Upon reception of the Request Probe Packet, the responder echoes
the received Request Probe Packet back to the sender as a Response
Probe Packet, including the value of the ECN field in the IP
header of the Request Probe Packet in the payload of the Response
Probe Packet.
o The sender compares the received ECN marking in the payload of the
Response Probe Packet with the value 01 originally set in the
Request Probe Packet. If it is 10 or 11 (ECT(0) or CE(1)), then a
cheater is present in the network which lowered the ECN marking.
The above procedure can optionally be used a second time, but using
the ECN value 11, or CE(1), on the Request Probe Packet.
Due to the nature of the Real-time ECN process described in this
memo, it is only possible to detect for the presence of cheaters
which lower the ECN marking.
Also, detection of cheaters is only possible if there are no other
ECN-capable routers down stream from the cheating device along the
network path legitimately marking the ECN bits, masking out the
cheating condition. If there are one or more ECN-capable routers
along the network path after the cheating device, then the cheater
can only be detected if the ECN-capable router(s) after it do not
mark the probe packets with a higher ECN value than set by the
cheating device.
Once a new real-time flow has been admitted, the following procedure
can be used to detect cheaters:
o The two endpoints involved in a flow negotiate a value N.
Normally, a ECN-capable endpoint uses the value 10, or ECT(0), as
the ECN for an RTP packet in a flow. The negotiated value N is
used such that every Nth packet sent for the flow is initially
marked with ECN 01, or CE(2). Upon receipt of the RTP packets,
Babiarz, et al. Expires August 22, 2005 [Page 13]
Internet-Draft Document February 2005
the endpoint compares the received ECN with the expect value of
01, or CE(2). If a cheater is present, and is not being
overridden by one or more ECN-capable router after it along the
path through the network, the endpoint detects the presence of a
cheater if the received ECN value is 10 or 11 (ECT(0) or CE(1)).
5. Example of ECN usage for Admission Control
Normally real-time VoIP bearer traffic is marked with EF DSCP and is
mapped into a DiffServ service class that produces very low latency,
jitter and packet loss when the traffic load is within the specified
parameters. Currently there is no method defined that can limit
(without dropping packets) the amount of traffic that can be
aggregated onto a link. As a result, controlling loads to within
engineered limits is difficult. To address this issue, we propose
that for real-time flows we use the metering and ECN marking method
defined in this document.
Here we describe how ECN can be used in real-time VoIP solution to
provide end-to-end admission of new media flows. This is only a
simple example of how admission control may be implemented using rate
metering and ECN bit marking in the network. Different applications
may use modified approaches to verify if there is sufficient
bandwidth before admitting a new flow.
Let us assume that the network is configured to mark real-time VoIP
payload packets with EF DSCP, and only this traffic is mapped into a
DiffServ service class referred to as Telephony service class.
Mapping of real-time traffic marked with other DSCP values is
possible but to keep this example simple we will only talk about EF
marked packets.
For example, before a session (i.e., a call) is established between
two clients, the two endpoints involved in the call will execute a
request/response transaction where the called party (Client B) sends
a Request probe packet to the calling party (Client A) and the
calling party correspondingly sends back a Response probe packet to
the called party. Probe packets are marked with EF DSCP and are
mapped into the Telephony service class.
A DiffServ style traffic meter and ECN marker are used on selected
nodes in the network along the path to measure the aggregated
(real-time media and probe packets) flow rate of EF marked packets.
If the flow rate of the EF marked packets as measured by the meter is
greater than rate "A", bit 7 in the ECN field of IP header is set to
1 and the packet is forwarded as usual. The metering and marking of
ECN bit only needs to be performed on selected nodes where bandwidth
Babiarz, et al. Expires August 22, 2005 [Page 14]
Internet-Draft Document February 2005
constraints exist and where congestion is likely to occur.
Upon receipt of the Request probe packet, the calling party generates
and sends a Response probe packet to the called party, echoing the
status of the received ECN bits in the Response probe packet. Again,
a DiffServ style traffic meter and ECN marker are used on selected
nodes in the network along the reverse path to measure the aggregated
flow rate of EF marked packets. If the flow rate of EF marked
packets as measured by the meter is greater than rate "A", bit 7 in
ECN field of IP header is set to 1 and the packet is forwarded as
usual. On receipt of the Response probe packet, the called party
could send a notification with the ECN Status to relay the ECN bit
status results for the media path to a server in the network where
call admission control is performed. Based on the received
congestion status (bandwidth usage) for that path, the admission
control function will make a decision as to whether or not to
continue with call setup and admit this new real-time flow. Should
bandwidth usage parameters as indicated by ECN bit marking be
exceeded, then this new real-time flow will not be admitted.
6. Non-compliance
Because of the unstable history of the TOS octet, the use of the ECN
field as specified in this document cannot be guaranteed to be
backwards compatible with any past uses of these two bits that
pre-date ECN. The potential dangers of this lack of backwards
compatibility are discussed in RFC 3168 [6] Section 22.
7. Issues List
NOTE TO RFC EDITOR: Please remove this section during the publication
process.
The following issues list are based on comments received.
Issues from Sally during our discussion at San Diego IETF 8/1-6/2004
on -01 version of the draft.
1. Need to resolve Receiver Cheating situations.
In -02:
Section on cheating was added to draft.
2. Need to indicate why we are not concerned with ECT usage.
In -02:
Explanation was added. However, we are still investigating
scenarios where ECT may be useful
In -03:
Added back the usage of ECT(0).
Babiarz, et al. Expires August 22, 2005 [Page 15]
Internet-Draft Document February 2005
But because ECT(1) is not used, catching cheating is still different from RFC 3168.
3. Clarify to indicate using specific DiffServ Code Point.
In -02:
Added clarification in "Abstract" section and added
"Applicability and Operating Environment" section.
4. Need Applicability Statement up front.
In -02:
Added clarification in "Abstract" section and added
"Applicability and Operating Environment" section.
5. Change the draft to indicate RFC 3168 applies to UDP as well as TCP (all IP traffic).
In -02:
Removed mentioning of RFC3168 focusing on TCP in "Introduction"
and bottom of "Assumptions and General Principles" sections.
6. Provide an explanation on situation where there is a node in
the middle that does not understand DiffServ but can do ECN.
In -02:
Added "Applicability and Operating Environment" section.
7. Sally preferred to have the ECN bits to have:
00=Not-CE, 01=CE(0), 10=CE(1), 11=Not-DiffServ-CE.
In -02: Open:
Keeping current marking as is for this version of draft.
Investigate alternate marking approach pros and cons for two level of congestion.
In -03:
Adopted the use of
00=Not-ECT, 01=CE(2), 10=ECT(0), 11=CE(1); the Alt-1 semantics in early discussions.
8. Security Considerations
This document discusses detection of congestion for real-time traffic
flows and also describes a common policy configuration, for the use
and application of ECN bit marking. If implemented as described, it
should require the network to do nothing that the network has not
already allowed. If that is the case, no new security issues should
arise from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined congestion
detection point. In that case, a policy issue exists that the
network must detect, assess, and deal with. This is a known security
issue in any network dependent on policy-directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a
Babiarz, et al. Expires August 22, 2005 [Page 16]
Internet-Draft Document February 2005
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the author's knowledge, there is no known technical
way to respond to or act upon a data stream that has been admitted
for service but that it is not intended for authenticated use.
9. IANA Considerations
To be completed.
10. Acknowledgements
The authors acknowledge a great many inputs, most notably from Sally
Floyd, Nabil Bitar, Hadriel Kaplan, David McDysan, Mike Pierce, Alia
Atlas, John Rutledge, Francois Audet, Tony MacDonald, Mary Barnes,
Greg Thor, Corey Alexander, Jeremy Matthews, Marvin Krym, and Stephen
Dudley.
11. References
11.1 Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] 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.
[5] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
11.2 Informative References
[7] Alexander, C., "Admission Control Use Case for Real-time ECN",
Babiarz, et al. Expires August 22, 2005 [Page 17]
Internet-Draft Document February 2005
Internet-Draft draft-alexander-rtecn-admission-control-use-case-00
, February 2005.
Authors' Addresses
Jozef Z. Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-768-2231
Email: babiarz@nortel.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-4690
Email: khchan@nortel.com
Victor Firoiu
BAE Systems
6 New England Executive Park
Burlington, MA 01803
US
Phone: +1-781-505-4677
Fax: +1-781-273-9345
Email: victor.firoiu@baesystems.com
Appendix A. Meter Example
This appendix provides an example of Real-Time ECN capability in a
network node. This example uses a Single Rate Meter and ECN Marker.
For scenarios that require to measure two traffic levels within a
service class for congestion indications, two instances of the single
rate meter and ECN marker can be used, one for configured rate "A"
and one for configured rate "B". The meter parameters should be
selected to meet the characteristics and performance requirements of
traffic being measured as well meters' behavior for each level.
Babiarz, et al. Expires August 22, 2005 [Page 18]
Internet-Draft Document February 2005
Appendix A.1 Introduction
The Single Rate Meter and ECN Marker is configured by assigning
values to the following parameters: Committed Information Rate (CIR),
Token Bucket Size (TBS), upper threshold m (in percentage of TBS) and
lower threshold n (in percentage of TBS). The Token Bucket Update
duration (TBU) is an implementation parameter that may not be
configurable. We also consider the Token Bucket Drain duration (TBD)
resulting from the first two configurable parameters, TBD=TBS/CIR.
The meter also has an internal state "flag" which when set indicates
a condition where the measured traffic has exceeded the CIR and token
in the token bucket were exhausted below the n threshold, as
described below. CIR is measured in bytes of IP packets per second,
i.e., it includes the IP header, but not link specific headers.
The Meter meters each packet within the real-time service class and
passes the packet and the metering result to the Marker:
+------------+
| Result |
| V
+-------+ +--------+
| | | |
Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
| | | |
+-------+ +--------+
Figure 4: Block Diagram of Meter and Marker Function
The Marker sets the ECN bit values for each packet within the
real-time service class based on the results of the Meter.
Appendix A.2 Meter Configuration
The Single Rate Meter and ECN Marker is configured by assigning
values to six traffic parameters: Committed Information Rate (CIR),
Token Bucket Size (TBS), Token Bucket Drain duration (TBD)
TBD=TBS/CIR, Token Bucket Update duration (TBU), and two thresholds
(m and n) in percent of TBS. CIR is measured in bytes of IP packets
per second, i.e., it includes the IP header, but not link specific
headers.
TBS is measured in bytes, and represents the variants of the rate
being measured. Normally, variable rate traffic will need larger
token bucket than constant rate traffic, and the size will depend on
the characteristics of traffic being measured. TBS should be
configured such that traffic variation within the specified rate as
measured at the node should not use up all the available tokens
Babiarz, et al. Expires August 22, 2005 [Page 19]
Internet-Draft Document February 2005
during a single TBD duration.
TBD and TBU are measured in seconds and TBD should be configured to
be at least 2 times greater than TBU. For real-time inelastic
traffic, it is recommended that TBD be configured to be greater than
the expected inter-packet emission time at sender for the measured
packet stream. For best accuracy, TBU should be a small value, as
small as implementation practical.
Appendix A.3 Meter Behavior
The behavior of the Meter is specified in terms of its Token Bucket
Size (TBS) with its rates CIR and Token Bucket Update duration (TBU).
Where TBD = TBS/CIR and
Where TBD > 2 x TBU
The token bucket (TBS) initially (at time 0) is full, i.e., the token
count is represented by Tp.
Where Tp(0) = TBS
Thereafter, tokens (Tp) are added to the token bucket at rate of (CIR
x TBU) per TBU.
Every TBU; Tp = Tp(t)+(TBU x CIR)
If Tp(t) > TBS, Set Tp = TBS
If result flag is set and Tp(t) + (TBU x CIR) > m x TBS, clear
result flag, and set Tp = TBS
Where m = 1-99% of TBS
When a packet of size B bytes arrives at time t, the following
happens:
If result flag is not set and Tp(t)-B < n x TBS, set result flag,
and set Tp to zero. (TBS empty)
Where n = 1-99% of TBS
else
Decrement Tp by B.
Where m > n; both m and n are a percentage of TBS.
Babiarz, et al. Expires August 22, 2005 [Page 20]
Internet-Draft Document February 2005
The actual implementation of a Meter doesn't need to be modeled
according to the above formal specification.
Appendix A.4 Marking
The ECN Marker reflects the result flag setting received from the
meter. If result flag is set, all packets serviced by the real-time
inelastic service class have their ECN bit set. The ECN Marker sets
the ECN bit as long as the result flag from the meter is set.
Appendix A.5 Summary of the Behavior
When the measured rate is exceeded (token bucket runs out of tokens)
the meter sets the "result flag" and passes it to the ECN Marker.
The ECN Marker, sets the ECN bit of all packets belonging to the
service classes flowing through the interface being measured until
the traffic rate is reduced below the measuring threshold; thereby
the token bucket becomes full. When the token bucket becomes full,
the meter clears the "result flag" if set. The clearing of the
result flag output from the meter stops the marking of ECN bit by the
Marker.
Babiarz, et al. Expires August 22, 2005 [Page 21]
Internet-Draft Document February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Babiarz, et al. Expires August 22, 2005 [Page 22]
<x-flowed>
</x-flowed>
| PAFTECH AB 2003-2026 | 2026-04-23 17:03:20 |