doc: Add RFC documents

1 files changed, 674 insertions, 0 deletions

diff --git a/doc/rfc/rfc2354.txt b/doc/rfc/rfc2354.txt
new file mode 100644
index 0000000..4aaa7c7
--- /dev/null
+++ b/doc/rfc/rfc2354.txt
@@ -0,0 +1,674 @@
+
+
+
+
+
+
+Network Working Group                                         C. Perkins
+Request for Comments: 2354                                     O. Hodson
+Category: Informational                        University College London
+                                                               June 1998
+
+
+                 Options for Repair of Streaming Media
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This document summarizes a range of possible techniques for the
+   repair of continuous media streams subject to packet loss.  The
+   techniques discussed include redundant transmission, retransmission,
+   interleaving and forward error correction.  The range of
+   applicability of these techniques is noted, together with the
+   protocol requirements and dependencies.
+
+1  Introduction
+
+   A number of applications have emerged which use RTP/UDP transport to
+   deliver continuous media streams.  Due to the unreliable nature of
+   UDP packet delivery, the quality of the received stream will be
+   adversely affected by packet loss.  A number of techniques exist by
+   which the effects of packet loss may be repaired.  These techniques
+   have a wide range of applicability and require varying degrees of
+   protocol support.  In this document, a number of such techniques are
+   discussed, and recommendations for their applicability made.
+
+   It should be noted that this document is introductory in nature, and
+   does not attempt to be comprehensive.  In particular, we restrict our
+   discussion to repair techniques which require the involvement of the
+   sender of a media stream, and do not discuss possibilities for
+   receiver based repair.
+
+   For a more detailed survey, the reader is referred to [5].
+
+
+
+
+
+
+Perkins & Hodson             Informational                      [Page 1]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+2  Terminology and Protocol Framework
+
+   A unit is defined to be a timed interval of media data, typically
+   derived from the workings of the media coder.  A packet comprises one
+   or more units, encapsulated for transmission over the network.  For
+   example, many audio coders operate on 20ms units, which are typically
+   combined to produce 40ms or 80ms packets for transmission.  The
+   framework of RTP [18] is assumed.  This implies that packets have a
+   sequence number and timestamp.  The sequence number denotes the order
+   in which packets are transmitted, and is used to detect losses.  The
+   timestamp is used to determine the playout order of units.  Most loss
+   recovery schemes rely on units being sent out of order, so an
+   application must use the RTP timestamp to schedule playout.
+
+   The use of RTP allows for several different media coders, with a
+   payload type field being used to distinguish between these at the
+   receiver.  Some loss repair schemes send multiple copies of units, at
+   different times and possibly with different encodings, to increase
+   the probability that a receiver has something to decode.  A receiver
+   is assumed to have a `quality' ranking of the differing encodings,
+   and so is capable of choosing the `best' unit for playout, given
+   multiple options.
+
+   A session is defined as interactive if the end-to-end delay is less
+   then 250ms, including media coding and decoding, network transit and
+   host buffering.
+
+3  Network Loss Characteristics
+
+   If it is desired to repair a media stream subject to packet loss, it
+   is useful to have some knowledge of the loss characteristics which
+   are likely to be encountered.  A number of studies have been
+   conducted on the loss characteristics of the Mbone [2, 8, 21] and
+   although the results vary somewhat, the broad conclusion is clear:
+   in a large conference it is inevitable that some receivers will
+   experience packet loss.  Packet traces taken by Handley [8] show a
+   session in which most receivers experience loss in the range 2-5%,
+   with a somewhat smaller number seeing significantly higher loss
+   rates.  Other studies have presented broadly similar results.
+
+   It has also been shown that the vast majority of losses are of single
+   packets.  Burst losses of two or more packets are around an order of
+   magnitude less frequent than single packet loss, although they do
+   occur more often than would be expected from a purely random process.
+   Longer burst losses (of the order of tens of packets) occur
+   infrequently.  These results are consistent with a network where
+   small amounts of transient congestion cause the majority of packet
+   loss.  In a few cases, a network link is found to be severely
+
+
+
+Perkins & Hodson             Informational                      [Page 2]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   overloaded, and large amount of loss results.
+
+   The primary focus of a repair scheme must, therefore, be to correct
+   single packet loss, since this is by far the most frequent
+   occurrence.  It is desirable that losses of a relatively small number
+   of consecutive packets may also be repaired, since such losses
+   represent a small but noticeable fraction of observed losses.  The
+   correction of large bursts of loss is of considerably less
+   importance.
+
+4  Loss Mitigation Schemes
+
+   In the following sections, four loss mitigation schemes are
+   discussed.  These schemes have been discussed in the literature a
+   number of times, and found to be of use in a number of scenarios.
+   Each technique is briefly described, and its advantages and
+   disadvantages noted.
+
+4.1 Retransmission
+
+   Retransmission of lost packets is an obvious means by which loss may
+   be repaired.  It is clearly of value in non-interactive applications,
+   with relaxed delay bounds, but the delay imposed means that it does
+   not typically perform well for interactive use.
+
+   In addition to the possibly high latency, there is a potentially
+   large bandwidth overhead to the use of retransmission.  Not only are
+   units of data sent multiple times, but additional control traffic
+   must flow to request the retransmission.  It has been shown that, in
+   a large Mbone session, most packets are lost by at least one receiver
+   [8].  In this case the overhead of requesting retransmission for most
+   packets may be such that the use of forward error correction is more
+   acceptable.  This leads to a natural synergy between the two
+   mechanisms, with a forward error correction scheme being used to
+   repair all single packet losses, and those receivers experiencing
+   burst losses, and willing to accept the additional latency, using
+   retransmission based repair as an additional recovery mechanism.
+   Similar mechanisms have been used in a number of reliable multicast
+   schemes, and have received some discussion in the literature [9, 13].
+
+   In order to reduce the overhead of retransmission, the retransmitted
+   units may be piggy-backed onto the ongoing transmission, using a
+   payload format such as that described in [15].  This also allows for
+   the retransmission to be recoded in a different format, to further
+   reduce the bandwidth overhead.  As an alternative, FEC information
+   may be sent in response to retransmission requests [13], allowing a
+   single retransmission to potentially repair several losses.  The
+   choice of a retransmission request algorithm which is both timely and
+
+
+
+Perkins & Hodson             Informational                      [Page 3]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   network friendly is an area of current study.  An obvious starting
+   point is the SRM protocol [7], and experiments have been conducted
+   using this, and with a low-delay variant, STORM [20].  This work
+   shows the trade-off between latency and quality for retransmission
+   based repair schemes, and illustrates that retransmission is an
+   effective approach to repair for applications which can tolerate the
+   latency.
+
+   There is no standard protocol framework for requesting retransmission
+   of streaming media.  An experimental RTP profile extension for SRM-
+   style retransmission requests has described in [14].
+
+4.2 Forward Error Correction
+
+   Forward error correction (FEC) is the means by which repair data is
+   added to a media stream, such that packet loss can be repaired by the
+   receiver of that stream with no further reference to the sender.
+   There are two classes of repair data which may be added to a stream:
+   those which are independent of the contents of the stream, and those
+   which use knowledge of the stream to improve the repair process.
+
+4.2.1 Media-Independent FEC
+
+   A number of media-independent FEC schemes have been proposed for use
+   with streamed media.  These techniques add redundant data, which is
+   transmitted in separate packets, to a media stream.  Traditionally,
+   FEC techniques are described as loss detecting and/or loss
+   correcting.  In the case of streamed media, loss detection is
+   provided by the sequence numbers in RTP packets.
+
+   The redundant FEC data is typically calculated using the mathematics
+   of finite fields [1].  The simplest of finite field is GF(2) where
+   addition is just the eXclusive-OR operation.  Basic FEC schemes
+   transmit k data packets with n-k parity packets allowing the
+   reconstruction of the original data from any k of the n transmitted
+   packets.  Budge et al [4] proposed applying the XOR operation across
+   different combinations of the media data with the redundant data
+   transmitted separately as parity packets.  These vary the pattern of
+   packets over which the parity is calculated, and hence have different
+   bandwidth, latency and loss repair characteristics.
+
+   Parity-based FEC based techniques have a significant advantage in
+   that they are media independent, and provide exact repair for lost
+   packets.  In addition, the processing requirements are relatively
+   light, especially when compared with some media-specific FEC
+   (redundancy) schemes which use very low bandwidth, but high
+   complexity encodings.  The disadvantage of parity based FEC is that
+   the codings have higher latency in comparison with the media-specific
+
+
+
+Perkins & Hodson             Informational                      [Page 4]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   schemes discussed in following section.
+
+   A number of FEC schemes exist which are based on higher-order finite
+   fields, for example Reed-Solomon (RS) codes, which are more
+   sophisticated and computationally demanding.  These are usually
+   structured so that they have good burst loss protection, although
+   this typically comes at the expense of increased latency.  Dependent
+   on the observed loss patterns, such codes may give improved
+   performance, compared to parity-based FEC.
+
+   An RTP payload format for generic FEC, suitable for both parity based
+   and Reed-Solomon encoded FEC is defined in [17].
+
+4.2.2 Media-Specific FEC
+
+   The basis of media-specific FEC is to employ knowledge of a media
+   compression scheme to achieve more efficient repair of a stream than
+   can otherwise be achieved.  To repair a stream subject to packet
+   loss, it is necessary to add redundancy to that stream:  some
+   information is added which is not required in the absence of packet
+   loss, but which can be used to recover from that loss.
+
+   The nature of a media stream affects the means by which the
+   redundancy is added.  If units of media data are packets, or if
+   multiple units are included in a packet, it is logical to use the
+   unit as the level of redundancy, and to send duplicate units.  By
+   recoding the redundant copy of a unit, significant bandwidth savings
+   may be made, at the expense of additional computational complexity
+   and approximate repair.  This approach has been advocated for use
+   with streaming audio [2, 10] and has been shown to perform well.  An
+   RTP payload format for this form of redundancy has been defined [15].
+
+   If media units span multiple packets, for instance video, it is
+   sensible to include redundancy directly within the output of a codec.
+   For example the proposed RTP payload for H.263+ [3] includes multiple
+   copies of key portions of the stream, separated to avoid the problems
+   of packet loss.  The advantages of this second approach is
+   efficiency: the codec designer knows exactly which portions of the
+   stream are most important to protect, and low complexity since each
+   unit is coded once only.
+
+   An alternative approach is to apply media-independent FEC techniques
+   to the most significant bits of a codecs output, rather than applying
+   it over the entire packet.  Several codec descriptions include bit
+   sensitivities that make this feasible.  This approach has low
+   computational cost and can be tailored to represent an arbitrary
+   fraction of the transmitted data.
+
+
+
+
+Perkins & Hodson             Informational                      [Page 5]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   The use of media-specific FEC has the advantage of low-latency, with
+   only a single-packet delay being added.  This makes it suitable for
+   interactive applications, where large end-to-end delays cannot be
+   tolerated.  In a uni-directional non-interactive environment it is
+   possible to delay sending the redundant data, achieving improved
+   performance in the presence of burst losses [11], at the expense of
+   additional latency.
+
+4.3 Interleaving
+
+   When the unit size is smaller than the packet size, and end-to-end
+   delay is unimportant, interleaving [16] is a useful technique for
+   reducing the effects of loss.  Units are resequenced before
+   transmission, so that originally adjacent units are separated by a
+   guaranteed distance in the transmitted stream, and returned to their
+   original order at the receiver.  Interleaving disperses the effect of
+   packet losses.  If, for example, units are 5ms in length and packets
+   20ms (ie:  4 units per packet), then the first packet could contain
+   units 1, 5, 9, 13; the second packet would contain units 2, 6, 10,
+   14; and so on.  It can be seen that the loss of a single packet from
+   an interleaved stream results in multiple small gaps in the
+   reconstructed stream, as opposed to the single large gap which would
+   occur in a non-interleaved stream.  In many cases it is easier to
+   reconstruct a stream with such loss patterns, although this is
+   clearly media and codec dependent.  Note that the size of the gaps is
+   dependent on the degree of interleaving used, and can be made
+   arbitrarily small at the expense of additional latency.
+
+   The obvious disadvantage of interleaving is that it increases
+   latency.  This limits the use of this technique for interactive
+   applications, although it performs well for non-interactive use.  The
+   major advantage of interleaving is that it does not increase the
+   bandwidth requirements of a stream.
+
+   A potential RTP payload format for interleaved data is a simple
+   extension of the redundant audio payload [15].  That payload requires
+   that the redundant copy of a unit is sent after the primary.  If this
+   restriction is removed, it is possible to transmit an arbitrary
+   interleaving of units with this payload format.
+
+5  Recommendations
+
+   If the desired scenario is a non-interactive uni-directional
+   transmission, in the style of a radio or television broadcast,
+   latency is of considerably less importance than reception quality.
+   In this case, the use of interleaving, retransmission based repair or
+   FEC is appropriate.  If approximate repair is acceptable,
+   interleaving is clearly to be preferred, since it does not increase
+
+
+
+Perkins & Hodson             Informational                      [Page 6]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   the bandwidth of a stream.  Media independent FEC is typically the
+   next best option, since a single FEC packet has the potential to
+   repair multiple lost packets, providing efficient transmission.
+
+   In an interactive session, the delay imposed by the use of
+   interleaving and retransmission is not acceptable, and a low-latency
+   FEC scheme is the only means of repair suitable.  The choice between
+   media independent and media specific forward error correction is less
+   clear-cut:  media-specific FEC can be made more efficient, but
+   requires modification to the output of the codec.  When defining the
+   packet format for a new codec, this is clearly an appropriate
+   technique, and should be encouraged.
+
+   If an existing codec is to be used, a media independent forward error
+   correction scheme is usually easier to implement, and can perform
+   well.  A media stream protected in this way may be augmented with
+   retransmission based repair with minimal overhead, providing improved
+   quality for those receivers willing to tolerate additional delay, and
+   allowing interactivity for those receivers which desire it.  Whilst
+   the addition of FEC data to an media stream is an effective means by
+   which that stream may be protected against packet loss, application
+   designers should be aware that the addition of large amounts of
+   repair data when loss is detected will increase network congestion,
+   and hence packet loss, leading to a worsening of the problem which
+   the use of error correction coding was intended to solve.
+
+   At the time of writing, there is no standard solution to the problem
+   of congestion control for streamed media which can be used to solve
+   this problem.  There have, however, been a number of contributions
+   which show the likely form the solution will take [12, 19].  This
+   work typically used some form of layered encoding of data over
+   multiple channels, with receivers joining and leaving layers in
+   response to packet-loss (which indicates congestion).  The aim of
+   such schemes is to emulate the congestion control behavior of a TCP
+   stream, and hence compete fairly with non-real time traffic.  This is
+   necessary for stable network behavior in the presence of much
+   streamed media.
+
+   Since streaming media applications are in use now, without congestion
+   control, it is important to give some advice to authors of those
+   tools as to the behavior which is acceptable, until congestion
+   control mechanisms can be deployed.  The remainder of this section
+   uses the throughput of a TCP connection over a link with a given loss
+   rate as an example to indicate behavior which may be classified as
+   reasonable.
+
+   As a number of authors have noted (eg:  [6]), the loss rate and
+   throughput of a TCP connection are approximately related as follows:
+
+
+
+Perkins & Hodson             Informational                      [Page 7]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+    T = (s * c) / (RTT * sqrt(p))
+
+   where T is the observed throughput in octets per second, s is the
+   packet size in octets, RTT is the round-trip time for the session in
+   seconds, p is the packet loss rate and c is a constant in the range
+   0.9...1.5 (a value of 1.22 has been suggested [6]).  Using this
+   relation, one may determine the packet loss rate which would result
+   in a given throughput for a particular session, if a TCP connection
+   was used.
+
+   Whilst this relation between packet loss rate and throughput is
+   specific to the TCP congestion control algorithm, it also provides an
+   estimate of the acceptable loss rate for a streaming media
+   application using the same network path, which wishes to coexist
+   fairly with TCP traffic.  Clearly this is not sufficient for fair
+   sharing of a link with TCP traffic, since it does not capture the
+   dynamic behavior of the connection, merely the average behavior, but
+   it does provide one definition of "reasonable" behavior in the
+   absence of real congestion control.
+
+   For example, an RTP audio session with DVI encoding and 40ms data
+   packets will have 40 bytes RTP/UDP/IP header, 4 bytes codec state and
+   160 bytes of media data, giving a packet size, s, of 204 bytes.  It
+   will send 25 packets per second, giving T = 4800.  It is possible to
+   estimate the round-trip time from RTCP reception report statistics
+   (say 200 milliseconds for the purpose of example).  Substituting
+   these values into the above equation, we estimate a "reasonable"
+   packet loss rate, p, of 6.7%.  This would represent an upper bound on
+   the packet loss rate which this application should be designed to
+   tolerate.
+
+   It should be noted that a round trip time estimate based on RTCP
+   reception report statistics is, at best, approximate; and that a
+   round trip time for a multicast group can only be an `average'
+   measure.  This implies that the TCP equivalent throughput/loss rate
+   determined by this relation will be an approximation of the upper
+   bound to the rate a TCP connection would actually achieve.
+
+6  Security Considerations
+
+   Some of the repair techniques discussed in this document result in
+   the transmission of additional traffic to correct for the effects of
+   packet loss.  Application designers should be aware that the
+   transmission of large amounts of repair traffic will increase network
+   congestion, and hence packet loss, leading to a worsening of the
+   problem which the use of error correction was intended to solve.  At
+   its worst, this can lead to excessive network congestion and may
+   constitute a denial of service attack.  Section 5 discusses this in
+
+
+
+Perkins & Hodson             Informational                      [Page 8]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   more detail, and provides guidelines for prevention of this problem.
+
+7  Summary
+
+   Streaming media applications using the Internet will be subject to
+   packet loss due to the unreliable nature of UDP packet delivery.
+   This document has summarized the typical loss patterns seen on the
+   public Mbone at the time of writing, and a range of techniques for
+   recovery from such losses.  We have further discussed the need for
+   congestion control, and provided some guidelines as to reasonable
+   behavior for streaming applications in the interim until congestion
+   control can be deployed.
+
+8  Acknowledgments
+
+   The authors wish to thank Phil Karn and Lorenzo Vicisano for their
+   helpful comments.
+
+9  Authors' Addresses
+
+   Colin Perkins
+   Department of Computer Science
+   University College London
+   Gower Street
+   London WC1E 6BT
+   United Kingdom
+
+   EMail: c.perkins@cs.ucl.ac.uk
+
+
+   Orion Hodson
+   Department of Computer Science
+   University College London
+   Gower Street
+   London WC1E 6BT
+   United Kingdom
+
+   EMail: o.hodson@cs.ucl.ac.uk
+
+References
+
+   [1] R.E. Blahut. Theory and Practice ofError Control Codes.
+       Addison Wesley, 1983.
+
+   [2] J.-C. Bolot and A. Vega-Garcia. The case for FEC based
+       error control for packet audio in the Internet. To appear
+       in ACM Multimedia Systems.
+
+
+
+
+Perkins & Hodson             Informational                      [Page 9]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+   [3] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,
+       D. Newell, J. Ott, S. Wenger, and C.  Zhu. RTP payload
+       format for the 1998 version of ITU-T reccomendation  H.263
+       video (H.263+).  Work in Progress.
+
+   [4] D. Budge, R. McKenzie, W. Mills, W. Diss,  and P. Long.
+       Media-independent error correction using RTP, Work in Progress.
+
+   [5] G. Carle and E. W. Biersack. Survey of error recovery
+       techniques for IP-based audio-visual multicast applications.
+       IEEE Network, 11(6):24--36, November/December 1997.
+
+   [6] S. Floyd and K. Fall. Promoting the use  of end-to-end
+       congestion control in the internet. Submitted to IEEE/ACM
+       Transactions on Networking, February 1998.
+
+   [7] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang.
+       A reliable multicast framework for light-weight sessions and
+       applications level framing. IEEE/ACM Transactions on Networking,
+       1995.
+
+   [8] M. Handley.   An examination of Mbone performance.  USC/ISI
+       Research Report:  ISI/RR-97-450, April 1997.
+
+   [9] M. Handley and J. Crowcroft.   Network text editor (NTE): A
+       scalable shared text editor for the Mbone.   In Proceedings
+       ACM SIGCOMM'97, Cannes, France, September 1997.
+
+  [10] V. Hardman, M. A. Sasse, M. Handley, and  A. Watson.
+       Reliable audio for use over the Internet.    In Proceedings
+       of INET'95, 1995.
+
+  [11] I. Kouvelas, O. Hodson, V. Hardman, and J.  Crowcroft.
+       Redundancy control in real-time Internet audio conferencing.
+       In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.
+
+  [12] S. McCanne, V. Jacobson, and M. Vetterli.   Receiver-driven
+       layered multicast.  In Proceedings ACM SIGCOMM'96, Stanford,
+       CA., August 1996.
+
+  [13] J. Nonnenmacher, E. Biersack, and D. Towsley.   Parity-based
+       loss recovery for reliable multicast transmission. In
+       Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.
+
+  [14] P. Parnes.   RTP extension for scalable reliable multicast,
+       Work in Progress.
+
+
+
+
+
+Perkins & Hodson             Informational                     [Page 10]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+  [15] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
+       Bolot, J-C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
+       for Redundant Audio Data", RFC 2198, September 1997.
+
+  [16] J.L. Ramsey. Realization of optimum interleavers. IEEE Transactions
+       on Information Theory, IT-16:338--345, May 1970.
+
+  [17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for
+       generic forward error correction in RTP.  Work in Progress.
+
+  [18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+       "RTP: A transport protocol for real-time applications",
+       RFC 1889, January 1996.
+
+  [19] L. Vicisano, L. Rizzo, and Crowcroft J.  TCP-like congestion
+       control for layered multicast data transfer.  In Proceedings
+       IEEE INFOCOM'98, 1998.
+
+  [20] R. X. Xu, A. C. Myers, H. Zhang,  and R. Yavatkar.
+       Resilient multicast support for continuous media applications.
+       In Proceedingsof the 7th International Workshop on Network and
+       Operating Systems Support for Digital Audio and Video
+       (NOSSDAV'97), Washington University in St. Louis, Missouri,
+       May 1997.
+
+  [21] M. Yajnik, J. Kurose, and D. Towsley. Packet loss correlation
+       in the Mbone multicast network. In Proceedings IEEE Global
+       Internet Conference, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hodson             Informational                     [Page 11]
+
+RFC 2354         Options for Repair of Streaming Media         June 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hodson             Informational                     [Page 12]
+