Subject: [Fecframe] one new document to be discussed

From: "qin hao" <[email-masked]>
Date: Thu, 26 Oct 2006 11:04:45 +0800

Dear members,
There is one document we want to be discussed. It is not an official
document, we will submit it officially as soon as the IETF allows new
submissions.
The document presents a generic RTP payload format for guaranteeing QoS of
video communication with FEC technique.

Request you kindly provide the feedback.

 Best regards,

FECFrame                                                          B. Song
Internet-Draft                                                    H. Qin
Expires: May 5, 2007                                        Xidian Univ.
                                                                Nov 2006

   Generic RTP Payload Format guaranteeing QoS of Video communication
                       draft-bsong-fecframe-gfec-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 May 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document presents a new generic RTP payload format for
   guaranteeing QoS of video communication, and describes a generic
   scheme to packetize video stream for transport using the presented
   RTP payload format.  Forward erasure correction and interleaving are
   used in the scheme to reduce the impact of the packet losses.  Video
   stream may be unequally FEC protected with different strength such
   that the QoS of video communication can be greatly improved.
   Furthermore, this document presents an application of this generic

Song & Qin                 Expires May 5, 2007                  [Page 1]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

   scheme in video communication.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Forward erasure correction . . . . . . . . . . . . . . . . . .  4
   3.  A Generic payload format for FEC and interleaving  . . . . . .  5
     3.1.  FEC algorithm with unequal error protection  . . . . . . .  6
     3.2.  Interleaving FEC encoded blocks  . . . . . . . . . . . . .  7
     3.3.  Encapsulating interleaved blocks into RTP packets  . . . .  8
     3.4.  Delay consideration and parameter determination  . . . . .  8
     3.5.  Detecting packet losses  . . . . . . . . . . . . . . . . .  9
   4.  An application of FEC and interleaving in video
       communication  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  characteristics of the video data  . . . . . . . . . . . . 11
     4.2.  Design consideration . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  the more important video data  . . . . . . . . . . . . 11
       4.2.2.  the less important video data  . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Song & Qin                 Expires May 5, 2007                  [Page 2]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

1.  Introduction

   The nature of real-time video applications implies that they usually
   have more stringent delay requirements than normal data
   transmissions.  As a result, the retransmission of lost packets is
   generally not an acceptable option for such applications.  In these
   cases, a better method is to attempt to recover the information
   contained in lost packets through Forward Error Correction (FEC)
   [RFC3453].  On the other hand, interleaving the data streams from the
   sender can mitigate quality degradation due to packet loss,
   especially burst loss.  This document specifies a new RTP payload
   format, which can guarantee the QoS of video communication, and as an
   example, provides the description of its application to video data
   streams.

1.1.  Terminology

   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 BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant RTP
   implementations.

Song & Qin                 Expires May 5, 2007                  [Page 3]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

2.  Forward erasure correction

   In the general literature, FEC refers to the ability to overcome both
   erasure errors and bit-level corruptions [RFC3558].  However, in the
   case of an IP-based protocol, either the network layer detects
   corrupted packets and discard them, or the transport layer uses
   packet authentication mechanism to discard corrupted packets.
   Therefore the primary application of FEC codes to IP protocols is one
   as an erasure code.  On the sender's side, the payloads are generated
   and processed using an FEC erasure encoder, and on the receiver's
   side, objects are reassembled from the reception of the packets
   containing the FEC encoded payloads by an FEC erasure decoder using
   the corresponding FEC mechanism.

   A (N, K) FEC code works in the following way.  The input to a block
   FEC encoder are origin data blocks (ODBs) of equal length grouped
   into batches with one batch at a time.  Each batch contains K ODBs,
   and for each batch of input ODBs, the encoder then generates a total
   of N>K encoded data blocks (EDB) composed of the K ODBs and the N-K
   redundant check blocks.  The whole group of these N EDBs is referred
   to as an FEC unit.  A block FEC decoder has the property that any K
   of the N EDBs is sufficient to reconstruct the original K ODBs.  A
   typical (N, K) erasure code is known as Tornado code.

Song & Qin                 Expires May 5, 2007                  [Page 4]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

3.  A Generic payload format for FEC and interleaving

   In order to improve the ability of the receiver to tolerate the
   packet losses and guarantee the QoS of real-time communications,
   especially video communications, this section presents a novel
   generic RTP payload format for which attempts to relieve if not
   eliminate the impacts of packet losses.

   The new RTP payload format is defined as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         RTP Header                            |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |C|  R  |FECType|FEC subtype|     packet index  | block size    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               one or more encoded data blocks                 |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RTP header fields take the values described in the RTP
   specification [RFC3550].  The fields for generic FEC and interleaving
   are specified as follows:

   C: 1 bits
      Reserved, MUST be set to zero by the sender, SHOULD be ignored by
      the receiver.

   R: 3 bit
      The field indicates the type of interleaving algorithms used for
      the RTP payload.  A value of zero means no interleaving is used
      for this RTP payload,the output data is time-ordered.

   FEC type: 4 bits
      The field indicates the type of FEC algorithms (erasure code) used
      for the RTP payload.  A value of zero means no FEC is used for
      this RTP payload.  The mapping of non-zero FEC type values to FEC
      algorithms is not to be specified in this document.

   FEC subtype: 6 bits
      The field is used to define the different subtype of FEC type
      which is defined above.  The basic idea of using two fields FEC
      type and FEC subtype to identify a certain FEC code is that the
      whole family of FEC codes can be divided into different
      subfamilies and each subfamily contains FEC codes with similar
      characteristics and generation mechanisms.  The FEC type field
      indicates which subfamily a certain FEC code is in and the FEC

Song & Qin                 Expires May 5, 2007                  [Page 5]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

      subtype field further indicates in the given subfamily what
      generation parameters are used for this certain FEC code.  Usually
      FEC codes in a subfamily have similar generation mechanism but
      different generation parameters, and as a result, different
      protection strengths.

      This field SHOULD be ignored if FEC type is zero.  For non-zero
      FEC subtype values, parameters of FEC algorithm, such as the
      values of N and K for (N, K) erasure code, SHOULD be uniquely
      determined by this field.  Therefore, for a given non-zero value
      of the FEC subtype field, parameters of FEC algorithm can be
      exactly derived.

   Packet index: 10bits

      If interleaving is used, This field indicates zero-based index
      within an interleaving group which is used to tell the indices of
      lost packets in each interleaving group (see section 3.2) which
      are important to FEC decoding.  In contrast, the SN field in RTP
      header tells the indices of the lost packets.

      If interleaving is not used, this field indicates zero-based block
      index within an FEC unit which is used to tell the indices of lost
      blocks in each FEC unit.

      The value of this field SHOULD be less than N, which is the number
      of EDBs comprising an FEC unit.

   Block size (B): 8 bits
      Each data block contained in an FEC unit SHOULD have the same
      size, and this field indicates the number of octets in a block.

3.1.  FEC algorithm with unequal error protection

   Real-time data in a RTP session may have different relative
   importance to the receiver.  Generally speaking, the encoded stream
   of a video sequence is launched frame by frame.  These frames have
   different importance to the video decoder, For example, in H.264
   video communication, reference frames are critical to a decoder to
   reconstruct following pictures, and prediction frames are used to
   reconstruct just one picture based on the previous reference frame.
   Losses of reference frames may cause far more serious disasters to
   the video decoder in the sense that the video decoder can be forced
   into an interruption lasting a rather long period.

   Data with different importance MAY be unequally protected with
   different FEC algorithms. if this is the case, only the data with the
   same or similar importance can be encapsulated into a RTP packet.  In

Song & Qin                 Expires May 5, 2007                  [Page 6]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

   other words, only one FEC algorithm can be used throughout a RTP
   packet.

   The encoded stream from the sender is equally divided into a sequence
   of origin data blocks, and each block has the size of B octets.
   Every K data blocks will be encoded using an FEC algorithm to
   generate N (N>K) encoded blocks.

   When unequal protection is enabled, if the total number of octets of
   the encoded stream with the same importance is not divided exactly by
   K*B. Padding octets should be appended to enable FEC algorithm to
   work correctly.

   The negotiation on FEC algorithms acceptable to both the sender and
   the receiver is not to be specified in this document.

3.2.  Interleaving FEC encoded blocks

   Bundling is used to spread the transmission overhead of the RTP and
   payload headers over multiple encoded blocks so as to maximize the
   bandwidth efficiency and minimize the transmission latency.
   Interleaving [RFC3453] additionally reduces the receiver's perception
   the negative effects of data losses by spreading such losses over
   non-consecutive blocks.  Interleaving is meaningful only if more than
   one encoded blocks are put into a single RTP packet.

   All receivers MUST support interleaving.  The senders MAY optionally
   support interleaving.

   Given a sequence of EDBs from the sender, numbered 0, .., n, and a
   (N, K) FEC algorithm.  Note that n SHOULD be divided exactly by N,
   this can be achieved using padding mentioned in section 3.1.  These n
   EDBs will be organized to form F=n/N FEC units, and will be further
   interleaved into G=(F+U-1)/U groups with interleaving length N where
   U is the maximum bundling value, i.e., the maximum FEC unit number
   that can be contained in a RTP packet.  The blocks are placed into
   RTP packets as follows:

   First RTP Packet in Interleaved group 0:

   Interleave index=0

   block 0, block N, block 2N, ... block (U-1)*N for a total of U blocks

   Second RTP Packet in Interleaved group 0:

   Interleave index=1

Song & Qin                 Expires May 5, 2007                  [Page 7]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

   block 1, block N+1, block 2N+1, ... block (U-1)*N+1 for a total of U
   blocks

   This continues to the last RTP packet in the interleave group 0:

   Nth RTP Packet in Interleaved group 0:

   Interleave index=N-1

   block N-1, block 2N-1, block 3N-1, ... block U*N-1 for a total of U
   blocks

   This continues to the interleaved group G-2.  Each RTP packet belongs
   to these G-1 interleaving groups contain U encoded blocks

   Until now, there are still F mod U FEC units to be interleaved for
   interleaved group G-1.  The same interleaving method as mentioned
   above is used for interleaving group G-1 with each RTP packet
   containing only V=F mod U encoded blocks.

3.3.  Encapsulating interleaved blocks into RTP packets

   A RTP packet MUST contain exactly one or more encoded blocks, i.e.,
   one encoded block SHOULD NOT span two or more RTP packets.  The
   sender MUST not contain more data blocks in a single RTP packet than
   can be fitted in the MTU (maximum transfer unit) of the underlying
   transport protocol.

   The following formula can be used to calculate the number of blocks
   in a RTP packet.  RTP packet size can be obtained from the underlying
   transport layer.

   U = (RTP_packet_size - RTP_header_length - payload_header_length) / B

   When interleaving is enabled, the bundle value V always equals to the
   block number in a RTP packet. and when interleaving is not used, to
   mitigate the impact of burst packet loss to the FEC decoder, only one
   FEC block SHOULD be encapsulated in every RTP packet.

3.4.  Delay consideration and parameter determination

   FEC and interleaving reduce the effect of pack losses at the cost of
   increasing the delay.  Large values of N, K or U increase not only
   the ability of the receiver to be tolerant of packet losses, but also
   the delay.  Tradeoff between the low end-to-end delay and great
   tolerance for packet losses should be made in the choice of FEC and
   interleaving parameters.

Song & Qin                 Expires May 5, 2007                  [Page 8]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

3.5.  Detecting packet losses

   From the difference of the SN fields of two consecutive received RTP
   packets, the number of lost packets can be determined.  When FEC is
   used, this information is insufficient for an FEC decoder to recover
   the lost packet.  To make the FEC decoder work, the position of the
   lost packets in their corresponding FEC unit need to be determined.

   1.  If the data are neither protected by the FEC and nor interleaved,
       the lost packet cannot be recovered.

   2.  If the data are protected by the FEC but are not interleaved.
       The receiver determines the number of data blocks N for all RTP
       packets in an FEC units by FEC type and FEC subtype field in the
       first received RTP packet of the FEC unit.  Note that this may
       not be the first RTP packet of the FEC unit if packets are lost
       or delivered out of order by the underlying transport.  Given an
       RTP packet with sequence number S, N (block number of an FEC
       unit), block index I, the FEC unit consists of this RTP packet
       and other RTP packets with sequence numbers ranging between S-I
       mod 65536 to S-I+N mod 65536 inclusively.  In other words, one
       FEC unit consists of N RTP packets with sequential sequence
       numbers.  The indices of lost packets in a given FEC unit can be
       detected quickly from the break of interleaving index field.
       This information is needed by the FEC decoder to recover the lost
       packets.

   3.  If the data are not only protected by FEC but also interleaved.
       The receiver determines the expected bundling value V for all RTP
       packets in an interleaved group by the number of encoded blocks
       bundled in the first received RTP packet of the interleaved group
       received.  Note that this may not be the first RTP packet of the
       interleaved group if packets are lost or delivered out of order
       by the underlying transport.  Given an RTP packet with sequence
       number S, interleaving length N which can be derived from the FEC
       subtype field, interleaving index value I, and bundling value U,
       the interleaved group consists of this RTP packet and other RTP
       packets with sequence numbers ranging between S-I mod 65536 to
       S-I+N mod 65536 inclusively.  In other words, the interleaved
       group always consists of N RTP packets with sequential sequence
       numbers.  The bundling values for all RTP packets in an
       interleaved group MUST be the same.  The indices of lost packets
       in a given interleaved group can be detected quickly from the
       interleaving index field.  This information is needed by the FEC
       decoder to recover the lost packets.

   The informations of the unrecovered packets, with the information of
   the corresponding FEC units or the corresponding interleaving group,

Song & Qin                 Expires May 5, 2007                  [Page 9]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

   should be reported to the high application.

Song & Qin                 Expires May 5, 2007                 [Page 10]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

4.  An application of FEC and interleaving in video communication

4.1.  characteristics of the video data

   The importance of the video data are different.  In a picture
   sequence, the data that are close to the beginning of the picture
   sequence are in general more important and they are more likely to
   carry more information than the data further back in the picture
   sequence.  In the other hand, the data which have the different
   function have the different importance, for example, for H.264 video
   data, I-slices are critical to the receiver.  The data which are
   located between two adjacent I-slices, called a picture sequence,
   have less importance than I-slices.

4.2.  Design consideration

   Video code stream is transmitted or stored based on frame.  As it is
   known, different data have different significances.  For the above
   mentioned reasons, the video encoded streams are unequally protected
   with different FEC protection strengths based on their significances.
   The more important data are protected by the stronger protection
   schemes.

4.2.1.  the more important video data

   the more important video data should be strongly protected. and the
   data should not be protected with interleaving, because the
   interleaving algorithm will introduce the more delay.  The time-
   ordered frames have the size of W octets, the data are equally
   divided into k=W/B data blocks, each data block has the size of B
   octets.  If W is not divided exactly by B, padding octets should be
   appended to enable FEC algorithm to work correctly.  For every K data
   blocks, N encoded blocks are generated via a strong FEC algorithm
   with more redundancy.  To mitigate the impact of burst packet loss to
   the FEC decoder, exactly one FEC block is encapsulated in one RTP
   packet.

   The format of encapsulation of the more important data is defined as
   follows.

    +-------------+   +------------+--------------+   +---------------+
    |data block #1|...|data block k|check block #1|...|check block N-k|
    +-------------+   +------------+--------------+   +---------------+
    ^             ^   ^            ^              ^   ^               ^
    |RTP packet #1|...|RTP packet k|RTP packet k+1|...| RTP packet N  |

Song & Qin                 Expires May 5, 2007                 [Page 11]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

4.2.2.  the less important video data

   Assuming the total number of octets of the less important video data
   which belong to the same picture sequence is W bytes, and the total
   number of octets, excluding the redundant octets appended by FEC, of
   an interleaved group is U*K*B. All these data can be divided into
   W/(U*K*B) groups, which will be protected with a normal FEC
   algorithm, interleaved and encapsulated.  There may remain W mod
   (U*K*B) octets.  These octets are encapsulated directly, i.e., they
   are neither protected with FEC nor interleaved.  Because they are at
   the end of the picture sequence, hence have lower importance.  Even
   these octets are lostGBP[not] their impacts on reconstructed pictures
   will be eliminated by the following I-slice.

   The format of encapsulation of the less important data which are
   protected with FEC and interleaving algorithms is defined as follows.

    +--------+--------+--------+   +----------+----------+   +--------+
    |    0   |    1   |    2   |...|   k-1    |    k     |...|   N-1  |
    +--------+--------+--------+   +----------+----------+   +--------+
    |    N   |   N+1  |   N+2  |...|  N+k-1   |   N+k    |...|  2N-1  |
    +--------+--------+--------+   +----------+----------+   +--------+
    |   ...  |   ...  |   ...  |   |   ...    |   ...    |   |   ...  |
    +--------+--------+--------+   +----------+----------+   +--------+
    | (U-1)N |(U-1)N+1|(U-1)N+2|...|(U-1)N+k-1| (U-1)N+k |...|  U*N-1 |
    +--------+--------+--------+   +----------+----------+   +--------+
    ^        ^        ^        ^   ^          ^          ^   ^        ^
    |RTP     |RTP     |RTP     |...|RTP       |RTP       |...|RTP     |
    |packet 1|packet 2|packet 3|   |packet k  |packet k+1|   |packet N|

Song & Qin                 Expires May 5, 2007                 [Page 12]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

5.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550], and any appropriate RTP profile.  This
   implies that confidentiality of the media streams is achieved by
   encryption.  Because the data compression used with this payload
   format is applied end-to-end, encryption may be performed after
   compression so there is no conflict between the two operations.

   A potential denial-of-service threat exists for data encoding using
   compression techniques that have non-uniform receiver-end
   computational load.  The attacker can inject pathological datagrams
   into the stream which are complex to decode and cause the receiver to
   be overloaded.  The usage of authentication of at least the RTP
   packet is RECOMMENDED

   As with any IP-based protocol, in some circumstances a receiver may
   be overloaded simply by the receipt of too many packets, either
   desired or undesired.  Network-layer authentication may be used to
   discard packets from undesired sources, but the processing cost of
   the authentication itself may be too high.  In a multicast
   environment, pruning of specific sources may be implemented in future
   versions of IGMP and in multicast routing protocols to allow a
   receiver to select which sources are allowed to reach it.

   A security review of this payload format found no additional
   considerations beyond those in the RTP specification.

Song & Qin                 Expires May 5, 2007                 [Page 13]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

6.  Conclusion

   Using the novel generic RTP payload format, forward erasure
   correction and interleaving described in this document, the
   capability of error resilience for real-time communications over
   error-prone IP networks with packet losses can be improved.
   Furthermore, this method is simple and easy-to-implement.

7.  Normative References

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [RFC3453]  Frederick, M., Vicisano, L., Gemmell, J., Rizzo, L.,
              Handley, M., and J. Crowcroft, "The Use of Forward Error
              Correction (FEC) in Reliable Multicast", RFC 3453,
              December 2002.

   [RFC3558]  Li, A., "RTP Payload Format for Enhanced Variable Rate
              Codecs (EVRC) and Selectable Mode Vocoders (SMV)",
              RFC 3558, July 2003.

Song & Qin                 Expires May 5, 2007                 [Page 14]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

Authors' Addresses

   Bin Song
   Xidian Univ.
   2 South TaiBai Road
   Xi'an, Shaanxi  710071
   CN

   Phone: +86 29 8820 4409
   Email: [email-masked]

   Hao Qin
   Xidian Univ.
   2 South TaiBai Road
   Xi'an, Shaanxi  710071
   CN

   Phone: +86 29 8820 3614
   Email: [email-masked]

Song & Qin                 Expires May 5, 2007                 [Page 15]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006

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
   [email-masked].

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 (2006).  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.

Song & Qin                 Expires May 5, 2007                 [Page 16]
_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe