Internet DRAFT - draft-saurin-tsvwg-tfrc-testing

draft-saurin-tsvwg-tfrc-testing






Network Working Group                                          A. Saurin
Internet-Draft                                                C. Perkins
Expires: January 6, 2006                           University of Glasgow
                                                            July 5, 2005


                        TFRC Testing Strategies
                 draft-saurin-tsvwg-tfrc-testing-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 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes a possible testing strategy for TFRC
   implementations.









Saurin & Perkins         Expires January 6, 2006                [Page 1]

Internet-Draft                tfrc-testing                     July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Glossary of Terms  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Testing Overview . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1   Components Layout  . . . . . . . . . . . . . . . . . . . .  3
     3.2   Parts Tested . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Data Transport . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1   System Initialization  . . . . . . . . . . . . . . . . . .  4
     4.2   Basic Behavior . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Sender Behavior  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1   RTT Measurement  . . . . . . . . . . . . . . . . . . . . .  6
     5.2   Errors with Feedback Reports . . . . . . . . . . . . . . .  7
     5.3   TFRC Sending Rate  . . . . . . . . . . . . . . . . . . . .  8
     5.4   Inter-Packet Interval Calculation  . . . . . . . . . . . . 10
     5.5   Slow-Start Algorithm . . . . . . . . . . . . . . . . . . . 10
     5.6   Oscillation Prevention . . . . . . . . . . . . . . . . . . 10
   6.  Receiver Behavior  . . . . . . . . . . . . . . . . . . . . . . 11
     6.1   Feedback Mechanism . . . . . . . . . . . . . . . . . . . . 11
     6.2   Loss Event Rate Estimation . . . . . . . . . . . . . . . . 12
   7.  Open Issues and Future Work  . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
   11.   Normative References . . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16
























Saurin & Perkins         Expires January 6, 2006                [Page 2]

Internet-Draft                tfrc-testing                     July 2005


1.  Introduction

   TFRC is "a congestion control mechanism designed for unicast flows
   operating in an Internet environment and competing with TCP traffic"
   [2].  This memo describes a possible testing strategy for TFRC
   implementations.  These tests are intended to help demonstrate
   correctness of implementations, and to illustrate common problems.
   However, they are not intended to be an exhaustive set of tests, and
   passing these tests does not necessarily imply conformance to the
   complete TFRC specification.

2.  Glossary of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1]

3.  Testing Overview

3.1  Components Layout

   The architecture for testing TFRC requires three major components:
   two end systems, performing as communicating elements, and an
   interface system, acting as communication medium and testing
   instrument.


                                +------------------+
                       +--------+ Interface System +-----+
                       |        +------------------+     |
                       |                                 |
               +-------+--------+                +-------+--------+
               |   First TFRC   |                |   Second TFRC  |
               | implementation |                | implementation |
               |    (Sender)    |                |   (Receiver)   |
               +----------------+                +----------------+


   The interface system must be capable of sending arbitrarily packets
   to both TFRC implementations, and of receiving packets sent by the
   sender implementation, parsing them, computing metrics based on those
   packets, and transmitting them to the receiver.  This system should
   also be able to discard or reorder selected packets, or to introduce
   some delay in the transmission process.

   The testing framework is independant of the internal details of the
   TFRC implementation.  Most of the tests have a zero knowledge of the
   system used, considering it as a black box and observing only the



Saurin & Perkins         Expires January 6, 2006                [Page 3]

Internet-Draft                tfrc-testing                     July 2005


   interchanged information.

   However, some other tests have been proposed as optional, just in
   case there is enough information of the inner organization of the
   system.

3.2  Parts Tested

   For the testing of TFRC we must stress the following main parts of
   the protocol:

   o  The basic interchage of information and interoperatibility
      (Section 4).

   o  The RTT estimation (Section 5.1).

   o  The TFRC sending rate calculation and inter-packet spacing
      (Section 5.3 and Section 5.4).

   o  The feedback mechanism (Section 5.2 and Section 6.1).

   o  The loss detection, loss history and associated loss rate
      estimation (Section 6.2).

   The following sections describe a series of tests for these parts of
   the TFRC protocol.

4.  Data Transport

   The intention of these tests is to show that basic communication can
   be performed between the two TFRC implementations.  In order to
   verify this, the system initialization must be tested as well as the
   basic operation of the system.

4.1  System Initialization

   In these tests, tested the correct initialization of both end points
   will be tested, in particular the initial values for the fundamental
   parameters.

   The sender initialization is tested first.  There few specific tests
   for the sender, as the estimated RTT, R_i, and the RTO, t_RTO, have
   unspecified initial state.  The sender initialization tests are
   limited to verifying that, for the first data packet sent, the
   sequence number is 0 (or an initial value chosen).

   The test continues with the receiver initialization.  The receiver is
   initialized when the first packet from the sender arrives.  When the



Saurin & Perkins         Expires January 6, 2006                [Page 4]

Internet-Draft                tfrc-testing                     July 2005


   receiver receives an initial data packet at t_1, with sequence number
   0, i=0, and associated timestamp, ts_0=0, and RTT, R_0=0, some checks
   must be performed:

   1.  Verify that the receiver sends a feedback report at t_2, t_2 =
       t_1 + t_delay.

   2.  Verify that the value reported for t_delay matches the time
       elapsed between t_1 and t_2.

   3.  Verify that the value reported for X_recv is equal to the packet
       size.

   4.  Verify that the value reported for t_recvdata is 0.

   5.  Verify that the value reported for p is 0.

   6.  Verify that the sender receives this feedback report.

   These tests demonstrate that the receiver correctly processes the
   first data packet, and is initialized with appropriate state.

4.2  Basic Behavior

   The purpose of these tests is to verify the basic correctness of the
   implementation of the TFRC transmission rules.  These requirements
   can be verified at any point in a session.

   The sender application must be able to handle the following cases

   o  Verify that the sequence number is incremented by one for each
      data packet sent.

   o  Verify that the timestamp is incremented for each data packet
      sent.

   o  Verify correct operation during sequence number wrap-around.

   o  Verify correct operation during timestamp wrap-around.

   The receiver should also be verified to correctly handle the
   following edge cases:

   o  Verify correct operation during sequence number wrap-around.

   o  Verify correct operation during timestamp wrap-around.





Saurin & Perkins         Expires January 6, 2006                [Page 5]

Internet-Draft                tfrc-testing                     July 2005


5.  Sender Behavior

   In this section, in addition to the basic communicacion requirements
   of Section 4, other features of the sender behavior must be verified.
   In particular, the RTT measurement, the feedback mechanism and the
   sending rate.

5.1  RTT Measurement

   It should be verified that the initial conditions regarding the RTT
   are correctly initialized in both systems.  This process is described
   in Section 4.3 of [2].  As the RTT known by the receiver is provided
   by the sender, a correct measure by the sender is decisive.

   For the first test, we will tests how the receiver measures the RTT
   using the RTT sample provided in every feedback report.  In order to
   do this, we will use a t_delay of 0 ms in the receiver, and the
   interface system will initially simulate a fixed 10ms delay between
   both systems that will not change depending on the queue length.

   The sender will initialize the system sending an initial data packet
   at t_0.

   1.  Verify that the first RTT reported by the sender is 0 (or null).

   2.  Verify that the first t_delay reported by the receiver is 0.

   3.  Verify that the first not-null RTT reported by the sender is
       equal to the RTT sample, 0.020.

   If this test succeeded, the process should be repeated for some time,
   keeping the network delay and send rate constant.

   1.  Verify that the RTT reported by the sender, R_i, is constant, R_i
       = 0.020, provided that the network delay is constant.

   If this test succeeds, the interface system will change the simulated
   delay to 20ms after the reception of a feedback report, at t_2.  Next
   feedback report, received at t_3, t_3 = t_2 + 0.020, will provide a
   new R_sample.

   Next data packet, sent at t_4, t_4 > t_3, and with sequence number j,
   will include a different RTT measure:

   1.  Verify that the value reported for RTT in the data packet with
       sequence number j is 22ms.

   For subsequent data packet sent after a feedback report is received,



Saurin & Perkins         Expires January 6, 2006                [Page 6]

Internet-Draft                tfrc-testing                     July 2005


   the RTT measure included must follow a known sequence:

   1.  Verify that the RTT included in the data packets evolves
       following the sequence 23.8ms, 25.42ms, 26.87ms, 28.19ms,
       29.37ms, 30.43ms, 31.39ms, 32.25ms, 33.02ms...

   2.  Verify that, for every successive data packet sent after a
       feedback report, the RTT included, R_i, is equal to the new RTT
       estimation, R = 0,9*R + 0.1*(t_now - t_recvdata).


5.2  Errors with Feedback Reports

   The sender behavior should be verified for the absence of feedback
   reports.  In order to verify this, the sender will be initialized,
   but the receiver will not send any feedback report.  The sender has
   no knowledge of the RTT, so it must wait up to 2 seconds for a
   feedback report.

   o  Verify that the sender sends one packet per second for two
      seconds.

   o  Verify that the sender halves its sending rate every two seconds.

   o  Verify that the sender reaches a minimum sending rate of one
      packet every 64 seconds.


    TIME: 0.000000 SEQ: 0
    TIME: 1.000000 SEQ: 1
    TIME: 2.000000 SEQ: 2
    TIME: 4.000000 SEQ: 3
    TIME: 6.000000 SEQ: 4
    TIME: 10.000000 SEQ: 5
    TIME: 14.000000 SEQ: 6
    TIME: 22.000000 SEQ: 7
    TIME: 30.000000 SEQ: 8
    TIME: 46.000000 SEQ: 9
    TIME: 62.000000 SEQ: 10
    TIME: 94.000000 SEQ: 11
    TIME: 126.000000 SEQ: 12
    TIME: 190.000000 SEQ: 13
    TIME: 254.000000 SEQ: 14

   The behavior of the sender must change if no feedback information is
   received for some time, given by the current RTO.

   In order to verify this, the sender must begin sending packets and



Saurin & Perkins         Expires January 6, 2006                [Page 7]

Internet-Draft                tfrc-testing                     July 2005


   the sender must respond with ACK packets, continuing with the normal
   operation until t=500ms, when all feedback reports must be suspended
   again.

   At this moment, we must take into account the last RTT, r, and
   sending rate, x, known by the sender when the last feedback report
   was received at the moment t.

   o  Verify that, if the sender does not receive a feedback report in
      four RTT, at t+4r, it halves its sending rate, X=x/2.

   This situation must be kept for some time, discarding all feedback
   reports, verifying that the sender spaces packets accordingly.

   o  Verify that the sender halves the sender rate every 4*r seconds .

   o  Verify that the inter-packet interval is decreased until it
      reaches a minimum value of one packet every 64 seconds (as
      specified in Section 4.3 of [2])


5.3  TFRC Sending Rate

   A TFRC implementation should be conformant to the throughput formula.
   For t_RTO = 4*R and b = 1, the throughput equation is:
   X= S/R*f(p)
   f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2))

   This formula depends on three parameters: the packet size (s), the
   loss event rate (p) and the RTT (R).  Setting all three parameters to
   known values for a period of time should produce a known sending rate
   for the same period.

   Alternatively, if we set two parameters with known values but we
   change the last one, we should be able to observe a conforming
   variation in the sending rate of the sending system.

   To ensure this, some tests must be performed:

   o  Fixing the packet size to S, the loss event rate to P and the RTT
      to R for a time T, verify that the calculated sending rate X
      corresponds to these values.









Saurin & Perkins         Expires January 6, 2006                [Page 8]

Internet-Draft                tfrc-testing                     July 2005


          Varying p:
          s=1500 p=0.006 R=0.010   -> X=2.25006*10^6
          s=1500 p=0.026 R=0.010   -> X=919512
          s=1500 p=0.100 R=0.010   -> X=265515

          Varying S:
          s=1500 p=0.010 R=0.010   -> X=1.68498*10^6
          s=4800 p=0.006 R=0.010   -> X=7.20021*10^6
          s=9000 p=0.006 R=0.010   -> X=1.35004*10^7

          Varying RTT:
          s=1500 p=0.006 R=0.001   -> X=2.25006*10^7
          s=1500 p=0.006 R=0.200   -> X=112503
          s=1500 p=0.006 R=0.400   -> X=56251.6

   o  Fixing the packet size to S and the loss event rate to P for a
      time T, verify that a change of R in the RTT produces a change of
      X in the sending rate.

   o  Fixing the packet size to S and the RTT to R for a time T, verify
      that a change of P in the loss event rate produces a change of X
      in the sending rate.

   We don't take into account a variation in the packet size, as it
   should be constant.

   It must also be verified that the real sending rate matches the
   amount of data sent in a RTT, R. This can be tested in the following
   manner.  The interface system must measure the amount of data
   interchanged between two feedback reports, received at times t_1 and
   t_2, provided that the receiver is sending one report per RTT, t_2 -
   t_1=R.

   Taking into account the first data packet sent after t_1, at t_d, t_1
   < t_d < t_2, and the sending rate, X_d, and RTT, R_d, included:

   o  Verify that the amount of data send between t_d and t_2 matches
      the sending rate for that period, X_d*R_d.

   In addition, some tests should be performed to verify that the sender
   conforms to the data reported by the receiver.  Some checks could be:

   o  Verify that the sending rate is always less than twice the X_recv
      reported by the receiver.







Saurin & Perkins         Expires January 6, 2006                [Page 9]

Internet-Draft                tfrc-testing                     July 2005


5.4  Inter-Packet Interval Calculation

   It must be verified that the inter-packet interval matches the
   current sending rate reported by the sender (see Section 4.6 of [2]).

   In order to tests this, the sender must send packets to the receiver,
   and the interface system must log the times when these packets are
   sent.  The packet size, S, is known, as it is the sending rate, X.

   o  Verify that the average space between packets in one RTT is S/X.


5.5  Slow-Start Algorithm

   To perform this test, the system must be intialized.  The sender will
   send packets and the reciever will answer with the corresponding
   feedback reports.  The interface system must measure the amount of
   data sent between consecutive reports.

   o  Verify that the sender doubles the sending rate once per RTT (see
      Section 4.3 of [2]).

   o  Verify that the receiver reports a null value for the loss event
      rate, p=0.

   This situation can be sustained for some time, until t_1, where the
   last sending rate of the sender is X_1.  After that, the receiver
   must report a loss event rate greater than 0, p_1 > 0, in order to
   test that the sender finishes the slow start phase.

   o  Verify that the first data packet sent after t_1, at t_2, includes
      a sending rate, X_2, with X_2 < X_1.


5.6  Oscillation Prevention

   This is an OPTIONAL feature (specified in Section 4.5 of [2]).

   To prevent oscillations in the sending rate, the sender keeps an
   estimate of the long-term RTT and sets its sending rate depending on
   how much the last RTT differs from this mean value.

   For this testing scenario, the sender must be initialized and the
   receiver must send feedback reports on a regular basis.  The RTT must
   be kept fixed at 20ms for at least two RTT (producing a internal
   value of 0.141421 for R_sqmean).

   This must must be kept for some time until a feedback reports arrives



Saurin & Perkins         Expires January 6, 2006               [Page 10]

Internet-Draft                tfrc-testing                     July 2005


   at t_1.  After this, the RTT must be halved, RTT = 10ms, and a new
   feedback report will arrive at t_2, providing an updated RTT sample.

   If the sending rate at t_1 was X_1, and the sending rate reported in
   the first data packet sent after t_2 is X_2:

   1.  If the internal value of R_sqmean is known, verify that R_sqmean
       is updated and its value is 0.137279.

   2.  Verify that the sending rate X_2 is X_1 * R_sqmean/sqrt(R_sample)
       = X_1 * 1.37279.

   This test must be performed again, but this time the RTT must be
   doubled after t_1, setting RTT=40ms.

   1.  If the internal value of R_sqmean is know, verify that R_sqmean
       is updated and its value is 0.147279.

   2.  Verify that the sending rate X_2 is X_1 * R_sqmean/sqrt(R_sample)
       = X_1 * 0.736396.

   These tests demonstrate that the receiver correctly calculates
   R_sqmean based on an expentially weighted moving average of the
   observed RTT values.

6.  Receiver Behavior

   In this section, some advanced characteristics of the receiver will
   be verified.  In particular, the feedback mechanism and some aspects
   of the loss event rate calculation.

6.1  Feedback Mechanism

   The receiver is expected to send a feedback report once per RTT.  The
   following tests verify the accuracy of the information provided in a
   feedback report.

   The sender begins transmission, with the delay through the interface
   system kept constant for at least two RTTs.  It must be known the
   RTT, R_1, when last feedback report arrived at the sender, at t_1.
   The interface system must then record all packets, since t_1 to t_2,
   t_2 - t_1 = R_1.

   1.  Verify that a feedback report is sent at t2.

   2.  Verify that the reported timestamp of last packet received,
       t_recvdata, matches the timestamp, t_last, of the last packet
       received, t_last < t_2.



Saurin & Perkins         Expires January 6, 2006               [Page 11]

Internet-Draft                tfrc-testing                     July 2005


   The sending rate reported in the absence of losses must match the
   sending rate of the sender.  Calculating the amount of data, d, sent
   in the interval between t_1 and t_2:

   o  Verify that the reported sending rate as seen by the receiver,
      X_recv, matches the sending rate of the sender, X, in the previous
      RTT.

   o  Verify that the sending rate as seen by the receiver, X_recv,
      matches the amount of data received since t_1, X_recv = d/RTT.

   Feedback reports must be sent only when some data has been received
   since the last one was sent.  In order to test this, all data packets
   must be discarded after a feedback report arrrives at the sender, at
   t_1.  If the last RTT known by the receiver was R_1, then a new
   feedback report would be expected at t_2 = t_1 + R_1.

   o  Verify that there is no feedback report sent at t_2

   o  Verify that there is no feedback report sent while there are no
      data packets.


6.2  Loss Event Rate Estimation

   In the next test it will be tested some aspect of Section 5.1 of [2].

   The receiver is required to keep a history of packets that have been
   successfully transmited in order to detect a lost packet.  Using this
   facility, the loss detection system must register in a loss history
   any lost packet, and any change in this history will modify the
   current loss event rate reported.

   In these tests, the first implementation is made to transmit data
   packets, which are then received by the second implementation.  The
   test instrument must discard some packets sent by the sender in order
   to simulate losses.  An increment in the reported loss event rate
   will indicate that the loss has been detected.  In the first test, a
   packet with sequence number i is discarded:

   o  Verify that, after the receiver system receives three packets with
      sequence numbers i+1, i+2 and i+3, this is detected as a loss.

   o  Verify that the receiver sends a feedback report immediately after
      it detects the loss.

   o  Verify that the p reported has been increased.




Saurin & Perkins         Expires January 6, 2006               [Page 12]

Internet-Draft                tfrc-testing                     July 2005


   If this tests succeded, the process should be repeated but with some
   packet reordering.  In this case, no packet will be discarded, but
   some packets must be delayed by the test instrument, altering their
   natural sequence:

   o  Verify that, after the receiver system receives three packets with
      sequence numbers i+2, i and i+1, this is not detected as a loss.

   o  Verify that, after the receiver system receives four packets with
      sequence numbers i+3, i+2, i+1 and i, the last packet is detected
      as a lost packet.

   o  Verify that the receiver sends a feedback report immediately after
      it detects the loss.

   o  Verify that the p reported has been increased.

   In the next test it will be tested some aspect of loss computation
   (Section 5.2 of [2]).

   Like in the previous test, the testing instrument should discard some
   packets and verify the behavior of the receiver under such
   circumstances.  However, it must be taken into account the state of
   the sender before the loss is produced.  In particular, the RTT and p
   must be known.

   In this test, the interface system discards two packets in the same
   RTT, with sequence numbers i and i+1.

   o  Verify that the receiver sends a feedback report after the packet
      with sequence number i+4 has been received.

   o  Verify that there is an increment in the value of p reported by
      the receiver.

   o  Verify that, discarding two packets in a RTT, it has the same
      effect as a single loss on the loss measurement.

   The test must be repeated with the same initial conditions.  However,
   only one packet will be discarded this time:

   o  Verify that a feedback report is sent by the receiver when the
      loss is detected.

   o  Verify that the increment in the value of p is the same as in the
      previous measurement.





Saurin & Perkins         Expires January 6, 2006               [Page 13]

Internet-Draft                tfrc-testing                     July 2005


7.  Open Issues and Future Work

   This draft could be conceived as a basic framework for testing TFRC.
   Future drafts should include more advanced testing of its features,
   as well as some scenarios where it would be tested the behavior of
   long term connections.

   For example, testing of the loss history is a difficult issue, and it
   would require some sort of scenario where patterns of losses could
   show how the loss event rate evolves.  In the same way, more advanced
   features, like history discounting, would need long scenarios where
   the complete execution of the system could be tested.

8.  Security Considerations

   Security considerations relating to the TFRC protocol are discussed
   in RFC 3448 [2].  The testing strategies outlined in this memo
   introduce no additional security considerations.

9.  IANA Considerations

   No IANA actions are required.

10.  Acknowledgements

   This work is supported by the National Science Foundation under grant
   No. 0230738.  Thanks to Ladan Gharai for feedback on an early version
   of this memo.

11.  Normative References

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

   [2]  Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
        Rate Control (TFRC): Protocol Specification", RFC 3448,
        January 2003.














Saurin & Perkins         Expires January 6, 2006               [Page 14]

Internet-Draft                tfrc-testing                     July 2005


Authors' Addresses

   Alvaro Saurin
   University of Glasgow
   Department of Computing Science
   17 Lilybank Gardens
   Glasgow  G12 8QQ
   UK

   Email: saurin@dcs.gla.ac.uk


   Colin Perkins
   University of Glasgow
   Department of Computing Science
   17 Lilybank Gardens
   Glasgow  G12 8QQ
   UK

   Email: csp@csperkins.org































Saurin & Perkins         Expires January 6, 2006               [Page 15]

Internet-Draft                tfrc-testing                     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.




Saurin & Perkins         Expires January 6, 2006               [Page 16]