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]