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]