AVT B. VerSteeg Internet-Draft A. Begen Intended status: Standards Track Cisco Systems Expires: September 10, 2009 T. VanCaenegem Alcatel-Lucent Z. Vax Microsoft Corporation March 9, 2009 Unicast-Based Rapid Synchronization with RTP Multicast Sessions draft-versteeg-avt-rapid-synchronization-for-rtp-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 10, 2009. Copyright Notice VerSteeg, et al. Expires September 10, 2009 [Page 1] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract When a receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties, the time lag before a receiver can usefully consume the multicast data, which we refer to as the synchronization delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTCP protocol machinery that reduces the synchronization delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/ accompanies the multicast flow. This unicast flow may be transmitted at a faster than natural rate to further accelerate the synchronization. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the synchronization delay is long enough to be a problem. VerSteeg, et al. Expires September 10, 2009 [Page 2] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Elements of Delay in Multicast Streams . . . . . . . . . . . . 7 5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Synchronization . . . . . . . . 9 6. Rapid Multicast Synchronization . . . . . . . . . . . . . . . 11 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 18 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 18 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 19 7.1. RMS Request . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. RMS Information . . . . . . . . . . . . . . . . . . . . . 21 7.3. RMS Termination . . . . . . . . . . . . . . . . . . . . . 23 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 24 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 27 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 27 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 27 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 27 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 13.1. Registration of SDP Attribute Values . . . . . . . . . . . 28 13.2. Registration of FMT Values . . . . . . . . . . . . . . . . 28 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 29 15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 VerSteeg, et al. Expires September 10, 2009 [Page 3] Internet-Draft Rapid Synchronization for RTP Flows March 2009 1. Introduction Most multicast flows carry a stream of inter-related data. Certain information must first be acquired by the receivers to start processing any data sent in the multicast session. This document refers to this information as Reference Information. The Reference Information is conventionally sent periodically in the multicast session and usually consists of items such as a description of the schema for the rest of the data, references to which data to process for the receivers, encryption information including keys, as well as any other information required to process the data in the multicast flow. Real-time multicast applications require the receivers to buffer data. The receiver may have to buffer data to smooth out the network jitter, to allow loss-repair methods such as Forward Error Correction and retransmission to recover the missing packets, and to satisfy the data processing requirements of the application layer. When a receiver joins a multicast session, it has no control over what point in the flow is currently being transmitted. Sometimes the receiver may join the session right before the Reference Information is sent in the session. In this case, the required waiting time is usually minimal. Similarly, the receiver may also join the session right after the Reference Information has been transmitted. In this case the receiver has to wait for the Reference Information to appear again in the stream before it can start processing any multicast data. In some other cases, the Reference Information is not contiguous in the flow but dispersed over a large period, which forces the receiver to wait for all of the Reference Information to arrive before starting to process the rest of the data. The net effect of waiting for the Reference Information and waiting for various buffers to fill up is that the receivers may experience significantly large delays in data processing. In this document, we refer to the difference between the time a receiver joins the multicast session and the time the receiver acquires all the necessary Reference Information as the Synchronization Delay. The synchronization delay may not be the same for different receivers; it usually varies depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties. The varying nature of the synchronization delay adversely affects the receivers that frequently switch among multicast sessions. In this specification, we address this problem for RTP-based multicast applications and describe a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. In this VerSteeg, et al. Expires September 10, 2009 [Page 4] Internet-Draft Rapid Synchronization for RTP Flows March 2009 method, either the multicast source (or the distribution source in a single-source multicast (SSM) session) retains Reference Information for a period after transmission, or an intermediary network element joins the multicast session and continuously caches the Reference Information as it is sent in the session and acts as a feedback target (See [I-D.ietf-avt-rtcpssm])for the session. When a receiver wishes to join the same multicast session, instead of simply issuing an Internet Group Management Protocol (IGMP) [RFC3376] Join message, it sends a request to the feedback target address for the session asking for the Reference Information. The feedback target starts a unicast retransmission RTP session and sends the Reference Information to the receiver over that session. If there is spare bandwidth, the feedback target may also burst the Reference Information at a faster than natural rate. As soon as the receiver acquires the Reference Information, it can join the multicast group and start processing the multicast data. This method potentially reduces the synchronization delay. We refer to this method as Unicast-based Rapid Synchronization with RTP Multicast Sessions. A simplified network diagram showing the rapid synchronization method through an intermediary network element is depicted in Figure 1. +-------------------+ +--->| Intermediary | | ...| Network Element | | : +-------------------+ | : | v +-----------+ +----------+ +----------+ | Multicast | | Router |---------->| Joining | | Source |------->| |..........>| RTP | +-----------+ +----------+ | Receiver | | +----------+ | | +----------+ +---------------->| Existing | | RTP | | Receiver | +----------+ ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 1: Rapid synchronization through an intermediary network element A primary design goal in this solution is to use the existing tools in the RTP protocol family. This improves the versatility of the VerSteeg, et al. Expires September 10, 2009 [Page 5] Internet-Draft Rapid Synchronization for RTP Flows March 2009 existing implementations, and promotes faster deployment and better interoperability. To this effect, we use the unicast retransmission support of RTP [RFC4588] and the capabilities of RTCP to handle the signaling needed to accomplish the synchronization. The packet(s) carrying the Reference Information are sent by the feedback target in the auxiliary unicast session for rapid synchronization. These are constructed as retransmission packets that would have been sent in a unicast RTP session to recover the missing packets at a receiver that has never received any packet. In fact, a single RTP session MAY be used for both rapid synchronization and retransmission-based loss repair. Furthermore, the session can be used to simultaneously provide unicast burst traffic for the rapid synchronization and repair packets requested by the receiver when it detects lost burst packets or lost RTP packets from the primary multicast stream (in the case it is receiving both streams at the same time). The conventional RTCP feedback message that requests the retransmission of the missing packets [RFC4585] indicates their sequence numbers. However, upon joining a new session the receiver has never received a packet and thus, does not know the sequence numbers. Instead, the receiver sends a newly defined RTCP feedback message to request the Reference Information needed to rapidly synchronize with the primary multicast session. It is also worth noting that in order to issue the initial RTCP message to the feedback target, the SSRC of the session to be joined must be known prior to any packet reception, and hence, needs to be signaled out-of-band (or in-band). In a Session Description Protocol (SDP) description, the SSRC MUST be signaled through the 'ssrc' attribute [I-D.ietf-avt-rtcpssm] In the rest of this specification, we have the following outline: In Section 4, we describe the delay components in generic multicast applications. Section 5 presents an overview of the protocol design considerations for rapid synchronization. We provide the protocol details of the rapid multicast synchronization method in Section 6 and Section 7. Section 8 and Section 9 discuss the SDP signaling issues with examples and NAT-related issues, respectively. Note that Section 3 provides a list of the definitions frequently used in this document. 2. Requirements Notation 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 [RFC2119]. VerSteeg, et al. Expires September 10, 2009 [Page 6] Internet-Draft Rapid Synchronization for RTP Flows March 2009 3. Definitions This document uses the following acronyms and definitions frequently: Media Session: Media session as defined in [RFC3550]. Primary Multicast Stream: The one-to-many RTP stream of single- source multicast (SSM) RTP packets to which an RTP receiver joins at a random point in time. Feedback Target: (Unicast RTCP) Feedback target as defined in [I-D.ietf-avt-rtcpssm]. Retransmission Packet: Retransmission packet as defined in [RFC4588]. Burst (Stream): A unicast stream of RTP packets associated with the primary multicast stream. The burst stream is typically transmitted at an accelerated rate. Retransmission Server (RS): The RTP/RTCP endpoint generating the burst stream that can be triggered and controlled by messages defined in this document. Media and Reference Information: Media and reference information is a media stream containing the media content and its metadata, sufficient to reconstruct and use the content in the context of a specific application. The meaning, format and the size of this information are specific to the application and are out of scope of this document. Maximal Burst Bandwidth: The peak absolute bitrate for the unicast burst stream. This is supplied by the RTP receiver, based on its understanding of the access network capacity, its own ability to process burst packets, and other factors. 4. Elements of Delay in Multicast Streams In an any-source (ASM) or a single-source (SSM) multicast delivery system, there are three major elements that contribute to the overall synchronization delay when a receiver switches from one multicast session to another one. These are: o Multicast switching delay o Reference Information latency VerSteeg, et al. Expires September 10, 2009 [Page 7] Internet-Draft Rapid Synchronization for RTP Flows March 2009 o Buffering delays Multicast switching delay is the delay that is experienced to leave the current multicast session (if any) and join the new multicast session. In typical systems, the multicast join and leave operations are handled by a group management protocol. For example, the receivers and routers participating in a multicast session may use the Internet Group Management Protocol (IGMP) [RFC3376]. In [RFC3376], when a receiver wants to join a multicast session, it sends an IGMP Join message to its upstream router and the routing infrastructure sets up the multicast forwarding state to deliver the packets of the multicast session to the new receiver. Depending on the proximity of the upstream router, the current state of the multicast tree, the load on the system and the protocol implementation, the join times vary. Current systems provide join latencies usually less than 200 milliseconds (ms). If the receiver had been participating in another multicast session before joining the new session, it needs to send an IGMP Leave message to its upstream router to leave the session. In IGMP version 3 [RFC3376] , the leave times are usually smaller than the join times, however, it is possible that the Leave and Join messages may get lost, in which case the multicast switching delay inevitably increases. Reference Information latency is the time it takes the receiver to acquire the Reference Information. It is highly dependent on the proximity of the actual time the receiver joined the session to the next time the Reference Information will be sent to the receivers in the session, whether the Reference Information is sent contiguously or not, and the size of the Reference Information. For some multicast flows, there is a little or no interdependency in the data, in which case the Reference Information latency will be nil or negligible. For other multicast flows, there is a high degree of interdependency. One example of interest is the multicast flows that carry compressed audio/video. For these flows, the Reference Information latency may become quite large and be a major contributor to the overall delay. The buffering component of the overall synchronization delay is driven by the way the application layer processes the payload. In many multicast applications, an unreliable transport protocol such as UDP [RFC0768] is often used to transmit the data packets, and the reliability, if needed, is usually addressed through other means such as Forward Error Correction and retransmission [I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require buffering at the receiver side to function properly. In many applications, it is also often necessary to de-jitter the incoming data packets before feeding them to the application. The de- jittering process also increases the buffering delays. Besides these VerSteeg, et al. Expires September 10, 2009 [Page 8] Internet-Draft Rapid Synchronization for RTP Flows March 2009 network-related buffering delays, there are also specific buffering needs that are required by the individual applications. For example, MPEG decoders require a significant amount of content to be available in the decoder buffers prior to starting to decode the content. 5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Synchronization Rapid synchronization is an optimization of a system that must continue to work correctly whether or not the optimization is effective, or even fails due to lost control messages, congestion, or other problems. This is fundamental to the overall design requirements surrounding the protocol definition and to the resource management schemes to be employed together with the protocol (e.g., QoS machinery, server load management, etc). In particular, the system needs operate within a number of constraints. o First, a rapid synchronization operation must fail gracefully. The user experience must, except perhaps in pathological circumstances, be not significantly worse for trying and failing to complete rapid synchronization compared to simply joining the multicast session. o Second, providing the rapid synchronization optimizations must not cause collateral damage to either the multicast session being joined, or other multicast sessions sharing resources with the rapid synchronization operation. In particular, the rapid synchronization operation must avoid self-interference with the multicast session that may be simultaneously being received by other hosts. In addition, it must also avoid interference with other multicast sessions sharing the same network resources. These properties are possible, but difficult to achieve. One challenge is the existence of multiple bandwidth bottlenecks between the receiver and the server(s) in the network providing the rapid synchronization service. In commercial IPTV deployments, for example, bottlenecks are often present in the aggregation network connecting the IPTV servers to the network edge, the access links (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some of these links may serve only a single subscriber, limiting congestion impact to the traffic of only that subscriber, but others can be shared links carrying multicast sessions of many subscribers. A second challenge is that for some uses (e.g., high-bitrate video) the burst bandwidth is high while the flow duration of the burst is short. This is because the purpose of the burst is to allow the receiver to join the multicast quickly and thereby limit the overall VerSteeg, et al. Expires September 10, 2009 [Page 9] Internet-Draft Rapid Synchronization for RTP Flows March 2009 resources consumed by the burst. Such high-bitrate, short-duration flows are not amenable to conventional admission control techniques. For example, per-flow signaled admission control techniques such as RSVP have too much latency and control channel overhead to be a good fit for rapid multicast synchronization. Similarly, using a TCP (or TCP-like) approach with a 3-way handshake and slow-start to avoid inducing congestion would defeat the purpose of attempting rapid synchronization in the first place by introducing many RTTs of delay. These observations lead to certain unavoidable requirements and goals for a rapid multicast synchronization protocol. These are: o The protocol must be designed to allow a deterministic upper bound on the extra bandwidth used (compared to just joining the multicast group). A reasonable size bound is e*B, where B is the "nominal" bandwidth of the multicast flow, and e is an "excess- bandwidth" coefficient The total duration of the burst must have a reasonable bound; long bursts devolve to the bandwidth profile of multi-unicast for the whole system. o The scheme should minimize (or better eliminate) the overlap of the burst and the multicast flow. This minimizes the window during which congestion could be induced on a bottleneck link compared to just carrying the multicast or unicast packets alone. o The scheme must minimize (or better eliminate) any gap between the unicast burst and multicast flow which has to be repaired later, or in the absence of repair, will result in loss being experienced by the application. In addition to the above, there are some other protocol design issues to be considered. First, there is at least one RTT of "slop" in the control loop. In starting a rapid multicast synchronization burst, this manifests as the time between the client requesting the burst and the burst description (and possibly the first burst packets) arriving at the receiver. For managing and terminating the burst, there are two possible approaches for the control loop: The receiver can adapt to the burst as received, converge based on observation and explicitly terminate the burst with a second control loop exchange (which takes a minimum of one RTT, just as starting the burst does). Alternatively, the server generating the burst can pre-compute the burst parameters based on the information in the initial request and tell the receiver the burst duration. The protocol described in the next section allows either method of controlling the rapid multicast synchronization burst. VerSteeg, et al. Expires September 10, 2009 [Page 10] Internet-Draft Rapid Synchronization for RTP Flows March 2009 6. Rapid Multicast Synchronization We start this section with an overview of the rapid multicast synchronization (RMS) method. 6.1. Overview [I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control Protocol (RTCP) to use unicast feedback in an SSM session. It defines an architecture that introduces the concept of Distribution Source, which - in an SSM context - distributes RTP data and redistributes RTCP information to all receivers. This RTCP information is retrieved from the Feedback Target, to which RTCP unicast feedback traffic is sent. The Feedback Target MAY be implemented in one or more entities different from the Distribution Source, and different RTP receivers MAY use different Feedback Targets. This document builds further on these concepts to reduce the synchronization time when an RTP receiver wants to join a multicast session at a random point in time by introducing the concept of the Burst Source and new RTCP feedback messages. The Burst Source has a cache where the most recent RTP packets from the SSM distribution are continuously stored. When an RTP receiver wants to receive an SSM RTP stream, prior to joining the SSM session, it will first request an RTP burst from the Burst Source. In this burst, the packets are formatted as RTP retransmission packets [RFC4588] and the data carried in these packets allow the RTP receiver to synchronize quickly with the SSM session. Using an accelerated rate (as compared to the rate of the primary multicast stream) for the RTP burst implies that at a certain point in time, the payload transmitted in the RTP burst is going to be the same as the payload multicast in the SSM session, i.e., the unicast burst will catch up with the primary multicast stream. At this point, the RTP receiver no longer needs to receive the unicast RTP burst and can join the SSM session. This method is referred to as the Rapid Multicast Synchronization (RMS) method. This document proposes extensions to [RFC4585] for an RTP receiver to request an RTP burst as well as for additional control messaging that can be leveraged during the synchronization process. 6.2. Message Flows Figure 2 shows the main entities involved in rapid multicast synchronization: VerSteeg, et al. Expires September 10, 2009 [Page 11] Internet-Draft Rapid Synchronization for RTP Flows March 2009 o Multicast Source o Feedback Target (FT) o Burst Source o Retransmission Source o RTP Receiver (RR) +----------------------------------------------+ | Retransmission Server | | (RS) | | +----------+ +--------+ +----------------+ | | | Feedback | | Burst | | Retransmission | | | | Target | | Source | | Source | | | +----------+ +--------+ +----------------+ | +----------------------------------------------+ ^ ^ : | ' : | ' : | ' : +-----------+ +----------+ +----------+ | | | |'''''''''''>| | | Multicast |------->| Router |...........>| RTP | | Source | | |<~~~~~~~~~~~| Receiver | | | | |----------->| (RR) | +-----------+ +----------+ +----------+ '''> Unicast RTCP Messages ~~~> IGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 2: Flow diagram for unicast-based rapid synchronization A Retransmission Source can equally act as a Burst Source. The Retransmission Source can also incorporate the Feedback Target ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a retransmission server, since it is a logical function to which RRs send their unicast feedback), and we will use the term Retransmission Server (RS) in the remainder of the document to refer to a single physical entity comprising these three entities. Note that the same method (with the identical message flows) would also apply in a scenario where rapid synchronization is performed by a feedback target co-located with the media source. VerSteeg, et al. Expires September 10, 2009 [Page 12] Internet-Draft Rapid Synchronization for RTP Flows March 2009 As the RTP burst packets are formatted as RTP retransmission packets [RFC4585], the unicast RTP burst and RTP retransmissions MAY be provided in one and the same RTP (retransmission) session. The RTP burst is triggered by the RTCP feedback message defined in this document, whereas an RTP retransmission is triggered by an RTCP NACK message defined in [RFC4585]. Pending on RMS practices, there may be a gap between the end of the burst stream and the reception of the primary multicast stream because of the imperfections in the switch-over. RR can make use of the RTCP NACK message to request a retransmission for the missing packets in the gap. Editor's note: As stated in the text, FT, Burst Source and Retransmission Source are logical entities. For efficiency and simplicity, they MAY be implemented by a single physical Retransmission Server (RS). In a number of places throughout this document we assume (and explicitly state so) that all three are implemented by the same physical entity and therefore share the same IP address and the port number. The authors look to the AVT community for recommendations on whether this is sufficient or the mechanism has to explicitly address other topologies where FT, Burst Source and Retransmission Source are not co-located. Figure 3 depicts an example of messaging flow for rapid synchronization. The RTCP feedback messages are explained below. Note that the messages indicated in parentheses may or may not be present during rapid synchronization. VerSteeg, et al. Expires September 10, 2009 [Page 13] Internet-Draft Rapid Synchronization for RTP Flows March 2009 +-----------+ +----------------+ +----------+ +------------+ | Multicast | | Retransmission | | | | RTP | | Source | | Server | | Router | | Receiver | | | | (RS) | | | | (RR) | +-----------+ +----------------+ +----------+ +------------+ | | | | |-- RTP Multicast ------------------->| | | | | | |-- RTP Multicast ->| | | | | | | | |<''''''''''''''''''' RTCP RMR-R ''| | | | | | | | | | |'' (RTCP RMS-I) '''''''''''''''''>| | | | | | | | | | |.. Unicast RTP Burst ............>| | | | | | | | | | |'' (RTCP RMS-I) '''''''''''''''''>| | | | | | | | | | | |<~~ IGMP Join ~~| | | | | | | | | |-- RTP Multicast ------------------------------------>| | | | | | | | | | |<''''''''''''''''''' RTCP RMR-T ''| | | | | | | | | | |<''''''''''''''''''' (RTCP NACK)''| | | | | | | | | | |.. (Unicast Retransmissions) ....>| | | | | | | | | | |<''''''''''''''''''''' RTCP BYE ''| | | | | | | | | | | | | '''> Unicast RTCP Messages ~~~> IGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow VerSteeg, et al. Expires September 10, 2009 [Page 14] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Figure 3: Message flows for unicast-based rapid synchronization This document defines the expected behaviors of RS and RR. It is instructive to have independently operating implementations on RS and RR that request the burst, describe the burst, start the burst, join the multicast stream and stop the burst. These implementations send messages to each other, but there MUST be provisions for the cases where the control messages get lost or are not being delivered to their destinations. The following steps describe rapid synchronization in detail: 1. Request: RR sends a rapid synchronization request for the new multicast RTP session to the feedback target address of that session. The request contains the SSRC of RR and the SSRC of the media source. This RTCP feedback message is defined as Rapid Multicast Synchronization Request (RMS-R) message and MAY contain parameters, which may constrain the burst, such as the bandwidth limit. Other parameters may be related to the amount of buffering capacity available at RR, which may be used by RS to prepare a rapid synchronization burst that conforms with RR's requirements. Before joining the primary multicast session, a new joining RR learns the addresses associated with the new multicast session (addresses for the multicast source, group and retransmission server) by out-of-band means (See for Section 8 details). Also note that since no RTP packets have been received yet for this session, the SSRC must be obtained out-of-band or in-band. See Section 8 for details. 2. Response: RS receives the RMS-R message and decides whether to accept it or not. RS MUST send an (at least one) RMS-Information (RMS-I) message to RR. The first RMS-I message MAY precede the burst or it may be sent during the burst. Additional RMS-I messages may be sent during the burst. The join-time information (for the new multicast session) MUST be populated in at least one of the RMS-I messages. Note that RS learns the IP address and port information for RR from the RMS-R message it received. (This description glosses over the NAT details. Refer to Section 9 for a discussion of NAT-related issues.) If RS cannot provide a rapid synchronization service, RS rejects the request and informs RR immediately via an RMS-I message. If RR receives a message indicating that its rapid synchronization request has been denied, it abandons the rapid synchronization VerSteeg, et al. Expires September 10, 2009 [Page 15] Internet-Draft Rapid Synchronization for RTP Flows March 2009 attempt and MAY immediately join the multicast session by sending an IGMP Join message [RFC3376] to its upstream multicast router for the new multicast session. If RS accepts the request, it sends an RMS-I message to RR (before commencing the burst or during the burst) that comprises fields that can be used to describe the burst that will be sent by RS (e.g., the bitrate and the size of the burst). There may also be optional payload-specific information that RS chooses to send to RR. Such an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for transmitting the payload-specific information for MPEG2 Transport Streams. The burst duration may be calculated by RS, and its value may be updated by messages received from RR. 3. Updated Responses: RS may send more than one RMS-I messages, e.g., to update the burst bitrate information when the bitrate is adapted and/or to signal RR in real time to join the SSM session. For redundancy purposes, an RMS-I message MAY also be sent multiple times. RR may depend on RS to learn the join-time for the SSM session. The join-time can be conveyed by the first RMS-I message, or it can be sent/revised in later RMS-I messages. If RS is not capable of determining the join-time in the first RMS-I message, it will have to send another RMS-I message later. 4. SSM Join: In principal, RR can join the primary multicast session any time during or after the end of the RTP burst via an IGMP Join message [RFC3376]. However, there may be missing packets if RR joins the SSM session too early or too late. For example, if RR starts receiving the primary multicast stream while it is still receiving the RTP burst at a high excess bitrate, this may result in an increased risk of packet loss. Or, if RR joins the SSM session some time after the RTP burst is finished, there may be a gap between burst and multicast data (a number of RTP packets may be missing). In both cases, RR MAY issue retransmissions requests [RFC4585] to fill the gap. Yet, there are cases where the remaining available bandwidth may limit the number of retransmissions that can be provided within a certain time period, causing the retransmission data to arrive too late at RR (from application layer point of view). To cope with such cases, the RMS-I message allows RS to signal explicitly when RR should join the SSM session. Alternatively, RS may pre- compute the burst duration and the time RR should join the SSM session. This information may be conveyed in the RMS-I message and can be updated in subsequent RMS-I messages. RR may use the information from the most recent RMS-I message, or it may use a locally calculated join-time. VerSteeg, et al. Expires September 10, 2009 [Page 16] Internet-Draft Rapid Synchronization for RTP Flows March 2009 5. Multicast Receive: After joining the SSM session, RR starts receiving the multicast RTP flow. 6. Terminate: RS may know when it needs to stop the unicast burst based on the burst parameters, or RR may explicitly let RS know the sequence number of the first RTP packet it received from the multicast session, or RR may request RS to terminate the burst immediately. RR SHALL use the RMS-Termination (RMS-T) message when it wishes to provide information to RS regarding the cessation of the burst. RR can choose to send the RMS-T message before or after it starts receiving the multicast data. In the latter case, RR SHALL include the sequence number of the first RTP packet received in the SSM session in the RMS-T message, and RS SHOULD terminate the burst after it sends the RTP burst packet whose OSN field in the RTP retransmission payload header matches this number minus one. If RR wants to stop the burst prior to receiving the multicast data, it sends an empty RMS-T message (i.e., without an RTP sequence number). Note that regardless of whether RS knows when to stop the burst or not, RR MUST send at least one RMS-T message. Against the possibility of a message loss, RR MAY repeat the RMS-T messages multiple times as long as it follows the RTCP timer rules defined in [RFC4585]. 7. Terminate with RTCP BYE: When RR is no longer interested in receiving the primary multicast stream and the associated burst, RR SHALL issue an RTCP BYE message to the Feedback Target to terminate the burst and RTP retransmission session. Upon receiving an RTCP BYE message, RS MUST terminate the rapid synchronization operation, and cease transmitting any further packets of the associated unicast burst. Section 6.1 of [RFC3550] mandates the RTCP BYE message always to be sent with a sender or receiver report in a compound RTCP packet (If no data has been received, an empty receiver report MUST be included). With the information contained in the receiver report, RS can also figure out how many duplicate RTP packets have been delivered to RR (Note that this will be an upper-bound estimate as one or more packets might have been lost during the burst transmission). The impact of duplicate packets and measures that can be taken to minimize the impact of receiving duplicate packets will be addressed in Section 6.3. Note that if RR decides to switch to a new multicast session VerSteeg, et al. Expires September 10, 2009 [Page 17] Internet-Draft Rapid Synchronization for RTP Flows March 2009 after it already joined a multicast session following a rapid synchronization request, RR MUST also send an RTCP BYE message for the session associated with the current multicast source stream. For the purpose of gathering detailed information about RR's rapid synchronization experience,[I-D.begen-avt-rapid-sync-rtcp-xr] defines an RTCP Extended Report (XR) Block. This report is designed to be payload-independent, thus, it can be used by any multicast application that supports rapid synchronization. Support for this XR report is, however, optional. 6.3. Shaping the Unicast Burst Editor's note: This section may discuss sizing of the buffers, output buffer overload protection, output bandwidth management, adjustment of burst rate and duration. TBC. 6.4. Failure Cases Editor's note: This section discusses what happens if the request for rapid synchronization gets lost, or rapid synchronization fails, or when there are no available resources, etc. All RMS messages MAY be sent several times to the possibility of message loss as long as RS/RR follows the RTCP timer rules defined in [RFC4585]. In the following we examine the implications of losing the RMS-R, RMS-I or RMS-T messages. When RR sends an RMS-R message to initiate a rapid synchronization but the message gets lost and RS does not receive it, RR will not get an RMS-I message, nor an RTP burst. In this case, RR may, within a reasonable amount of time, either resend the request or may time out and immediately join the primary multicast session. The timeout duration may be based on the previous observed response times. In the case RR starts receiving an RTP burst but it does not receive a corresponding RMS-I message within a reasonable amount of time, RR MAY either discard the burst data and stop the burst by sending an RTCP BYE message to RS, or decide not to interrupt the RTP burst and be prepared to join the primary multicast session at an appropriate time it determines or indicated in a subsequent RMS-I message. In either case, RR SHALL send an RMS-T message to RS at an appropriate time. In the case the RMS-T message sent by RR does not reach its VerSteeg, et al. Expires September 10, 2009 [Page 18] Internet-Draft Rapid Synchronization for RTP Flows March 2009 destination, RS may continue sending the RTP burst even though RR no longer needs it. In some cases, RS has not pre-computed the burst duration and does not know when to stop the burst. To cover that case, RR MAY repeat the RMS-T message multiple times as long as it follows the RTCP timer rules defined in [RFC4585]. RS MUST be provisioned to deterministically terminate the burst at some point, even if it never receives an RMS-T message. If RR determines that rapid synchronization has failed, it SHOULD first cancel the pending/active rapid synchronization operation. Then, if staying on the same session, RR SHOULD join the multicast session; if switching to a new session, RR MAY send a new rapid synchronization request for the new session only after it sends an RTCP BYE message to the Feedback Target to terminate the existing burst and RTP retransmission session. 7. Encoding of the Signaling Protocol in RTCP This section defines the formats of the RTCP transport-layer feedback messages that are exchanged between the Retransmission Server (RS) and RTP Receiver (RR) during rapid multicast synchronization (RMS). These messages are payload-independent and SHOULD be used by all RTP- based multicast applications that support rapid synchronization regardless of the payload they carry. Specific payload formats are not defined in this document, but a framework is presented that allows payload-specific information to be included in the exchange. The common packet format for the RTCP feedback messages is defined in Section 6.1 of [RFC4585]. Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), payload type (PT), length, SSRC of packet sender, SSRC of media source as well as a variable-length field for feedback control information (FCI). In the transport-layer feedback messages, the PT field is set to RTPFB (205). Editor's note: Rather than having special cases for "value unknown or unspecified" in each of the fields carried in the messages, we are considering to format the fields in these structures as Type/Length/ Value (TLV) elements. If the originator of the message does not have a value for a field, the field will not be present. The advantage of this design is that there will not be any ambiguity in the value of the field. The disadvantage is that the message is variable length, and slightly more complex to generate/parse. VerSteeg, et al. Expires September 10, 2009 [Page 19] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Extensions: Optional extended parameters may be encoded using TLV elements as described below: o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. o Length: A two-octet field that indicates the length of the Value field. o Value: Variable-size set of octets that contains the specific value for the parameter. If a TLV element does not fall on a 32-bit boundary, the last word must be padded to the boundary using further bits set to 0. Editor's note: A design that will allow vendor-specific extensions to be used in these messages is also desirable. For interop purposes, the design must avoid collisions. Some approaches are currently being examined. 7.1. RMS Request The RMS Request message is identified by PT=RTPFB and FMT=5. The FCI field MUST contain only one RMS Request. The RMS Request is used by RR to request rapid synchronization for a new multicast RTP session. The FCI field has the structure depicted in Figure 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min RMS Buffer Fill Requirement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max RMS Buffer Fill Requirement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Receive Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FCI field syntax for the RMS Request message VerSteeg, et al. Expires September 10, 2009 [Page 20] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Min RMS Buffer Fill Requirement (32 bits): The minimum amount of data (in ms) required by RR after the burst completes. If specified, the amount of backfill that will be provided by the unicast burst SHOULD NOT be smaller than this value since it will not be able to build up the desired level of buffer at RR and may cause buffer underruns. Max RMS Buffer Fill Requirement (32 bits): The maximum amount of data (in ms) that can be received by RR after the burst completes. If specified, the amount of backfill that will be provided by the unicast burst SHOULD NOT be larger than this value since it may cause buffer overflows at RR. Max Receive Bitrate (32 bits): The maximum bitrate (in bits per second) that RR can receive. If specified, the unicast burst bitrate SHOULD NOT be larger than this value since it may cause congestion and packet loss. The length of the feedback message MUST be set to 2+n, where n is the number of fields contained in the message. The semantics of this feedback message is independent of the payload type. 7.2. RMS Information The RMS Information message is identified by PT=RTPFB and FMT=6. The FCI field MUST contain only one RMS Information. The RMS Information is used to describe the unicast burst that will be sent for rapid synchronization. It also includes other useful information for RR. The FCI field has the structure depicted in Figure 5. VerSteeg, et al. Expires September 10, 2009 [Page 21] Internet-Draft Rapid Synchronization for RTP Flows March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSN | Response | Rsvd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended RTP Seqnum of the First Burst Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Earliest IGMP Join Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rapid Synchronization Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Burst Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: FCI field syntax for the RMS Information message Message Sequence Number (8 bits) : During rapid synchronization, the RMS-I message(s) may be sent more than once. The first RMS-I message SHALL have an MSN value of 0. This value SHALL NOT be changed if the same RMS-I message is sent to the same RR multiple times for redundancy purposes. If a new information is conveyed in a new RMS-I message, the MSN value SHALL be incremented by one. Response (8 bits): Three values are defined: A value of 0 indicates that rapid synchronization request has been rejected. This MAY trigger RR to proceed with joining the primary multicast session. A value of 1 indicates that the rapid synchronization request has been accepted. A value of 2 means that RR SHOULD immediately join the primary multicast session. Other values MAY be defined later. Rsvd (16 bits): Reserved. Extended RTP Seqnum of the First Burst Packet (32 bits): The extended RTP sequence number of the first packet that will be sent as part of the rapid synchronization in the burst. This allows RR to know if one or more packets have been dropped at the beginning of the burst. 32-bit extended RTP sequence number is constructed by putting the 16-bit RTP sequence number in the lower two bytes and octet 0's in the higher two bytes. Earliest IGMP Join Time (32 bits): Time difference between the arrival of the RMS-I message and the earliest time instant when RR could join the new multicast session (in RTP clock ticks). A value of all 1's means that it is not specified. VerSteeg, et al. Expires September 10, 2009 [Page 22] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Rapid Synchronization Duration (32 bits): Time difference between the timestamps of the first and last RTP packets in the unicast burst (in RTP clock ticks). A value of all 1's means that it is not specified. Max Burst Bitrate (32 bits): The max bandwidth used by RS for the unicast burst, expressed in bits per second. A value of 0 means that it is not specified. The length of the feedback message MUST be set to 2+n, where n is the number of fields contained in the message. The semantics of this feedback message is independent of the payload type. The RMS-I message MAY be sent multiple times at the start of, prior to, or during the RTP unicast burst. The subsequent RMS-I messages MAY signal changes in any of the fields. 7.3. RMS Termination The RMS Termination message is identified by PT=RTPFB and FMT=7. The FCI field MUST contain only one RMS Termination. The RMS Termination may be used to assist RS in determining when to stop the burst. If prior to sending the RMS-T message RR has already joined the multicast session and received at least one RTP packet from the multicast session, RR includes the sequence number of the first RTP packet in the RMS-T message. With this information, RS can decide when to terminate the unicast burst. If RR issues the RMS-T message before it has joined and/or begun receiving RTP packets from the multicast session, RR does not specify any sequence number in the RMS-T message, which indicates RS to stop the burst immediately. However, note that RS may not receive this message or may alter the burst. The FCI field has the structure depicted in Figure 6. VerSteeg, et al. Expires September 10, 2009 [Page 23] Internet-Draft Rapid Synchronization for RTP Flows March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended RTP Seqnum of the First Multicast Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: FCI field syntax for the RMS Termination message Extended RTP Seqnum of the First Multicast Packet (32 bits): The extended RTP sequence number of the first packet received from the multicast session. Editor's note: We need to either have TLV syntax for this field, add a "valid flag" or come up with a reasonable value for "unknown". The length of the feedback message MUST be set to 2+n, where n is the number of fields contained in the message. The semantics of this feedback message is independent of the payload type. 8. SDP Definitions and Examples 8.1. Definitions The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. Here we add the following syntax to the 'rtcp-fb' attribute (the feedback type and optional parameters are all case sensitive): (In the following ABNF [RFC5234], fmt, SP and CRLF are used as defined in [RFC4566].) rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF rtcp-fb-pt = "*" ; wildcard: applies to all formats / fmt ; as defined in SDP spec rtcp-fb-val = "nack" SP "ssli" The following parameter is defined in this document for use with 'nack': o 'ssli' stands for Stream Synchronization Loss Indication and indicates the use of RMS messages as defined in Section 7. VerSteeg, et al. Expires September 10, 2009 [Page 24] Internet-Draft Rapid Synchronization for RTP Flows March 2009 8.2. Examples This section provides an SDP [RFC4566] example for enabling rapid synchronization with multicast RTP sessions. The following example uses the SDP grouping semantics [RFC3388], the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP extensions for SSM sessions with unicast feedback [I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-mmusic-sdp-source-attributes]. In the example below, we have two primary source streams and two unicast retransmission streams for each of these source streams. The source streams are multicast from a distribution source (with a source IP address of 8.166.1.1) in different multicast groups. For each source stream, a feedback target address (9.30.30.1) is also specified with the 'rtcp' attribute. The receiver(s) can report missing packets on the source stream to the feedback target and request retransmissions. The parameter 'rtx-time' specifies the time in milliseconds (measured from the time a packet was first sent) that the sender (in this case the feedback target) keeps an RTP packet in its buffers available for retransmission. For the first source stream, only the conventional retransmission support is enabled. For the second source stream, both the conventional retransmission and rapid synchronization support are enabled. This is achieved by the "a=rtcp-fb:98 nack ssli" line. When a receiver requires rapid synchronization for a new multicast session it wants to join, it sends an RMS-R message to the feedback target. This feedback message has to have the SSRC of the primary source session for which rapid synchronization is requested for. However, since this receiver has not received any RTP packets from this primary source session yet, the receiver MUST learn the SSRC value from the 'ssrc' attribute of the media description [I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname' source attribute MUST also be present in the SDP description [I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC values for the primary source sessions in the SDP file does not create a problem in SSM sessions when an SSRC collision occurs. This is because in SSM sessions, a receiver that observed an SSRC collision with a media source MUST change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550]. A feedback target that receives an RMS-R feedback message becomes aware that the prediction chain at the receiver side has been broken or does not exist any more. If the necessary conditions are satisfied (as outlined in Section 7 of [RFC4585]) and available resources exist, the feedback target MAY react to the RMS-R message VerSteeg, et al. Expires September 10, 2009 [Page 25] Internet-Draft Rapid Synchronization for RTP Flows March 2009 by sending the payload-specific feedback message(s) and starting the unicast burst. v=0 o=ali 1122334455 1122334466 IN IP4 rtp.rocks.com s=Rapid Synchronization Examples t=0 0 a=group:FID 1 2 a=group:FID 3 4 a=rtcp-unicast:rsi m=video 40000 RTP/AVPF 96 i=Primary Source Stream #1 c=IN IP4 224.1.1.1/255 a=source-filter: incl IN IP4 224.1.1.1 8.166.1.1 a=recvonly a=rtpmap:96 MP2T/90000 a=rtcp:40001 IN IP4 9.30.30.1 a=rtcp-fb:96 nack a=mid:1 m=video 40002 RTP/AVPF 97 i=Unicast Retransmission Stream #1 (Ret. Support Only) c=IN IP4 9.30.30.1 a=recvonly a=rtpmap:97 rtx/90000 a=rtcp:40003 a=fmtp:97 apt=96 a=fmtp:97 rtx-time=3000 a=mid:2 m=video 41000 RTP/AVPF 98 i=Primary Source Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 8.166.1.1 a=recvonly a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 9.30.30.1 a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=ssrc:123321 cname:iptv-ch32@rms.example.com a=mid:3 m=video 41002 RTP/AVPF 99 i=Unicast Retransmission Stream #2 (Ret. and Rapid Synch. Support) c=IN IP4 9.30.30.1 a=recvonly a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98 a=fmtp:99 rtx-time=5000 a=mid:4 VerSteeg, et al. Expires September 10, 2009 [Page 26] Internet-Draft Rapid Synchronization for RTP Flows March 2009 9. NAT Considerations TBC. 10. Known Implementations 10.1. Open Source RTP Receiver Implementation by Cisco An open source RTP Receiver code that implements the functionalities introduced in this document is available. For documentation, visit the following URL: http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/ ch1_over.html The code is also available at: ftp://ftpeng.cisco.com/ftp/vqec/ Note that this code is under development and may be based on an earlier version of this document. As we make progress in the draft, the source code will also be updated to reflect the changes. Some preliminary results based on this code are available in [CCNC09] and [IC2009]. 10.2. IPTV Commercial Implementation by Microsoft Rapid Multicast Synchronization is supported as part of the Microsoft Mediaroom Internet Protocol Television (IPTV) and multimedia software platform. This system is in wide commercial deployment. More information can be found at: http://www.microsoft.com/mediaroom http://informitv.com/articles/2008/10/13/channelchangetimes/ 11. Open Issues o Finalizing the RTCP payload-independent message formats. o Designing a capability for extending the feedback message formats in the future. o Burst shaping issues. VerSteeg, et al. Expires September 10, 2009 [Page 27] Internet-Draft Rapid Synchronization for RTP Flows March 2009 12. Security Considerations TBC. 13. IANA Considerations This document registers a new SDP attribute value and several new RTCP packets. The following contact information shall be used for all registrations in this document: Ali Begen abegen@cisco.com 170 West Tasman Drive San Jose, CA 95134 USA 13.1. Registration of SDP Attribute Values This document registers a new value for the 'nack' attribute to be used with the 'rtcp-fb' attribute in SDP. For more information about 'rtcp-fb', refer to [RFC4585]. Value name: ssli Long name: Stream Synchronization Loss Indication Usable with: nack Reference: This document 13.2. Registration of FMT Values Within the RTPFB range, the following three format (FMT) values are registered: Name: RMS-R Long name: Rapid Multicast Synchronization Request Value: 5 Reference: This document VerSteeg, et al. Expires September 10, 2009 [Page 28] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Name: RMS-I Long name: Rapid Multicast Synchronization Information Value: 6 Reference: This document Name: RMS-T Long name: Rapid Multicast Synchronization Termination Value: 7 Reference: This document 14. Acknowledgments The authors would like to thank the following for their contributions to this document: Dave Oran, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Roni Even and Guy Hirson. 15. Change Log 15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-02 The following are the major changes compared to version 01: o The discussion around MPEG2-TS has been moved to another document. o The RMS-R, RMS-I and RMS-T messages have been extensively modified and they have been made mandatory. o IANA Considerations section has been updated. o The discussion of RTCP XR report has been moved to another document. o A new section on protocol design considerations has been added. 15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-01 The following are the major changes compared to version 00: o The core of the rapid synchronization method is now payload- independent. But, the draft still defines payload-specific messages that are required for enabling rapid synch for the RTP flows carrying MPEG2-TS. o RTCP APP packets have been removed, new RTCP transport-layer and payload-specific feedback messages have been defined. VerSteeg, et al. Expires September 10, 2009 [Page 29] Internet-Draft Rapid Synchronization for RTP Flows March 2009 o The step for leaving the current multicast session has been removed from Section 6.2. o A new RTCP XR (Multicast Join) report has been defined. o IANA Considerations section have been updated. o Editorial changes to clarify several points. 16. References 16.1. Normative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [I-D.ietf-avt-rtcpssm] Ott, J., "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 (work in progress), January 2008. [I-D.ietf-mmusic-sdp-source-attributes] Lennox, J., Ott, J., and T. Schierl, "Source-Specific VerSteeg, et al. Expires September 10, 2009 [Page 30] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Media Attributes in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work in progress), October 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 16.2. Informative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [I-D.ietf-rmt-pi-norm-revised] Adamson, B., Bormann, C., London, U., and J. Macker, "NACK-Oriented Reliable Multicast Protocol", draft-ietf-rmt-pi-norm-revised-08 (work in progress), December 2008. [I-D.begen-avt-rtp-mpeg2ts-preamble] Begen, A., "RTP Payload Format for MPEG2-TS Preamble", draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in progress), March 2009. [I-D.begen-avt-rapid-sync-rtcp-xr] Begen, A., "Rapid Multicast Synchronization Report Block Type for RTCP XR", draft-begen-avt-rapid-sync-rtcp-xr-00 (work in progress), March 2009. [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified Approach for Repairing Packet Loss and Accelerating Channel Changes in Multicast IPTV (IEEE CCNC)", January 2009. [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing Channel Change Times in IPTV with Real-Time Transport Protocol (IEEE Internet Computing)", May 2009. Authors' Addresses Bill VerSteeg Cisco Systems 5030 Sugarloaf Parkway Lawrenceville, GA 30044 USA Email: billvs@cisco.com VerSteeg, et al. Expires September 10, 2009 [Page 31] Internet-Draft Rapid Synchronization for RTP Flows March 2009 Ali Begen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: abegen@cisco.com Tom VanCaenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen, 2018 Belgium Email: Tom.Van_Caenegem@alcatel-lucent.be Zeev Vax Microsoft Corporation 1065 La Avenida Mountain View, CA 94043 USA Email: zeevvax@microsoft.com VerSteeg, et al. Expires September 10, 2009 [Page 32]