[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Session Initiation Proposal                            C. Alexander, Ed.
Investigation                                                J. Rutledge
Internet-Draft                                                    Nortel
Expires: January 12, 2006                                  July 11, 2005


  A Congestion Status Precondition for the Session Initiation Protocol
                                 (SIP)
         draft-alexander-congestion-status-preconditions-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 defines the Congestion Status precondition for SIP,
   utilizing the framework defined in RFC 3312 and updated in RFC 4032.
   The Congestion Status precondition requires that the participant
   verify that congestion thresholds along the network path for the
   session media have not been exceeded before continuing with session
   establishment or modification.  This verification is performed via an
   RTP probe utilizing draft "Congestion Notification Process for Real-



Alexander & Rutledge    Expires January 12, 2006                [Page 1]


Internet-Draft       Congestion Status Precondition            July 2005


   Time Traffic" and draft "RTP Payload Format for ECN Probing".

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Congestion Status Precondition Definition  . . . . . . . . . .  6
     4.1   Precondition Type Tag  . . . . . . . . . . . . . . . . . .  6
     4.2   Additional Data Type . . . . . . . . . . . . . . . . . . .  6
     4.3   Payload Type . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4   SDP Parameters . . . . . . . . . . . . . . . . . . . . . .  7
     4.5   Status Type  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.6   Precondition Strength  . . . . . . . . . . . . . . . . . .  7
     4.7   Direction Tag  . . . . . . . . . . . . . . . . . . . . . .  7
     4.8   Suspending and Resuming Session Establishment  . . . . . .  7
     4.9   Cessation of ECN Probing . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2   Informative References . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18


























Alexander & Rutledge    Expires January 12, 2006                [Page 2]


Internet-Draft       Congestion Status Precondition            July 2005


1.  Introduction

   RFC 3312 [2], updated by RFC 4032 [3], defines the basic concept of
   preconditions, and a framework through which new preconditions can be
   defined.  This document defines a new Congestion Status precondition,
   "cong", that provides an admission control mechanism based on whether
   there is congestion in the network.

   An entity can use the Congestion Status precondition to delay session
   establishment or modification until a determination can be made that
   congestion thresholds along the network path between the offerer and
   answerer have not been exceeded.  When a mandatory Congestion Status
   precondition is received in an offer, session establishment or
   modification MUST be delayed until the Congestion Status precondition
   has been met, i.e., the Explicit Congestion Notification (ECN) value
   in ECN probe packets, as defined in "RTP Payload Format for ECN
   Probing" [6], explicitly indicates that congestion thresholds along
   the network path for the new session media have not been exceeded.
   The Congestion Status precondition relies on "Congestion Notification
   Process for Real-Time Traffic" [5] to be implemented within select
   routers in the network, specifically those routers at which
   congestion is likely to occur.  It also relies on [6] and "Real-time
   ECN Use Cases" [7] for the end-systems to probe for congestion.  The
   probe streams received at each end-system are analyzed, and the ECN
   markings are used to either pass or fail the preconditions.


























Alexander & Rutledge    Expires January 12, 2006                [Page 3]


Internet-Draft       Congestion Status Precondition            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 RFC2119 [15] and
   indicate requirement levels for compliant implementations.













































Alexander & Rutledge    Expires January 12, 2006                [Page 4]


Internet-Draft       Congestion Status Precondition            July 2005


3.  Definitions

   The following terms are used in this document, many adopted directly
   from RFC 3264 [4]:

   Agent: An agent is the protocol implementation involved in the offer/
      answer exchange.  There are two agents involved in an offer/answer
      exchange.

   Answer: An SDP message sent by an answerer in response to an offer
      received from an offerer.

   Answerer: An agent which receives a session description from another
      agent describing aspects of desired media communication, and then
      responds to that with its own session description.

   ECN Probe Stream: [7] describes a stream of RTP packets whose payload
      consists of that described in [6].  The ECN probe stream is used
      to detect congestion in the network via the mechanisms described
      in [5].

   Media Stream: As defined in RFC 2326 [11], a media stream is a single
      media instance, e.g., an audio stream or a video stream as well as
      a single whiteboard or shared application group.  In SDP, a media
      stream is described by an "m=" line and its associated attributes.

   Offer: An SDP message sent by an offerer.

   Offerer: An agent which generates a session description in order to
      create or modify a session.





















Alexander & Rutledge    Expires January 12, 2006                [Page 5]


Internet-Draft       Congestion Status Precondition            July 2005


4.  Congestion Status Precondition Definition

   The Congestion Status precondition type is represented by "cong".

4.1  Precondition Type Tag

   The precondition-type tag for the Congestion Status precondition is
   "cong".  The resulting precondition-type grammar refined from that
   defined in [2] is:

     precondition-type  =  "cong" | "qos" | token


4.2  Additional Data Type

   A new type, additional-data, is defined for the desired-status
   attribute.  It is generically specified as follows:

     additional-data  = ""

   This tag allows preconditions to extend the desired-status attribute
   line with data specific to their function and behavior, while keeping
   the tag itself generic to any precondition that requires its use.

4.3  Payload Type

   [6] specifies a dynamic payload type for the ECN probe packets in an
   ECN probe stream.  The dynamic payload type values are defined in RFC
   3551 [12].  This will be specified on the desired-status line of the
   Congestion Status precondition as a value within the additional-data
   type.  For the specification of this value, a new type, payload-type,
   is defined for use with this precondition.  This also necessitates
   the modification of the additional-data type defined earlier.  The
   payload-type type is REQUIRED for the Congestion Status precondition.

     additional-data  = "" | payload-type
     payload-type     =  96-127

   The payload-type value specified in the initial INVITE offer
   specifying the Congestion Status precondition indicates the payload
   type the offerer and/or answerer will use to identify ECN probe
   packets in an ECN probe stream.  It SHOULD be used as the payload-
   type value in any ECN probe flows associated with the corresponding
   media type.  If the corresponding answer indicates a different
   payload-type value than that in the offer, then the payload-type
   value in the offer indicates the payload-type value the offerer
   expects to see for ECN probe packets it receives, and the payload-
   type value in the answer indicates the payload-type value the



Alexander & Rutledge    Expires January 12, 2006                [Page 6]


Internet-Draft       Congestion Status Precondition            July 2005


   answerer expects to see for ECN probe packets it receives.

4.4  SDP Parameters

   Based on the new precondition-type value, and the new additional-data
   and payload-type types, the SDP parameters specified in [2] are
   modified as follows:

     desired-status     =  "a=des" precondition-type
                           SP strength-tag SP status-type
                           SP direction-tag SP additional-data
     precondition-type  =  "cong" | "qos" | token
     additional-data    =  "" | payload-type
     payload-type       =  96-127


4.5  Status Type

   The Congestion Status precondition MUST support the end-to-end status
   type as defined in [2].  An implementation MAY support the segmented
   status types.

4.6  Precondition Strength

   The Congestion Status precondition is defined as a mandatory
   precondition.  Note that use of a mandatory precondition requires the
   presence of a Require header with the option tag "precondition".

4.7  Direction Tag

   As described in [2], the direction tags represent the point of view
   of the entity generating the SDP description.  For example, in an
   offer, "send" is the direction offerer->answerer, while in an answer,
   "send" is the direction answerer->offerer.

4.8  Suspending and Resuming Session Establishment

   When the preconditions requirement is accepted by the answerer,
   session setup is suspended until the preconditions are met or fail.
   During  this suspension of session setup, neither the offerer or
   answerer provide any type of ringing.

   The Congestion Status precondition allows one or both of the offerer
   and answerer to verify during session setup, before ringing begins,
   that there is adequate bandwidth available in the network for the
   associated session media.  It utilizes the probe payload defined in
   [6], and a probing mechanism such as that desribed in [7], to probe
   for congestion in the network.  If the probe indicates that the



Alexander & Rutledge    Expires January 12, 2006                [Page 7]


Internet-Draft       Congestion Status Precondition            July 2005


   congestion thresholds along the network path have not been exceeded,
   the preconditions are met.  Otherwise, they are failed.

   In the example SDPs that follow, note that there is no rtpmap
   attribute in the SDP associated with ECN probing.  This is because
   the probing mechanism and payload format are implicitly linked to the
   Congestion Status precondition, as can be seen by the payload-type
   value associated with the desired-status attribute of this
   precondition.  Only the rtpmap attribute for the session media is
   explicitly described in the SDP.

   [6] also describes that the probe flow can optionally mimic various
   properties of the session media, specifically the send rate.  This is
   determined implicitly, as well, based on the preferred media
   specified in the SDP.

       Offerer                                      Answerer

          |                                            |
          |------------ (1) INVITE SDP1 -------------->|
          |                                            |
          |<----- (2) 183 Session Progress SDP2 -------|
          |                                            |
          |<========= (3) RTP Probe Flow ==============|
          |                                            |
          |========== (4) RTP Probe Flow =============>|
          |                                            |
          |--------------- (5) PRACK ----------------->|
          |                                            |
          |<---------- (6) 200 OK (PRACK) -------------|
          |                                            |
          |------------ (7) UPDATE SDP3 -------------->|
          |                                            |
          |<------- (8) 200 OK (UPDATE) SDP4 ----------|
          |                                            |
          |<------------ (9) 180 Ringing --------------|
          |                                            |
          |---------------- (10) PRACK --------------->|
          |                                            |
          |<----------- (11) 200 OK (PRACK) -----------|
          |                                            |
          |                                            |
          |                                            |
          |<---------- (12) 200 OK (INVITE) -----------|
          |                                            |
          |----------------- (13) ACK ---------------->|
          |                                            |




Alexander & Rutledge    Expires January 12, 2006                [Page 8]


Internet-Draft       Congestion Status Precondition            July 2005


   In SDP1, the offerer specifies a mandatory end-to-end Congestion
   Status precondition with "sendrecv" as the desired status. "sendrecv"
   indicates that congestion must be checked in both the send and
   receive direction, from the point of view of the offerer.  The
   offerer's local status table is:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     no    |    mandatory     |    no
          recv    |     no    |    mandatory     |    no

   The SDP content for SDP1 is:

   m=audio 50002 RTP/AVP 0 8 18
   c=IN IP4 192.168.1.200
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=curr:cong e2e none
   a=des:conn mandatory e2e sendrecv 104

   SDP1 carries to the answerer the IP address and port number for the
   offerer.  Note that the value 104 is specified on the desired-status
   line as the payload-type value that the offerer expects to see for
   ECN probe packets.

   Once the offerer sends SDP1, it MUST begin listening for probe
   packets on the IP address and port number associated with the
   Congestion Status precondition in SDP1.

   In SDP2, the answerer responds indicating that it wants the offerer
   to inform it about the congestion status in the network from the
   answerer to the offerer.  The answerer's local status table is:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     no    |    mandatory     |    no
          recv    |     no    |    mandatory     |    no

   The answerer indicates that it wants the offerer to inform it about
   congestion from the answerer to the offerer by using the confirm-
   status attribute.  The SDP content for SDP2 is:









Alexander & Rutledge    Expires January 12, 2006                [Page 9]


Internet-Draft       Congestion Status Precondition            July 2005


   m=audio 51286 RTP/AVP 0 8 18
   c=IN IP4 192.168.1.235
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=curr:cong e2e none
   a=des:conn mandatory e2e sendrecv 104
   a=conf:cong e2e send

   SDP2 carries to the offerer the IP address and port number for the
   answerer.  Note that the value 104 is specified on the desired-status
   line, unchanged from SDP1, as the payload-type value the answerer
   expects to see for ECN probe packets.

   Once the answerer sends SDP2, it MUST begin listening for probe
   packets on the IP address and port number associated with the
   Congestion Status precondition in SDP2.  It MUST also begin
   generating a stream of probe packets to the IP address and port
   number for the offerer that it determined from SDP1.  The probe
   packets MUST adhere to the format defined in [6], optionally padded
   to a size corresponding to the codec to be used for session media.

   When the offerer receives SDP2, it updates its local status table to
   reflect the confirm-status attribute as follows:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     no    |    mandatory     |    no
          recv    |     no    |    mandatory     |    yes

   The offerer MUST also begin generating a stream of probe packets to
   the IP address and port number for the answerer that it determined
   from SDP2.  The probe packets MUST adhere to the format defined in
   [6], optionally padded to a size corresponding to the codec to be
   used for session media.

   Both the offerer and answerer, upon receiving the stream of probe
   packets, determines whether congestion is present in the network by
   applying [5].

   As the offerer receives the stream of probe packets from the answerer
   indicating that congestion thresholds along the network path have not
   been exceeded, the offerer's local status table is updated to:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     no    |    mandatory     |    no
          recv    |     yes   |    mandatory     |    yes



Alexander & Rutledge    Expires January 12, 2006               [Page 10]


Internet-Draft       Congestion Status Precondition            July 2005


   As the answerer receives the stream of probe packets from the offerer
   indicating that congestion thresholds along the network path have not
   been exceeded, the answerer's local status table is updated to:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     no    |    mandatory     |    no
          recv    |     yes   |    mandatory     |    no

   The answerer now waits on the offerer to confirm the congestion
   status in the network from the answerer to the offerer.  The offerer
   generates and sends SDP3 in an UPDATE request as follows:

   m=audio 50002 RTP/AVP 0 8 18
   c=IN IP4 192.168.1.200
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=curr:cong e2e recv
   a=des:conn mandatory e2e sendrecv 104

   The answerer uses SDP3 to update its local status table as follows:

        Direction |   Current | Desired Strength | Confirm
       -----------+-----------+------------------+---------
          send    |     yes   |    mandatory     |    no
          recv    |     yes   |    mandatory     |    no

   Should the UPDATE request from the offerer arrive at the answerer
   before the stream of probe packets from the offerer, the answerer
   sends a 500 Server Internal Error response with the Retry-After
   header indicating the request should be attempted again in 1-3
   seconds.

   At this point, the Congestion Status precondition has been
   successfully met.  The answerer responds with SDP4 as follows:

   m=audio 51286 RTP/AVP 0 8 18
   c=IN IP4 192.168.1.235
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=curr:cong e2e sendrecv
   a=des:conn mandatory e2e sendrecv 104

   As the Congestion Status precondition has now been met, ringing
   begins with the answerer sending a 180 Ringing response.




Alexander & Rutledge    Expires January 12, 2006               [Page 11]


Internet-Draft       Congestion Status Precondition            July 2005


4.9  Cessation of ECN Probing

   The ECN probe stream(s) generated as a result of the Congestion
   Status precondition MAY be terminated by the answer after receiving
   an UPDATE request from the offerer containing SDP3 and/or by the
   offerer after receiving either a 200 UPDATE response from the
   answerer containing SDP4, or a 580 Precondition Failure final
   response.

   Alternatively, the ECN probe stream(s) MAY continue to be generated
   after preconditions are met successfully.  In this case, the ECN
   probe stream(s) started after the 183 Session Progress message was
   sent/received MAY continue to be sent, until either session
   establishment is aborted via a CANCEL from the offerer or a final
   response from the answerer, or the session is established.  The
   agents MUST continue to monitor the ECN probe stream(s) for network
   congestion.  If detected, local policy will be used to dictate the
   action to be taken.  The typical action upon detection of congestion
   is to terminate the session setup with a CANCEL message if congestion
   is detected by the offerer, or a 503 Service Unavailable final
   response if detected by the answerer.

   If the session is established, both the offerer and/or answerer
   SHOULD stop sending their respective ECN probe stream(s), and
   immediately begin sending session media.  The answerer MAY do this as
   soon as it sends the 200 OK indicating that the session is
   established.  The offerer MAY do this as soon as it receives the 200
   OK indicating that the session was established.























Alexander & Rutledge    Expires January 12, 2006               [Page 12]


Internet-Draft       Congestion Status Precondition            July 2005


5.  Security Considerations

   [2] and [3] describe security considerations for preconditions.  In
   addition, security considerations specific to the Congestion Status
   precondition are described here.

   [5] and [6] describe security considerations for the Real-time ECN
   mechanism and the associated RTP payload format.  They consider the
   possibility of devices attempting to change the level of congestion
   reported by the ECN probe stream, and describe mechanisms to detect
   such changes.

   Similar to the recommendations in [5] and [6], the RTP packets in the
   ECN probe stream(s) SHOULD be secured, and the SIP/SDP messaging
   SHOULD also be secured with S/MIME [8] or TLS [9], [10].

   This precondition utilizes an RTP stream - the ECN probe stream - to
   detect congestion during session setup.  A denial of service attack
   is possible, but harbors little more risk than for any other RTP
   media stream.  The ECN probe stream is only generated during session
   setup, prior to answer, so the agents involved only listen and expect
   such a stream during this time. [5] discusses the possibility of a
   denial of service attack in which false congestion is reported.




























Alexander & Rutledge    Expires January 12, 2006               [Page 13]


Internet-Draft       Congestion Status Precondition            July 2005


6.  IANA Considerations

   This document extends the desired-status SDP attribute defined in [2]
   with two new types, additional-data and payload-type.  These are
   described in Section 4.2 and Section 4.3.

   This document defines the following precondition, with the request
   that it be registered by the IANA:

   Precondition-Type    Reference       Description
   -----------------    -------------   ------------------------------
   cong                 This document   Congestion Status precondition







































Alexander & Rutledge    Expires January 12, 2006               [Page 14]


Internet-Draft       Congestion Status Precondition            July 2005


7.  Acknowledgements

   The authors acknowledge a great many inputs, including the following:
   Francois Audet, Jeremy Matthews, and Stephen Dudley.















































Alexander & Rutledge    Expires January 12, 2006               [Page 15]


Internet-Draft       Congestion Status Precondition            July 2005


8.  References

8.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Camarillo, G., Marshall, B., and J. Rosenberg, "Integration of
        Resource Management and Session Initiation Protocol (SIP)",
        RFC 3312, June 2002.

   [3]  Camarillo, G. and P. Kyzivat, "Update to the Session Initiation
        Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.

   [4]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [5]  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.

   [6]  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.

8.2  Informative References

   [7]   Alexander, C., Ed., Babiarz, J., and J. Matthews, "Real-time
         ECN Use Cases", Internet-Draft
         draft-alexander-rtecn-use-cases-00.txt (Work in Progress),
         July 2005.

   [8]   Peterson, J., "S/MIME Advanced Encryption Standard (AES)
         Requirement for the Session Initiation Protocol (SIP)",
         RFC 3853, July 2004.

   [9]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [10]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
         T. Wright, "Transport Layer Security (TLS) Extensions",
         RFC 3546, June 2003.

   [11]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.




Alexander & Rutledge    Expires January 12, 2006               [Page 16]


Internet-Draft       Congestion Status Precondition            July 2005


   [12]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
         Conferences with Minimal Control", RFC 3551, July 2003.

   [13]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in the Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [14]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, September 2002.

   [15]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.


Authors' Addresses

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

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


   John Rutledge
   Nortel
   MS 08704A30
   2370 Performance Drive
   Richardson, Texas  75082
   US

   Phone: +1 972 684-7528
   Email: jrutledg@nortel.com















Alexander & Rutledge    Expires January 12, 2006               [Page 17]


Internet-Draft       Congestion Status Precondition            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 & Rutledge    Expires January 12, 2006               [Page 18]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/