Internet DRAFT - draft-alexander-rtecn-use-cases

draft-alexander-rtecn-use-cases






Network Working Group                                  C. Alexander, Ed.
Internet-Draft                                                J. Babiarz
Expires: January 12, 2006                                    J. Matthews
                                                                  Nortel
                                                           July 11, 2005


                        Real-time ECN Use Cases
                 draft-alexander-rtecn-use-cases-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes use cases for the mechanisms described in
   draft "Congestion Notification Process for Real-Time Traffic" and the
   RTP payload format defined in draft "RTP Payload Format for ECN
   Probing".  Specifically, it describes admission control and
   preemption use cases.





Alexander, et al.       Expires January 12, 2006                [Page 1]

Internet-Draft           Real-time ECN Use Cases               July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Admission Control  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Probing Mechanism  . . . . . . . . . . . . . . . . . . . .  6
     3.2   Delaying Session Establishment . . . . . . . . . . . . . .  6
     3.3   Usage Examples . . . . . . . . . . . . . . . . . . . . . .  6
       3.3.1   Unidirectional Probing without Cheater Detection . . .  7
       3.3.2   Unidirectional Probing with Cheater Detection  . . . .  9
       3.3.3   Bidirectional Mechanisms . . . . . . . . . . . . . . . 11
   4.  Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1   Usage Example  . . . . . . . . . . . . . . . . . . . . . . 12
     4.2   Preemption Guidelines  . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2   Informative References . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 21




























Alexander, et al.       Expires January 12, 2006                [Page 2]

Internet-Draft           Real-time ECN Use Cases               July 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.

   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 bandwidth available.
   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
   than wholesale denial of sessions.

   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 routers mark the ECN bits in the IP headers of the probe
   packets according to the routers' 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



Alexander, et al.       Expires January 12, 2006                [Page 3]

Internet-Draft           Real-time ECN Use Cases               July 2005


   precedence.

   This document also proposes a preemption solution based on [1] and
   [2].  This relies on endpoints monitoring the ECN value of incoming
   media packets, specifically for the second level of congestion.  When
   present, the endpoint can initiate a preemption mechanism as dictated
   by local policy.

   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.  Its impact on the network is very low.

   The remainder of this memo provides two high-level examples depicting
   unidirectional ECN-based probing for admission control, plus a
   section describing how the same unidirectional probing can be used
   twice to provide bidirectional probing.  It also provides a single
   high-level example depicting preemption.  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.

   This document replaces a prior draft, "Admission Control Use Case for
   Real-time ECN" [5].






















Alexander, et al.       Expires January 12, 2006                [Page 4]

Internet-Draft           Real-time ECN Use Cases               July 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 January 12, 2006                [Page 5]

Internet-Draft           Real-time ECN Use Cases               July 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 during session setup, having first
   delayed session establishment.  Depending upon the 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 [1] and [2].  The mechanism is
   unidirectional, but bidirectional probing is possible using two
   unidirectional probes.  In either case, probing is end-to-end.

3.2  Delaying Session Establishment

   Session establishment should be delayed during the admission control
   process, at a minimum to avoid indicating the new session to the
   users prematurely, before an admission decision has been made.  For
   SIP, preconditions can accomplish this as described in "A Congestion
   Status Precondition for the Session Initiation Protocol (SIP)" [3].

3.3  Usage Examples

   Two usage examples are provided.  These cover use of the RTP payload
   format in [2] with unidirectional probing, both with and without
   detection of Cheaters along the media path.  A third section
   describes how bidirectional probing is accomplished.  The terminology
   used is defined in [2].

   All examples presume that probing starts at a point during session
   setup when the Receiver 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:





Alexander, et al.       Expires January 12, 2006                [Page 6]

Internet-Draft           Real-time ECN Use Cases               July 2005




   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.3.1  Unidirectional Probing without Cheater Detection

   A unidirectional probing mechanism without cheater detection is the
   simplest possible use of the payload format defined in [2].  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 being performed is bidirectional, then
   two of these unidirectional probes can be used, one in each
   direction.

              (1)                (3)
       +------+       +----------+       +------+
       |      |       |          |       |      |
       | EP A | ----> | Router A | ----> + EP B | (5)
       |      |       |          |       |      |
       +------+       +----------+       +------+
                    (2)                (4)

        Figure 1: Unidirectional Probing without Cheater Detection

   1.  Endpoint (EP) A starts the process.  It creates a Probe Packet
       and sends it to the address and port it has for EP B.

         IP Header:
            DSCP:          <specific to application media>
            ECN:           10

         RTP Header:
            Payload Type:  <dynamically selected>

         ECN Probe Payload:
            Version:       0000
            ECN:           00
            IRSN:          0000 0000 0000 0000
            Reserved:      00 0000 0000





Alexander, et al.       Expires January 12, 2006                [Page 7]

Internet-Draft           Real-time ECN Use Cases               July 2005


   2.  Router A receives the Probe Packet, and applies to it the methods
       described in [1] for real-time inelastic traffic.


   3.  Router A re-marks the ECN field in the IP header of the Probe
       Packet as described in [1], then forwards the packet.

         IP Header:
            DSCP:          <specific to application media>
            ECN:           <updated according to measured
                            bandwidth: ReqECN>

         RTP Header:
            Payload Type:  <dynamically selected>

         ECN Probe Payload:
            Version:       0000
            ECN:           00
            IRSN:          0000 0000 0000 0000
            Reserved:      00 0000 0000


   4.  EP B receives the 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
                            level on path towards EP B>

         RTP Header:
            Payload Type:  <dynamically selected>

         ECN Probe Payload:
            Version:       0000
            ECN:           00
            IRSN:          0000 0000 0000 0000
            Reserved:      00 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.






Alexander, et al.       Expires January 12, 2006                [Page 8]

Internet-Draft           Real-time ECN Use Cases               July 2005


3.3.2  Unidirectional Probing with Cheater Detection

   A unidirectional probing mechanism with cheater detection differs
   from the first example in two respects.  First, the ECN field in the
   Probe Packet contains the ECN value set in the ECN field in the IP
   header.  Second, the IRSN field contains the initial RTP sequence
   number selected randomly by EP A for the associated RTP media stream.
   This may be used by the endpoints for cheater detection after the
   real media exchange begins.  Third, 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
   Probe Packet must be sent, each with different ECN values in the IP
   header, as described in [1].  As with the first example, if the
   session for which admission control is being performed is
   bidirectional, then two of these unidirectional probes can be used,
   one in each direction.

              (1)                (3)
       +------+       +----------+       +------+
       |      |       |          |       |      |
       | EP A | ----> | Router A | ----> + EP B | (5)
       |      |       |          |       |      |
       +------+       +----------+       +------+
                    (2)                (4)

        Figure 5: Unidirectional Probing without Cheater Detection

   1.  Endpoint (EP) A starts the process.  It creates a Probe Packet
       and sends it to the address and port it has for EP B. At least
       three Probe Packets are sent.  A random ordering of the three ECN
       value 01, 10, and 11 is chosen, and these values are used in
       sequential Probe Packets as the ECN value in the IP header and
       the ECN field in the ECN Probe Payload.  Refer to [1] for
       additional details.  At least three Probe Packets are needed so
       that three sequential packets are received by the Receiver in
       order to determine the actual marking from the routers along the
       network path.














Alexander, et al.       Expires January 12, 2006                [Page 9]

Internet-Draft           Real-time ECN Use Cases               July 2005


         IP Header:
            DSCP:          <specific to application media>
            ECN:           <01, 10, or 11>

         RTP Header:
            Payload Type:  <dynamically selected>

         ECN Probe Payload:
            Version:       0000
            ECN:           <ECN value used in IP header of original
                            Probe Packet>
            IRSN:          <Initial sequence number value randomly
                            selected by EP A>
            Reserved:      00 0000 0000


   2.  Router A receives the Probe Packet, and applies to it the methods
       described in [1] for real-time inelastic traffic.


   3.  Router A re-marks the ECN field in the IP header of the 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>

         ECN Probe Payload:
            Version:       0000
            ECN:           <ECN value used in IP header of original
                            Probe Packet>
            IRSN:          <Initial sequence number value randomly
                            selected by EP A>
            Reserved:      00 0000 0000


   4.  EP B receives the Probe Packet.  EP B tracks the ECN value,
       ReqECN, from the IP header, and the ECN value from the ECN Probe
       Payload until it receives at least three sequential Probe
       Packets.








Alexander, et al.       Expires January 12, 2006               [Page 10]

Internet-Draft           Real-time ECN Use Cases               July 2005


         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>

         ECN Probe Payload:
            Version:       0000
            ECN:           <ECN value used in IP header of original
                            Probe Packet>
            IRSN:          <Initial sequence number value randomly
                            selected by EP A>
            Reserved:      00 0000 0000


   5.  Once EP B has received three sequential 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.3.3  Bidirectional Mechanisms

   As described in each of the examples, bidirectional probing can be
   accomplished by utilizing two unidirectional probes, one in each
   direction.  As it is simply a combination of two unidirectional, it
   is not explicitly depicted here.



















Alexander, et al.       Expires January 12, 2006               [Page 11]

Internet-Draft           Real-time ECN Use Cases               July 2005


4.  Preemption

   The Real-time ECN mechanism defined in [1] can be used to provide
   preemption capabilities.  As with the unidirectional probe streams
   described in the context of admission control earlier, endpoints can
   similarly monitor the ECN value of RTP media packets and react
   accordingly to provide preemption.  If the first or second threshold
   levels are exceeded, as indicated by the ECN value of the media
   packets, local policy may dictate preemption as a required action to
   keep bandwidth usage within engineered limits.

4.1  Usage Example

   The example provided here shows only a unidirectional media flow.  A
   bidirectional session would operate similarly, but with two
   unidirectional flows in opposite directions.

   The example provided here describes a local policy dictating that
   preemption occurs when the second threshold level has been exceeded,
   as indicated by the ECN value of the media packets.

              (1)                (3)
       +------+       +----------+       +------+
       |      |       |          |       |      |
       | EP A | ----> | Router A | ----> + EP B | (5)
       |      |       |          |       |      |
       +------+       +----------+       +------+
                    (2)                (4)

                           Figure 9: Preemption

   1.  Endpoint (EP) A starts the process.  It creates an RTP media
       packet and sends it to the address and port it has for EP B. Each
       media packet is marked with ECN 10.  Refer to [1] for additional
       details.

         IP Header:
            DSCP:          <specific to application media>
            ECN:           10

         RTP Header:
            Payload Type:  <specific to application media>


   2.  Router A receives the RTP media packets, and applies to them the
       methods described in [1] for real-time inelastic traffic.





Alexander, et al.       Expires January 12, 2006               [Page 12]

Internet-Draft           Real-time ECN Use Cases               July 2005


   3.  Router A re-marks the ECN field in the IP header of the RTP media
       packets as described in [1], then forwards the packet.  For the
       purposes of this example, it is presumed that bandwidth exists
       such that Router A marks ECN 01 to indicate that the second level
       of congestion has been exceeded.

         IP Header:
            DSCP:          <specific to application media>
            ECN:           01

         RTP Header:
            Payload Type:  <specific to application media>


   4.  EP B receives the RTP media packets.  EP B monitors the ECN value
       of RTP media packets, and upon receiving packets marked with ECN
       01 to indicate that the second level of congestion has been
       exceeded somewhere along the path in the network, it follows
       local policy to initiate preemption.

         IP Header:
            DSCP:          <specific to application media>
            ECN:           01

         RTP Header:
            Payload Type:  <specific to application media>


   5.  The specific actions taken to carry out preemption may vary, but
       some general guidelines will be specified below.



4.2  Preemption Guidelines

   The specific actions taken to carry out preemption may vary, but some
   general guidelines can be specified.  Because the marking mechanism
   described in [1] functions on all packets with the appropriate DSCP
   code point, versus only on packets for an individual media flow,
   there needs to be a mechanism in place that can control the rate and
   number of sessions that are preempted.  In other words, allowing
   preemption to be performed immediately and directly within an
   endpoint that detects a preempting congestion level in the network
   would likely result in many more sessions being preempted than is
   necessary to bring bandwidth levels back under the preempting
   congestion level.  This is due to the likelihood that more than one
   endpoint will receive indication of the preemption congestion level
   via ECN markings on their respective RTP media packets.  It is



Alexander, et al.       Expires January 12, 2006               [Page 13]

Internet-Draft           Real-time ECN Use Cases               July 2005


   envisioned that when an endpoint detects this preempting congestion
   level, it will send an indication to a preempting device which will
   perform the actual preemption actions.  In SIP, this indication would
   take the form of an event package, and the preempting device would be
   a back-to-back user agent (B2BUA).

   Given this description, two things need to be considered.  First, the
   indications sent from the endpoints when the preempting congestion
   level is detected need to be throttled among all the endpoints that
   detect the preempting congtestion level.  This will reduce the number
   of indications sent at roughly the same time, and will allow the
   preempting device to more easily manage their arrival.  To accomplish
   this, local policy could specify that endpoints would send these
   indications only after a delay, selected randomly by the individual
   endpoints from a range of a zero to ten seconds.

   Second, to further ensure that no more preemptions occur than are
   necessary, the preempting device needs to pace the preemption rate,
   allowing a preemption and the resulting session termination time to
   propagate through the network.  This can be accomplished by limiting
   the rate of preemption to no less than one preemption every 500
   milliseconds.





























Alexander, et al.       Expires January 12, 2006               [Page 14]

Internet-Draft           Real-time ECN Use Cases               July 2005


5.  Security Considerations

   Refer to [1] and [2] for security-related considerations.
















































Alexander, et al.       Expires January 12, 2006               [Page 15]

Internet-Draft           Real-time ECN Use Cases               July 2005


6.  IANA Considerations

   There are no IANA considerations.
















































Alexander, et al.       Expires January 12, 2006               [Page 16]

Internet-Draft           Real-time ECN Use Cases               July 2005


7.  IAB Considerations

   There are no IAB considerations.
















































Alexander, et al.       Expires January 12, 2006               [Page 17]

Internet-Draft           Real-time ECN Use Cases               July 2005


8.  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 January 12, 2006               [Page 18]

Internet-Draft           Real-time ECN Use Cases               July 2005


9.  References

9.1  Normative References

   [1]  Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification
        Process for Real-Time Traffic", Internet-Draft
        draft-babiarz-tsvwg-rtecn-04.txt (Work in Progress), July 2005.

   [2]  Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN
        Probing", Internet-Draft
        draft-alexander-rtp-payload-for-ecn-probing-01.txt (Work in
        Progress), July 2005.

   [3]  Alexander, C., Ed. and J. Rutledge, "A Congestion Status
        Precondition for the Session Initiation Protocol (SIP)",
        Internet-Draft
        draft-alexander-congestion-status-preconditions-00.txt (Work in
        Progress), July 2005.

9.2  Informative References

   [4]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

   [5]  Alexander, C., Ed., Babiarz, J., and J. Matthews, "Admission
        Control Use Case for Real-time ECN", Internet-Draft
        draft-alexander-rtecn-admission-control-use-case-00.txt (Work in
        Progress), February 2005.


Authors' Addresses

   Corey W. Alexander (editor)
   Nortel
   MS 08704A30
   2370 Performance Drive
   Richardson, TX  75082
   USA

   Phone: +1 972 684-8320
   Email: coreya@nortel.com









Alexander, et al.       Expires January 12, 2006               [Page 19]

Internet-Draft           Real-time ECN Use Cases               July 2005


   Jozef Z. Babiarz
   Nortel
   MS 04331C04
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763-6098
   Email: babiarz@nortel.com


   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 January 12, 2006               [Page 20]

Internet-Draft           Real-time ECN Use Cases               July 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 January 12, 2006               [Page 21]