Network Working Group C. Alexander, Ed.
Internet-Draft J. Babiarz
Expires: August 15, 2005 J. Matthews
Nortel
February 11, 2005
Admission Control Use Case for Real-time ECN
draft-alexander-rtecn-admission-control-use-case-00.txt
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 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes Admission Control as a use case for the
mechanisms described in "Congestion Notification Process for
Real-Time Traffic" [1] and the RTP payload format defined in "RTP
Payload Format for ECN Probing" [2].
Alexander, et al. Expires August 15, 2005 [Page 1]
Internet-Draft Real-time ECN Admission Control February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Admission Control . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6
3.2 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 One-way Mechanism without Cheater Detection . . . . . 6
3.2.2 Two-way/Loop-back Mechanism without Cheater
Detection . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 One-way Mechanism with Cheater Detection . . . . . . . 11
3.2.4 Two-way/Loop-back Mechanism with Cheater Detection . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Normative References . . . . . . . . . . . . . . . . . . . 22
8.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
Alexander, et al. Expires August 15, 2005 [Page 2]
Internet-Draft Real-time ECN Admission Control February 2005
1. Introduction
Converged networks that are configured to provide multi-services
normally are engineered to provide the required quality of service
using Diffserv technologies. Real-time inelastic traffic (e.g.
voice) normally is configured to use Expedited Forwarding (EF) PHB to
provide very low delay, loss and jitter transport. To stay within
that engineered quality of service, and to ensure a quality of
service level for that traffic, some type of admission control
mechanism is necessary. Due to the sensitive nature of voice and
other telephony applications (video conferencing, multi-media
streaming), freely allowing these types of sessions onto a network
where resources are limited can quickly lead to degradation of
service that users may not tolerate. And in a packet based network,
the degradation is not limited to the offending flows, which the
provider may not tolerate.
This document proposes an admission control solution based on
"Congestion Notification Process for Real-Time Traffic" [1] and "RTP
Payload Format for ECN Probing" [2]. The gist of the solution is
that nodes at selected points in the network, where congestion is
most likely to occur, measure traffic flow per service class and mark
the ECN bits in the IP header based on observed traffic level(s).
During session setup a probing mechanism is used between endpoints to
verify traffic level (or congestion) along the path. The probing
travels along the media path between the endpoints, where the
endpoints are on either side of one or more bandwidth constrained
links. At the links, ECN-capable nodes are provisioned with
congestion thresholds based on a traffic type's real-time service
class. The nodes mark the ECN bits in the IP headers of the probe
packets according to the nodes' experienced level of congestion for
the particular service class. As packets arrive, the ECN-capable
endpoints recognize any ECN markings and make an admission control
decision according to the indicated congestion level and session
precedence.
The Real-Time ECN process offers two levels of congestion indication.
There is an intermediate congestion indication in addition to a
maximum congestion indication. This adds flexibility to admission
control decisions. The intermediate congestion indication
essentially warns endpoint applications that network congestion is
relatively high but that there is still some available bandwidth.
Using this information, applications can possibly decide to filter
out certain types of sessions for admission in favor of other types.
Applications demanding a large amount of bandwidth like video
conferencing might be denied, while less bandwidth-intensive voice
sessions could be admitted. Whatever the admission control basis,
Real-Time ECN enables some discernment in the decision making rather
Alexander, et al. Expires August 15, 2005 [Page 3]
Internet-Draft Real-time ECN Admission Control February 2005
than wholesale denial of sessions.
Also, Real-Time ECN does not introduce a significant amount of
overhead to the network. Not every node in the network needs to be
ECN-capable. Only those nodes located at congestion points need the
capability. At the nodes, ECN metering and marking is quick. There
is practically no real-time hit to the routing. An ECN node does not
maintain flow state and does not add delay with any intricate policy
decisions. It's impact on the network is very low.
The remainder of this memo provides four examples depicting ECN-based
probing for admission control. While the examples provided are
protocol-agnostic, general recommendations are provided as to how the
payload format defined in [2] should be used in the context of
admission control. No protocol-specific signaling is defined or
suggested herein to show how to use the payload while admitting a new
session.
Alexander, et al. Expires August 15, 2005 [Page 4]
Internet-Draft Real-time ECN Admission Control February 2005
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and
indicate requirement levels for compliant implementations.
Alexander, et al. Expires August 15, 2005 [Page 5]
Internet-Draft Real-time ECN Admission Control February 2005
3. Admission Control
Admission control can use a probing mechanism to determine whether
there is available bandwidth for a session. The endpoints of a
session perform this probing which occurs during session setup.
Depending upon results of the probing mechanism, the session will be
either admitted or denied. This decision can be made within an
endpoint, or by a session server.
3.1 Probing Mechanism
The probing mechanism makes use of "Congestion Notification Process
for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing"
[2]. It can be either uni-directional or bi-directional, but in
either case is end-to-end.
3.2 Usage Examples
Four usage examples are provided. These cover use of the RTP payload
format in [2] in both one-way and two-way loop-back mechanisms, both
with and without detection of Cheaters along the media path. The
terminology used is defined in [2], as well.
All examples presume that probing starts at a point during session
setup when the Responder endpoint addressing information is known by
the Sender, and the dynamic payload type used for the packets
carrying the payload has been determined. As the immediate
application is admission control, the endpoints involved SHOULD NOT
begin alerting or otherwise notifying the user of a new session until
the admission control procedures determine whether to admit the new
session.
All examples list the relevant field contents where necessary. In a
real implementation, it is recommended that the payload be secured.
In order to ensure there is no confusion between different versions
of the referenced drafts, the following ECN bit definitions are used
in the four examples:
00 Not ECN-capable
10 ECN-capable, with no congestion experienced
11 ECN-capable, with congestion experienced at the first level
01 ECN-capable, with congestion experienced at the second level
3.2.1 One-way Mechanism without Cheater Detection
A one-way probing mechanism without cheater detection is the simplest
possible use of the payload format defined in [2]. The ECN field in
Alexander, et al. Expires August 15, 2005 [Page 6]
Internet-Draft Real-time ECN Admission Control February 2005
the IP header MUST be set to 10, indicating that the endpoint is
ECN-capable. The Version field MUST be set appropriately, i.e., for
this memo, to zero. The remaining fields SHOULD be set to zero. If
the session for which admission control is two-way, then two of these
one-way mechanisms can be used for admission control, one in each
direction.
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 1: One-way Mechanism without Cheater Detection
1. Endpoint (EP) A starts the process. It creates a Request Probe
Packet and sends it to the address and port it has for EP B.
IP Header:
DSCP: <specific to application media>
ECN: 10, indicating endpoint is ECN-capable
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
2. Router A receives the Request Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Request
Probe Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured rate:
ReqECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Alexander, et al. Expires August 15, 2005 [Page 7]
Internet-Draft Real-time ECN Admission Control February 2005
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
4. EP B receives the Request Probe Packet. The ECN value, ReqECN,
in the IP header indicates the highest level of congestion on the
path towards EP B.
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
5. EP B inspects the ECN value, ReqECN, in the IP header, then knows
the highest level of congestion on the path towards EP B. Based
on this, EP B can determine whether the session should be
admitted.
3.2.2 Two-way/Loop-back Mechanism without Cheater Detection
The two-way probing mechanism without cheater detection is not that
much more complicated than the one-way probing mechanism, although it
does utilize one additional payload field. The most noticable
difference is that a Response Probe Packet is sent in response to the
Request Probe Packet. The ECN field in the IP headers MUST be set to
10, indicating that the endpoints are ECN-capable. The Version field
MUST be set appropriately, i.e., for this memo, to zero. The SCI
field in the Request Probe Packet SHOULD be set to zero, and in the
Response Probe Packet should be set to the ECN value in the IP header
of the associated Request Probe Packet. The remaining fields SHOULD
be set to zero.
With a two-way/loop-back probing mechanism, the congestion indication
for both the upstream and downstream packet flows can be determined
with a single procedure, as illustrated by this example.
Alexander, et al. Expires August 15, 2005 [Page 8]
Internet-Draft Real-time ECN Admission Control February 2005
(1) (2) (3) (4)
+------+ +----------+ +------+
| | ----> | Router A | ----> | |
| | +----------+ | |
(9) | EP A | | EP B |
| | +----------+ | |
| | <---- | Router B | <---- | |
+------+ +----------+ +------+
(8) (7) (6) (5)
Figure 2: Two-way/Loop-back Mechanism without Cheater Detection
1. Endpoint (EP) A starts the process. It creates a Request Probe
Packet and sends it to the address and port it has for EP B.
IP Header:
DSCP: <specific to application media>
ECN: 10, indicating endpoint is ECN-capable
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
2. Router A receives the Request Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Request
Probe Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured rate:
ReqECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
4. EP B receives the Request Probe Packet. The ECN value, ReqECN,
in the IP header indicates the highest level of congestion on the
Alexander, et al. Expires August 15, 2005 [Page 9]
Internet-Draft Real-time ECN Admission Control February 2005
path towards EP B. This completes the first half of the
two-way/loop-back probe.
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
5. EP B creates a Response Probe Packet and sends it to the address
and port it has for EP A. Note the payload difference between
the Request Probe Packet sent by EP A and the Response Probe
Packet sent by EP B. First, the SCI field contains the ReqECN
value from the Request Probe Packet. Second, the SCI Sequence
Number field contains the value of the Sequence Number field in
the RTP header of the Request Probe Packet.
IP Header:
DSCP: <specific to application media>
ECN: 10, indicating endpoint is ECN-capable
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: 00
SCI Sequence Number: <Sequence Number value from RTP header in
Request Probe Packet>
Reserved: 0000 0000
6. Router B receives the Response Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
7. Router B re-marks the ECN field in the IP header of the Response
Probe Packet as described in [1], then forwards the packet.
IP Header:
Alexander, et al. Expires August 15, 2005 [Page 10]
Internet-Draft Real-time ECN Admission Control February 2005
DSCP: <specific to application media>
ECN: <updated according to measured rate:
RspECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: 00
SCI Sequence Number: <Sequence Number value from RTP header in
Request Probe Packet>
Reserved: 0000 0000
8. EP A receives the Response Probe Packet. The ECN value, RspECN,
in the IP header indicates the highest level of congestion on
path towards EP A. This completes the second half of the
two-way/loop-back probe.
IP Header:
DSCP: <specific to application media>
ECN: <RspECN: value indicating highest
congestion marking on path towards EP A>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: 00
SCI Sequence Number: <Sequence Number value from RTP header in
Request Probe Packet>
Reserved: 0000 0000
9. EP A inspects the two ECN values, RspECN (in the IP header) and
ReqECN (in the admcntl payload), then knows the highest level of
congestion on the paths between EP A and EP B. Based on this, EP
A can determine whether the session should be admitted.
3.2.3 One-way Mechanism with Cheater Detection
A one-way probing mechanism with cheater detection differs from the
first example in two respects. First, the SCI field in the Request
Probe Packet contains the ECN value set in the ECN field in the IP
header. Second, additional processing in EP B is necessary to
determine if there are Cheaters present on the path towards EP B. In
order to perform Cheater detection, more than one Request Probe
Alexander, et al. Expires August 15, 2005 [Page 11]
Internet-Draft Real-time ECN Admission Control February 2005
Packet must be sent, each with different ECN values in the IP header,
as described in [1].
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 3: One-way Mechanism with Cheater Detection
1. Endpoint (EP) A starts the process. It creates a Request Probe
Packet and sends it to the address and port it has for EP B. At
least three Request Probe Packets are sent. A random ordering of
the three ECN value 10, 11, or 01 is chosen, and these values are
used in sequential Request Probe Packets for the ECN value in the
IP header and the SCI field in the admcntl payload. Refer to [1]
for additional details. At least three Request Probe Packets are
needed so that three sequential packets are received by the
Responder in order to determine the actual marking from the
routers along the network path.
IP Header:
DSCP: <specific to application media>
ECN: <10, 11, or 01; Refer to [1] for details>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ECN value used in IP header of original
Request Probe Packet>
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
2. Router A receives the Request Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Request
Probe Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
Alexander, et al. Expires August 15, 2005 [Page 12]
Internet-Draft Real-time ECN Admission Control February 2005
ECN: <updated according to measured rate:
ReqECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ECN value used in IP header of original
Request Probe Packet>
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
4. EP B receives the Request Probe Packet. EP B tracks the ECN
value, ReqECN, from the IP header, and the SCI value from the
admcntl payload until it receives at least three out of four
sequential Request Probe Packets.
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ECN value used in IP header of original
Request Probe Packet>
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
5. Once EP B has received three sequential Request Probe Packets, it
can follow the steps described in [1] to both detect if Cheaters
are present on the path towards EP B, and to filter out the
highest actual level of congestion on path towards EP B. The
decision to admit is made based on whether Cheaters are present
and the level of congestion indicated by the ECN markings.
3.2.4 Two-way/Loop-back Mechanism with Cheater Detection
The two-way probing mechanism with cheater detection differs from the
second example mainly with respect to the content of the admcntl
fields in the Response Probe Packet. In the Response Probe Packet,
the SCI field contains the ECN value in the IP header of the
associated Request Probe Packet. The SCI Sequence Number field
contains the sequence number from the RTP header of the associated
Request Probe Packet.
Alexander, et al. Expires August 15, 2005 [Page 13]
Internet-Draft Real-time ECN Admission Control February 2005
In the Request Probe Packet, all admcntl payload fields SHOULD be set
to zero.
(1) (2) (3) (4)
+------+ +----------+ +------+
| | ----> | Router A | ----> | |
| | +----------+ | |
(9) | EP A | | EP B |
| | +----------+ | |
| | <---- | Router B | <---- | |
+------+ +----------+ +------+
(8) (7) (6) (5)
Figure 4: Two-way/Loop-back Mechanism with Cheater Detection
1. Endpoint (EP) A starts the process. It creates a Request Probe
Packet and sends it to the address and port it has for EP B. At
least three Request Probe Packets are sent. A random ordering of
the three ECN value 10, 11, or 01 is chosen, and these values are
used in sequential Request Probe Packets for the ECN value in the
IP header and the SCI field in the admcntl payload. Refer to [1]
for additional details. At least three Request Probe Packets are
needed so that three sequential packets are received by the
Responder in order to determine the actual marking from the
routers along the network path. EP A must track the ECN value
used by sequence number for use in steps 8 and 9 below. Refer to
[1] for additional details. All other admcntl fields are zero
IP Header:
DSCP: <specific to application media>
ECN: <10, 11, or 01; Refer to [1] for details>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
2. Router A receives the Request Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Request
Probe Packet as described in [1], then forwards the packet.
Alexander, et al. Expires August 15, 2005 [Page 14]
Internet-Draft Real-time ECN Admission Control February 2005
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured rate:
ReqECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
4. EP B receives the Request Probe Packet. The ECN value, ReqECN,
in the IP header indicates the highest level of congestion on the
path towards EP B. This completes the first half of the
two-way/loop-back probe.
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: 00
RCI: 00
SCI Sequence Number: 0000 0000 0000 0000
Reserved: 0000 0000
5. EP B creates a Response Probe Packet and sends it to the address
and port it has for EP A. Note the payload difference between
the Request Probe Packet sent by EP A and the Response Probe
Packet sent by EP B. First, the SCI field contains the ReqECN
value from the Request Probe Packet. Second, the SCI Sequence
Number field contains the value of the Sequence Number field in
the RTP header of the Request Probe Packet. Similar to the
Request Probe Packet, the ECN value in the IP header of the
Response Probe Packet and the SCI field in the admcntl payload
are set with one of 10, 11, or 01.
IP Header:
DSCP: <specific to application media>
Alexander, et al. Expires August 15, 2005 [Page 15]
Internet-Draft Real-time ECN Admission Control February 2005
ECN: <10, 11, or 01; Refer to [1] for details>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: <ECN value used in IP header of original
Response Probe Packet>
SCI Sequence Number: <Sequence Number from associated Request
Probe Packet>
Reserved: 0000 0000
6. Router B receives the Response Probe Packet, and factors it into
the methods described in [1] for real-time inelastic traffic.
7. Router B re-marks the ECN field in the IP header of the Response
Probe Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured rate:
RspECN>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: <ECN value used in IP header of original
Response Probe Packet>
SCI Sequence Number: <Sequence Number from associated Request
Probe Packet>
Reserved: 0000 0000
8. EP A receives the Response Probe Packet. EP A tracks the ECN
values ReqECN (from the SCI field in the admcntl payload), RspECN
(from the ECN field in the IP header of the Response Probe
Packet), and RCI from the admcntl payload. It uses the SCI
Sequence Number value to associate these three values with the
appropriate ECN value used step 1 above. It tracks these values
until it receives at least three sequential Request Probe
Packets.
IP Header:
Alexander, et al. Expires August 15, 2005 [Page 16]
Internet-Draft Real-time ECN Admission Control February 2005
DSCP: <specific to application media>
ECN: <RspECN: value indicating highest
congestion marking on path towards EP A>
RTP Header:
Payload Type: <dynamically selected>
admcntl Payload:
Version: 0000
SCI: <ReqECN: value indicating highest
congestion marking on path towards EP B>
RCI: <ECN value used in IP header of original
Response Probe Packet>
SCI Sequence Number: <Sequence Number from associated Request
Probe Packet>
Reserved: 0000 0000
9. Once EP A has received three sequential Response Probe Packets,
it can follow the steps described in [1] to both detect if
Cheaters are present on both of the paths, towards EP B and
towards EP B, and to filter out the highest actual level of
congestion on both of the paths. The decision to admit is made
based on whether Cheaters are present and the level of congestion
indicated by the ECN markings.
Alexander, et al. Expires August 15, 2005 [Page 17]
Internet-Draft Real-time ECN Admission Control February 2005
4. Security Considerations
Refer to "Congestion Notification Process for Real-Time Traffic" [1]
and "RTP Payload Format for ECN Probing" [2] for security-related
considerations.
Alexander, et al. Expires August 15, 2005 [Page 18]
Internet-Draft Real-time ECN Admission Control February 2005
5. IANA Considerations
There are no IANA considerations.
Alexander, et al. Expires August 15, 2005 [Page 19]
Internet-Draft Real-time ECN Admission Control February 2005
6. IAB Considerations
There are no IAB considerations.
Alexander, et al. Expires August 15, 2005 [Page 20]
Internet-Draft Real-time ECN Admission Control February 2005
7. Acknowledgements
The authors acknowledge a great many inputs, including the following:
John Rutledge, Marvin Krym, Stephen Dudley, and Kwok Ho Chan.
Alexander, et al. Expires August 15, 2005 [Page 21]
Internet-Draft Real-time ECN Admission Control February 2005
8. References
8.1 Normative References
[1] Babiarz, J., Chan, K. and V. Firoiu, "Congestion Notification
Process for Real-Time Traffic, draft-babiarz-tsvwg-rtecn-03",
Internet-Draft Work in Progress, February 2005.
[2] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN
Probing, draft-alexander-rtp-payload-for-ecn-probing-00",
Internet-Draft Work in Progress, February 2005.
8.2 Informative References
[3] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
Authors' Addresses
Corey W. Alexander (editor)
Nortel
MS 08704A30
2370 Performance Drive
Richardson, TX 75287
USA
Phone: +1 972 684-8320
Email: coreya@nortel.com
Jozef Z. Babiarz
Nortel
MS 04331C04
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763-6098
Email: babiarz@nortel.com
Alexander, et al. Expires August 15, 2005 [Page 22]
Internet-Draft Real-time ECN Admission Control February 2005
Jeremy P. Matthews
Nortel
MS 08704A30
2370 Performance Drive
Richardson, TX 75082
USA
Phone: +1 972 684-0336
Email: jeremym@nortel.com
Alexander, et al. Expires August 15, 2005 [Page 23]
Internet-Draft Real-time ECN Admission Control 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.
Alexander, et al. Expires August 15, 2005 [Page 24]