Internet DRAFT - draft-xu-avt-subrtcp

draft-xu-avt-subrtcp





Network Working Group                                              X. Xu
Internet-Draft                                                 K. Connor
Intended status: Standards Track                               T. Shaikh
Expires: July 1, 2007                                     R. Padmanabhan
                                                              I. Umansky
                                                           Cisco Systems
                                                       December 28, 2006


    SubRTCP:RTCP Extension for Internal Monitoring of RTP Sessions.
                        draft-xu-avt-subrtcp-00

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 July 1, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes SubRTCP, an extension to RTCP.  SubRTCP
   operates on the same underlying transport establishement as for RTCP
   but functions independently of the latter.  SubRTCP extends RTCP to
   the middle nodes of an RTP session to allow monitoring of its data
   delivery also at and between these middle nodes.  Such an internal



Xu, et al.                Expires July 1, 2007                  [Page 1]

Internet-Draft                   SubRTCP                   December 2006


   visibility provided by SubRTCP at the middle nodes complements the
   delivery monitoring by RTCP at the endpoints particularly in service
   providers' interest.


1.  Introduction

   An RTP session consists of two or more endpoints and possibly
   multiple middle nodes such as IP-IP gateways and session border
   controllers (SBC).  Data delivery of an RTP session are currently
   monitored only at its endpoints by the RTCP protocol.  Such an end-
   to-end monitoring provided by RTCP does tell how well an RTP session
   goes as a whole but lacks any detail to point out at which middle
   node the RTP session suffers.

   On the other hand, a service provider is much interested in the
   detailed observation of an RTP session at its middle nodes for use to
   justify the overall picture of the quality of service reported at its
   endpoints.  For example, a service provider is interested in knowing
   if the portion of an RTP session lying between the two SBCs or edge
   routers of its network domain goes well or not.  But RTCP is unable
   to give such a segment-level visibility of an RTP session.

   A way of overcoming the deficiency of RTCP is to plug the monitors
   defined in RTCP [1] at points of interest in an RTP session to
   measure its current quality of service by passive observation of its
   RTP and RTCP packets.  But it is difficult to correlate such
   individual measurements at different points to create a meaningful
   picture to udnerstand how well a segment between two points does.
   Furthermore, a monitor knows nothing about the application context
   where the RTP session is set.  Thus, such monitors do not fulfil a
   good solution.

   SubRTCP provides the solution by extending RTCP into the middle nodes
   of an RTP session to allow deeper monitoring of its data delivery at
   these middle nodes.  SubRTCP uses the same algorithms as for RTCP to
   measure the quality of service including packet loss, interrarrival
   jitter and round trip time.  But it could be expanded to accommodate
   other algorithms as well, such as RTCP-XR [2] and RTCP-HR [3].
   SubRTCP allows monitoring of the quality of service at the middle
   nodes of an RTP session and conveys such quality of services between
   the middle nodes to create a full picture of the on-going RTP session
   with regard to how it goes within the RTP session.

   SubRTCP operates at the RTP plane consisting of the RTP resources
   only including RTP terminals e.g.  IP phones, voice gateways, IP-IP
   gateways and SBCs.  Visibility at RTP plane is not sufficient to
   locate problems at the underlying data routing plane, which is being



Xu, et al.                Expires July 1, 2007                  [Page 2]

Internet-Draft                   SubRTCP                   December 2006


   investigated as a separate issue beyond the scope of this document.

   Also a more general solution is to allow monitoring of data delivery
   at service level rather than at RTP.  Such a solution can be applied
   to different applications on top of IP layer including RTP-based
   applications.  This is another separate issue being studied and
   beyond the scope of this document,too.


2.  Overview of SubRTCP

   With reference to Figure 1 where an RTP session is established
   between endpoints E1 and E2 but in-between traverses multiple middle
   RTP nodes RN1~n.  RTCP will function at both endpoints to do an
   overall monitoring of data delivery for the RTP session from the end-
   to-end perspective.  RTCP does not care much about how the RTP
   session goes at any particular middle node internally.

         +--------+    +-----+     +-----+     +-----+    +--------+
         |        |    |     |     |     |     |     |    |        |
         |   E1   +----+ RN1 +-----+ RN2 +-...-+ RNn +----+   E2   |
         |        |    |     |     |     |     |     |    |        |
         +--------+    +-----+     +-----+     +-----+    +--------+

            Figure 1: An RTP Session with Multiple Middle Nodes

   With extension of SubRTCP, a middle node will be able to monitor the
   on-going RTP session to provide the internal view of the RTP session
   at its point of location.  A middle node can pair up with other
   middle nodes and even endpoints to exchange their observation of the
   RTP session including calculating the round trip time (rtt) between
   each pair.

   For example, as illustrated in Figure 2, RNi pairs up with all its
   left-side nodes, each pair forming a segment between its two footing
   nodes, resulting in segments (RNi,RNi-1), (RNi,RNi-2),...,(RNi,RN1)
   and (RNi, E1).  The same way RNi can pair up with its righ-side
   nodes, too.

             |--------------------------|(RNi,E1)
             |         |----------------|(RNi,RN1)
             |         |         |------|(RNi,RNi-1)
         +--------+  +---+     +---+  +---+     +---+  +--------+
         |        |  |   |     |   |  |   |     |   |  |        |
         |Endpoint+--+RN +-...-+RN +--+RN +-...-+RN +--+Endpoint|
         |    1   |  | 1 |     |i-1|  | i |     | n |  |   2    |
         +--------+  +---+     +---+  +---+     +---+  +--------+




Xu, et al.                Expires July 1, 2007                  [Page 3]

Internet-Draft                   SubRTCP                   December 2006


            Figure 2: Example of Internal RTP Session Segments

   With reference to Figure 2, once the end-to-end RTP session between
   E1 and E2 is set up, participants of the RTP session i.e.  E1 and E2
   can exchange RTCP packets to convey per-session RTP statistics such
   as packet loss, fraction loss and interarrival jitter and timestamps
   for use to calculate rtt.  The middle nodes RN1~n will not process
   these end-to-end RTCP packets except relaying them between the
   endpoints.  Independent of RTCP, middle nodes can start SubRTCP to
   monitor the internal segements of the RTP session.

   For example, RNi can send a SubRTCP packet to report its observation
   of the RTP session at its location eastward and also solicit response
   from all or part of the RTP nodes on its left side.  Upon receiving a
   SubRTCP packet from RNi, RNi-1 can take one of the following actions:
   (1) Do nothing but relay this SubRTCP message further left to RNi-2;
   (2) Relay the packet to RNi-2 and also act on this packet, if needed
   send a response SubRTCP packet toward RNi;(3) Simply ignore the
   packet.  By performing these actions selectively and collectively at
   middle RTP nodes and endpoints of an RTP session, a middle RTP node
   can pair up with any middle node or endpoint of interest of the RTP
   session on its left side or right side or both to provide segement-
   level monitoring between the paired nodes.

2.1.  SubRTCP Use Scenario

   With reference to Figure 3, SubRTCP provides monitoring of segments
   A-B, B-C and C-D of the RTP session A-B-C-D.  The B-C segment may
   have some other middle RTP nodes sitting in-between.  When the end-
   to-end RTCP of the RTP session reports poor quality of service, the
   service provider X can start SubRTCP to monitor the B-C, A-B and C-D
   segments to narrow down the location of the problem.  The monitoring
   of segment B-C is always of interest to service provider X.
   Sometimes, service provider X may need to extend its responsibility
   to VGW (voice gateway) A and D, thus segments A-B and C-D becoming
   part of service provider X's interest, too.

         +--------------+    +------------------+     +--------------+
         |Enterprise    |    |Service Provider X|     |    Enterprise|
         |  site A  +---+    +---+ Network  +---+     +---+  site D  |
         |          |VGW|    |SBC|          |SBC|     |VGW|          |
         |          | A +----+ B +----//----+ C +-----+ D |          |
         |          +---+    +---+          +---+     +---+          |
         |              |    |                  |     |              |
         +--------------+    +------------------+     +--------------+

                Figure 3: One SubRTCP Application Scenario




Xu, et al.                Expires July 1, 2007                  [Page 4]

Internet-Draft                   SubRTCP                   December 2006


   When an RTP session crosses NATs, SubRTCP of the RTP session may
   require NAT traversals from one middle node to another.  STUN [4] and
   ICE [5] may be considered for overcoming the NAT traversal issue,
   which are beyond the scope of this document.


3.  SubRTCP Protocol

   SubRTCP operates in the RTCP framework but functions in the internal
   part of an RTP session versas the external or overall view of the RTP
   session monitored by RTCP at the endpoints.  This basic difference
   will be translated into the specifics of the SubRTCP protocol,
   detailed subsequently.

3.1.  Monitoring At Middle Nodes

   A middle RTP node of an RTP session monitors the data delivery of the
   session according to the same algorithms as for the endpoints
   specified in RTCP [1].  But a middle node is usually not a source or
   sink of the RTP packets.  It is a pure observer of an RTP session and
   is capable of seeing all the participants involved in the RTP
   session.

   Statistics generated at middle nodes of an RTP session can be
   retrieved remotely through SNMP [6]and correlated with the
   application context of the RTP session, which is beyond the scope of
   this document.

3.2.  Internal SSRC Space

   SubRTCP operates internally and is mostly invisible to the
   participants i.e. endpoints of an RTP session.  It is thus impossible
   for the endpoints to take the middle nodes of an RTP session into
   account for adjusting their RTCP report interval.  On the other hand,
   Operation of SubRTCP is in service providers' interest which should
   not interfere with the RTCP for the endpoints.  Due to this
   fundamental difference, SubRTCP will operate in its own SSRC space
   called the Internal SSRC Space versas the RTP SSRC space consisting
   of SSRCs used in RTP packets and RTCP packets.  The same SSRC can be
   assigned to an endpoint and a middle RTP node safely since they are
   from different SSRC space.

   A mddile RTP node is neither a source nor a sink of an RTP session.
   Thus the SSRC for a middle node serves as a pure unique identifier
   for the node, nothing else.

   SSRC for a middle RTP node can be assigned through configuration or
   or locally generated by the node itself, which is implementation



Xu, et al.                Expires July 1, 2007                  [Page 5]

Internet-Draft                   SubRTCP                   December 2006


   specific.  Two different middle nodes may happen to bear the same
   SSRC which leads to SSRC collision.  The detection and resolution
   mechanism for SSRC collision specified for RTCP [1] is applicable to
   SSRC collision for the internal SSRC space.

3.2.1.  Interaction of Two SSRC Spaces

   A middle RTP node is able to see RTP packets, RTCP packets and
   SubRTCP packets.  SubRTCP will handle RTP packets in the RTP SSRC
   space to produce and maintain per-source i.e. per-SSRC statistics of
   the on-going RTP session according to the algorithms specified for
   RTCP [1].  But RTCP packets will be relayed through the same way as
   they are today.  A SubRTCP packet may contains information for both
   endpoints and middle nodes which need to be processed in their
   respective SSRC space accordingly.

3.3.  SubRTCP Packet Format

   Similarly, all SubRTCP packets MUST be sent in a compound packet of
   at least two individual packets.  A SubRTCP packet always starts with
   an S-TS packet, followed by optionally an S-RR packet, then by an
   SDES packet and optionally ends up with a BYE packet.

          [S-TS packet][S-RR packet][SDES Packet][BYE packet]
          |                                                 |
          |<-------  SubRTCP compound packet -------------->|
          |<----------  UDP packet ------------------------>|

                    Figure 4: Example of SubRTCP Packet

   SDES and BYE are defined in [1].  S-TS and S-RR are new RTCP packet
   introduced specifically for SubRTCP, which are defined in their
   respective sub-sections below.

3.3.1.  S-TS: SubRTCP Timestamp Packet

   S-TS (timestamp) packet conveys timestamp information between footing
   nodes of internal segments of RTP sesseion for use to estimate their
   in-between round trip times, formatted as follows:












Xu, et al.                Expires July 1, 2007                  [Page 6]

Internet-Draft                   SubRTCP                   December 2006


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|0|    RC   | PT=S-TS=209   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    S-SSRC of sender                           |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
TS     |                 S-SSRC_1   (SSRC of first middle RTP node)    |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1      |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
TS     |                 S-SSRC_2   (SSRC of second middle RTP node)   |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2      :                         ...                                   :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
TS     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

                       Figure 5: S-TS Packet Format

   The S-TS packet may consists of up to 3 sections: S-TS header, TS
   blocks and Sender TS, where the TS blocks and Sender TS sections are
   optional.  All SSRCs in this packet are from the Internal SSRC Space.

   The first section, the S-TS header, is 8 octets long.  The fields
   have the following meaning:

   receiption timestamp count (RC): 5 bits

   The number of TS blocks contained in this packet.  A value of zero is
   valid, meaning no TS blocks existing in the packet.

   packet type (PT): 8 bits

   Contains the constant 209 (tentatively assigned here) to identify
   this as a S-TS packet.

   S-SSRC: 32 bits

   Identifier for the originator of this SubRTCP packet.

   The rest of fields i.e. length and version (V) bear the same meaning
   as their definition in [1].  Padding bit is set to 0 since no padding
   is needed.



Xu, et al.                Expires July 1, 2007                  [Page 7]

Internet-Draft                   SubRTCP                   December 2006


   The second section is optional.  It contains zero or more TS blocks,
   depending on the number of other middle RTP nodes heard by this
   sender since the last SubRTCP packet.  Each TS block conveys two
   timestamps for one single middle RTP node identified by its S-SSRC.
   The fields contained in a TS block are:

   S-SSRC_n (identifier for n-th source middle RTP node): 32 bits

   The SSRC of the source middle RTP node to which the information in TS
   block pertains.

   The timestamp fields i.e.  LSR and DLSR are defined in [1]where
   SSRC_n is replaced with S-SSRC_n.

   The third section, the sender TS, is optional.  It is 16 octets long,
   used to conveys its wallclock timestamp to other RTP nodes.  The NTP
   timestamp is also defined in RTCP [1].

3.3.2.  S-RR: SubRTCP Receiver Report Packet

   S-RR is for use by a middle RTP node to report its observation of the
   on-going RTP session.  It's enclosed in a SubRTCP packet, formatted
   as follow:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|0|    RC   | PT=S-RR=210   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     S-SSRC of packet sender                   |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first endpoint source)        |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second endpoint source)       |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 6: S-RR Packet Format

   S-RR consists of two sections: S-RR header and report blocks.  A S-RR
   without any report block (RC=0) is valid but makes nonsense.  S-SSRC



Xu, et al.                Expires July 1, 2007                  [Page 8]

Internet-Draft                   SubRTCP                   December 2006


   is from the Internal SSRC Space but the rest of SSRCs i.e.  SSRC_n
   are from the RTP SSRC Space.

   The first section, the S-RR header, is 8 octets long.  Its fields
   bear the same meaning as their corresponding field in the S-TS header
   except:

   receiption report count (RC): 5 bits

   The number of TS blocks contained in this packet.  A value of zero is
   valid, meaning no report block existing in the packet.

   packet type (PT): 8 bits

   Contains the constant 210 (tentatively assigned here) to identify
   this as a S-RR packet.

   The second section contains zero or more receiption report blocks
   depending on the number of the RTP sesseion synchronization sources
   heard by the middle RTP node i.e. this sender since the last SubRTCP
   report.  Each reception report block conveys statistics on the
   reception of RTP packets from a single RTP session synchronization
   source.  Receivers SHOULD NOT carry over statistics when a source
   changes its SSRC identifier due to a collision.

   The fields have the same meaning as for the SR report defined in [1].

3.4.  Statistics at Middle Node

   A middle RTP node sitting in middle of RTP session is able to monitor
   RTP session traffic from all directions.  A SubRTCP can choose to
   send SubRTCP packets toward any direction e.g. eastward or westward
   or bothward.  In a SubRTCP packet, a middle node can attach
   statistics observed for all participants or endpoints in the
   contained S-RR packet.

3.5.  SubRTCP Report Interval

   SubRTCP determines its report interval independently of RTCP.  In
   fact, RTCP will not see SubRTCP if SubRTCP is not extended to any
   endpoint of an RTP session.  The report interval for SubRTCP could be
   user configured or locally generated independently at each individual
   middle RTP node.  Operation of SubRTCP is stateless which allows a
   middle RTP node to accept response to any soliciting SubRTCP packet
   sent earlier from the middle node.

   But a middle RTP node may adjust its SubRTCP report interval based on
   the longest rtt it is experiencing with other RTP nodes.  The purpose



Xu, et al.                Expires July 1, 2007                  [Page 9]

Internet-Draft                   SubRTCP                   December 2006


   is to ensure a middle RTP node a reasonable time to reduce the rate
   of sending SubRTCP packets.


4.  IANA Considerations

   Two new RTCP message types for SubRTCP reports S-TS and S-RR,
   tenatively assigned as 209 and 210, need to be registered to IANA.


5.  Security Considerations

   SubRTCP suffers from the same security concern as the RTCP.  For
   example, within SubRTCP, CNAME and NAME information could be
   impersonated.  To protect sensitive information, a SubRTCP report may
   be transferred securely.  In addition, middle RTP nodes involved in
   SubRTCP may need to be authenticated.


6.  Contributors

   The authors would gratefully acknowledge Dave Oran, Jonathan
   Rosenberg, Dan Wing, Flemming Andreasen, Bill Foster and Cullen
   Jennings for their explorable comments and thoughts on solutions to
   providing internal monitoring of RTP and even general data sessions.


7.  References

7.1.  Normative References

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

7.2.  Informational References

   [2]  Almeroth, K., Caceres, R., Clark, A., Cole, R., and N. Duffield,
        "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611,
        November 2003.

   [3]  Clark, A., Pendleton, A., Kumar, R., Conner, K., and G. Hunt,
        "RTCP HR - High Resolution VoIP Metrics Report Blocks",
        draft-clark-avt-rtcphr-02 (work in progress), June 2005.

   [4]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN -
        Simple Traversal of User Datagram Protocol (UDP) Through Network
        Address Translators (NATs)", RFC 3489, March 2003.



Xu, et al.                Expires July 1, 2007                 [Page 10]

Internet-Draft                   SubRTCP                   December 2006


   [5]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network Address Translator (NAT) Traversal for
        Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in
        progress).

   [6]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
        Network Management Protocol (SNMP)", RFC 1157, May 1990.


Authors' Addresses

   Xiaode Xu
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 853-4540
   Email: xdxu@cisco.com


   Kevin Connor
   Cisco Systems
   2901 Third Avenue
   Seattle, WA  98121
   USA

   Phone: +1 360 493-6411
   Email: kconnor@cisco.com


   Taher Shaikh
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 853-3113
   Email: moshaikh@cisco.com












Xu, et al.                Expires July 1, 2007                 [Page 11]

Internet-Draft                   SubRTCP                   December 2006


   Radhika Padmanabhan
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 525-6644
   Email: rpadmana@cisco.com


   Ilya Umansky
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 525-4625
   Email: ilyau@cisco.com

































Xu, et al.                Expires July 1, 2007                 [Page 12]

Internet-Draft                   SubRTCP                   December 2006


Full 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.

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xu, et al.                Expires July 1, 2007                 [Page 13]