AVT Working Group J. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: September 9, 2010 H. Asaeda Keio University March 8, 2010 Proxy Rapid Acquisition of Multicast RTP Sessions draft-xia-avt-proxy-rapid-acquisition-01 Abstract This document describes a proxy rapid acquisition mechanism which reduces acquisition delay for an RTP receiver without supporting any rapid acquisition related functionality. The network is responsible for managing rapid acquisition on behalf of the RTP receiver, including detecting SFGMP message as proxy specified in [RFC4605] from the RTP receiver and launching the required rapid acquisition signaling instead of the RTP receiver. This proxy rapid acquisition of multicast RTP session in this document is referred to as Proxy Rapid Acquisition of Multicast Sessions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 9, 2010. Copyright Notice Xia, et al. Expires September 9, 2010 [Page 1] Internet-Draft PRAMS March 2010 Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proxy Rapid Acquisition Motivation . . . . . . . . . . . . . . 5 4. Proxy Rapid Acquisition Overview . . . . . . . . . . . . . . . 7 4.1. Proxy Rapid Acquisition Architecture . . . . . . . . . . . 7 4.2. Proxy Rapid Acquisition Message Flows . . . . . . . . . . 10 4.3. Proxy Acquisition Anchor Point Operation . . . . . . . . . 14 4.3.1. Membership Database . . . . . . . . . . . . . . . . . 15 4.3.2. Transport Address Mapping Database . . . . . . . . . . 16 4.3.3. Forwarding Packets . . . . . . . . . . . . . . . . . . 16 4.4. Retransmission Server Operation . . . . . . . . . . . . . 17 4.5. RTP Receiver Operation . . . . . . . . . . . . . . . . . . 17 5. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 17 5.1. Proxy Rapid Acquisition Request . . . . . . . . . . . . . 17 6. SDP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Xia, et al. Expires September 9, 2010 [Page 2] Internet-Draft PRAMS March 2010 1. Introduction The AVT working group has recently been working on specifying extensions to the unicast feedback for SSM sessions [RFC5760]. There is a large amount of interest from the IETF community in extending the protocol to support some real, practical and immediate use-cases for rapid acquisition. The basic requirement to adopt rapid acquisition and related solutions have been described in [I-D.ietf-avt-rapid-acquisition-for-rtp], [I-D.draft-johansson-avt-mcast-based-rams]and [I-D.draft-wang-avt-rtp-improved-rams]. In order to reduce the acquisition time, these solutions primarily require the RTP receiver to support rapid acquisition related functionality, including the ability to solicit or terminate the burst and provide required parameters to the network. These extensions will be implemented by receiver's software, and maybe hardware, to accommodate the requirement. From this viewpoint, this requirement may lead its deployment difficulties. This document proposes a proxy rapid acquisition approach without RTP receiver involvement by extending RTCP Rapid Acquisition [I-D.ietf-avt-rapid-acquisition-for-rtp] . This approach does not require the RTP receiver to be involved in the exchange of signaling messages between a RS and an RTP receiver. In order for this to work, a proxy rapid acquisition function, called the Proxy Acquisition Anchor Point, is introduced and allocated in the access network, and performs the rapid acquisition related signaling with a RS on behalf of the RTP receivers. Furthermore, the Proxy Acquisition Anchor Point should support feedback target function to perform aggregation of incoming RTCP messages and send aggregated information directly or indirectly (e.g., the Proxy Acquisition Anchor Point acts as a leaf feedback target in a hierarchical topological structure) to Distribution Source as described in [RFC5760]. The document is organized as follows: in Section 3, we describe the motivation why use a proxy network entity to perform rapid acquisition on behave of RTP receiver; in Section 4, we present an overview of the protocol design and behavior of network entities; in Section 5, we list som messages that are exchanged between the RS and Proxy Acquisition Anchor Point during proxy rapid acquisition.;in Section 6, we discuss SDP signaling items with examples. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Xia, et al. Expires September 9, 2010 [Page 3] Internet-Draft PRAMS March 2010 document are to be interpreted as described in [RFC2119]. All terms in this document are defined in [RFC4585], [RFC4588], [RFC5760], [I-D.ietf-avt-rapid-acquisition-for-rtp] and [RFC4605]. In addition or in replacement of these, the following terms are defined or redefined: Proxy Acquisition Domain Proxy Acquisition Domain refers to the access network where the rapid acquisition management of a RTP receiver is handled by Proxy Acquisition Anchor Point as defined in this document. The Proxy Acquisition domain includes single Proxy Acquisition Anchor Point and multiple RTP receivers between which security associations can be set up. It may consist of multiple wire or wireless interface technologies (e.g. XDSL, MSTP, 802.16e, Universal Mobile Telecommunications System (UMTS), etc.) interconnected with multiple types of backhaul interconnections (such as Synchronous Optical Network (SONET), Metro Ethernet, etc.). Proxy Acquisition Anchor Point (PAAP) The Proxy Acquisition Anchor Point is aggregation router which manages the rapid acquisition related signaling for RTP receivers attached to the proxy acquisition domain. Furthermore, Proxy Acquisition Anchor Point is responsible for receiving the RTP receivers' SFGMP Join/Leave messages, performing rapid acquisition related signaling with the RS and aggregating RTCP information of RTP receivers to Distribution Source. In this document, the Proxy Acquisition Anchor Point MUST support the SFGMP Proxy functionality specified in [RFC4605] and support the Feedback Target functionality specified in [RFC5760]. RTP Receiver (RR) Throughout this document, the term "RTP Receiver" refers to the entity whose rapid acquisition related functionality is managed by the Proxy Acquisition Anchor Point. As a result, the RTP Receiver is not required to participate in any rapid acquisition related signaling for achieving rapid acquisition in the Proxy Acquisition Domain. Multicast Burst A multicast stream is translated by Proxy Acquisition Anchor Point into an RTP receiver understandable multicast format when Proxy Acquisition Anchor Point receives the unicast RTP burst stream from Burst Source [I-D.ietf-avt-rapid-acquisition-for-rtp] or the Xia, et al. Expires September 9, 2010 [Page 4] Internet-Draft PRAMS March 2010 unicast retransmission stream from Retransmission Source [RFC4588]. If the multicast stream conveyed to RTP receiver is to enable RTP receiver to rapidly acquire the Reference Information, the multicast burst stream is typically shaped and transmitted at an accelerated rate. Otherwise, the multicast burst stream is shaped and transmitted at a normal rate. Proxy Rapid Acquisition Request A new RTCP message is sent by Proxy Acquisition Anchor Point to RS for triggering unicast burst stream for the RTP receivers in its proxy acquisition domain. Proxy Rapid Acquisition Information A new RTCP message is sent by RS in response to Proxy Rapid Acquisition Request message that it received from Proxy Acquisition Anchor Point. Proxy Rapid Acquisition Termination A new RTCP message is sent by Proxy Acquisition Anchor Point to RS for terminating unicast burst stream. 3. Proxy Rapid Acquisition Motivation All current rapid acquisition methods utilize an auxiliary high- bitrate unicast or multicast burst triggered by the RTP receiver to reduce the acquisition time. The common characteristic of these methods is that software update, system resource allocation or hardware modification are required on RTP receiver to support rapid acquisition related functionality. This limits broad usage even if the updates are small. The followings are the specific issues that should be taken into account: 1. A large number of the RTP receivers lacking rapid acquisition capability have been largely deployed. It is required lots of efforts for each vendor to adopt rapid acquisition on all variants of Windows, Android, iPhone, Linux and BSD systems. Additionally, it will be impossible to support older models for which support has been discontinued. 2. To avoid congestion possibility on the access network, RTP receiver needs to frequently acquire the network state information. It is assume that a RTP receiver may have knowledge of a portion of this network which is in the vicinity of the RTP receiver as described in section 5 of Xia, et al. Expires September 9, 2010 [Page 5] Internet-Draft PRAMS March 2010 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, the RS may be located far from the RTP receiver, in which case learning about the states of network adjacent to RS is still a difficult task for RTP receiver. Let alone it will be more complicated when the states of network are varying over time. From the whole network point of view, the transmission rate reported by RTP receiver only reflects the capability of RTP receiver itself or its adjacent access network rather than the capability of the comprehensive network. 3. The RTP receiver may not smoothly splice (minimize or eliminate the overlap and gap) the unicast burst stream and primary multicast stream because of imperfections in the switch over. 4. The rapid acquisition signaling messages will consume radio resources and the RTP receiver's power when RTP receiver is a mobile terminal. The situation becomes worse in the case where all rapid acquisition messages are sent multiple times against the possibility of message loss. For these reasons, Proxy Acquisition Anchor Point located at access network is able to perform rapid acquisition related signaling for RTP receivers as well as aggregate information contained in RTCP packets of RTP receivers inside its domain. As an intermediary network entity, Proxy Acquisition Anchor Point has a more global view of the access network close to RTP receiver, as well as the aggregate network close to RS. So Proxy Acquisition Anchor Point can adjust bursting rate according to the states (i.e., transmission medium, number of RTP receivers behind it, upper bound bandwidth etc) of each segmental network respectively. It will be more efficient to reduce the transmission latency when delivering burst from RS to RTP receiver. For example, RS can transmit RTP packets at 10Gbit/s rate to Proxy Acquisition Anchor Point when fiber link is deployed between them, while Proxy Acquisition Anchor Point can only transmit RTP packets at 200Mbit/s rate to RTP receiver when ADSL link is deployed between them. The burst can earlier arrives at RTP receiver compared to always transmit RTP packets at 200Mbit/s rate in the whole burst course. On the path between RS and RTP receiver, Proxy Acquisition Anchor Point is regarded as an RTP receiver from RS perspective. Proxy Acquisition Anchor Point should keep bursting with higher rate until the burst catches up with the primary multicast stream, then terminates the burst and conveys the primary multicast stream to RTP receiver, in which case the overlap and gap are perfectly eliminated on RTP receiver even if Proxy Acquisition Anchor Point needs to filter the overlap of the unicast burst and the primary multicast Xia, et al. Expires September 9, 2010 [Page 6] Internet-Draft PRAMS March 2010 stream as an trade-off. However the network between RS and Proxy Acquisition Anchor Point usually can provide wider bandwidth than access network, so the network congestion caused by overlap is almost negligible and the possibility of congestion-caused packet loss is absolutely decreased. The other advantages of developing a proxy rapid acquisition protocol based on RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] are: 1. Reuse of RS functionality and the messages/format used in RAMS signaling. RAMS is a mature protocol with several implementations that have undergone interoperability testing. 2. For a rapid acquisition capable RTP receiver, the Proxy Acquisition Anchor Point must be transparent to RAMS messages from/to the RTP receiver without any interference. The above observations, justify the development of the proxy rapid acquisition protocol as an efficient alternative to RAMS. The details of how a Proxy Acquisition Anchor Point perform rapid acquisition on behalf of the RTP receiver are described in the following sections. 4. Proxy Rapid Acquisition Overview 4.1. Proxy Rapid Acquisition Architecture PRAMS provides proxy rapid acquisition support to an RTP receiver (RR) without requiring its participation in any rapid acquisition related signaling. The architecture for PRAMS is shown in Figure 1. Xia, et al. Expires September 9, 2010 [Page 7] Internet-Draft PRAMS March 2010 +----------------------------------------------+ | Retransmission Server (RS) | | (Feedback Target) | | (Burst/Retrans Source) | +----------------------------------------------+ ^ ^ : | ' : | ' : | ' v +-----------+ +----------+ +------------------------------------+ | | | |'''''''''''>| | | Multicast |------->| Router |...........>| Proxy Acquisition Anchor Point | | Source | | |<~~~~~~~~~~~| (Feedback Target) | | | | |----------->| | +-----------+ +----------+ +------------------------------------+ / ^ ^ \ / ~ ~ \ / ~ ^ ~ \ / ~ ' ' ~ \ / ~ ' ' ~ \ / ~ ' ' ~ \ v ~ ' ' ~ v +----------+ +----------+ | | | | | RTP | | RTP | | Receiver | | Receiver | | (RR1) | | (RR2) | +----------+ +----------+ '''> Unicast RTCP Messages ~~~> SFGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 1: Flow diagram for proxy rapid acquisition Feedback Target is defined as a logical function to which RTCP unicast feedback traffic is addressed in [RFC5760]. The Feedback Target can disjoint from the Distribution Source, perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source, in which case Feedback Target performs summarization functions and it must also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. This document reuses and extends above concepts to introducing a new function entity, the Proxy Acquisition Anchor Point, and minor extensions to the RS operation Xia, et al. Expires September 9, 2010 [Page 8] Internet-Draft PRAMS March 2010 [I-D.ietf-avt-rapid-acquisition-for-rtp]. The RTP Receiver and Multicast Source operation will not be affected. Proxy Acquisition Anchor Point can be deployed as the first hop Feedback Target to the RTP receiver(s) and has knowledge of all these RTP receivers behind it through summarizing RTCP reports. Furthermore, from RS perspective, the Proxy Acquisition Anchor Point is an RTP receiver and receives unicast format RTP packets [RFC4588] from RS. When Proxy Acquisition Anchor Point detects SFGMP messages from the RTP receiver to joining the SSM session, prior to relay the messages to upstream multicast router, the Proxy Acquisition Anchor Point firstly launches the proxy rapid acquisition signaling for achieving unicast burst defined in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Upon receiving unicast burst from RS, the Proxy Acquisition Anchor Point needs to translate the unicast burst into multicast format burst whose packet has same transport address as primary multicast packet, then forward the multicast burst to RTP receiver. The Proxy Acquisition Anchor Point needs to be able to adjust the rate of multicast burst based on the access network situation and the RTP receiver's capability. It is also worth noting that in order to avoid any overlap or gap between the end of the multicast burst and the reception of the primary multicast stream on RTP receiver, the Proxy Acquisition Anchor Point must not stop the multicast burst until the primary multicast stream arrives on its upstream interface. The RS is defined as the combined functionality of Burst Source, Retransmission Source and Distribution Source. This document reuses and extends it to support proxy rapid acquisition function. This means that the RS should be capable of distinguishing the unicast burst stream is requested by a Proxy Acquisition Anchor Point or by a RTP receiver. The RTP receiver regularly sends the periodic receiver reports to Proxy Acquisition Anchor Point, as well as receives RTCP RSI packets and adapts session parameters in the SSM session. After sending SFGMP messages, RTP receiver will receive the SSM stream with accelerated rate soon, note that the rate is limited within the RTP receiver's performance envelope. After a while the SSM stream slows down to a normal rate and keeps stable. During the whole process, RTP receiver should be unaware of the translation performance on Proxy Acquisition Anchor Point. It is possible that an operator may co-locate a Proxy Acquisition Anchor Point with a RS. In such case, how the RS transmits bursts to the Proxy Acquisition Anchor Point is an implementation issue which is outside the scope of this document. In this document, only the Xia, et al. Expires September 9, 2010 [Page 9] Internet-Draft PRAMS March 2010 split scenario where the Proxy Acquisition Anchor Point is separated from RS is taken into account. Note that the proxy rapid acquisition protocol must ensure that there is no any other significantly negative impact when providing multicast burst to the RTP receiver. However, in the case where a RTP receiver supports rapid acquisition and launches rapid acquisition signaling itself, the Proxy Acquisition Anchor Point must be transparent to the RAMS messages sent from/to the RTP receiver. 4.2. Proxy Rapid Acquisition Message Flows Figure 2 shows the signaling flow for proxy rapid qcquisition when the RTP receiver plans to join a SSM session. In Figure 2, the signaling flow is simplified without any updated messages compared to RAMS protocol. +----------------+ +----------+ +-------------+ +-----------+ | Retransmission | | | | Rapid | | RTP | | Server | | Router | | Acquisition | | Receiver | | (RS) | | | | Proxy(RAP) | | (RR) | +----------------+ +----------+ +-------------+ +-----------+ | | | | | RTP Multicast | | ----------------------------------------->|--------------->| | | | | | | | | | | |<~ SFGMP Join ~~| | | | | | | | | |<'''''''''''''RTCP Proxy RAMS-R ''| | | | | | | | | | |'' (RTCP Proxy RAMS-I)'''''''''''>| | | | | | | | | | |.. Unicast RTP Burst ............>| | | | | | | | | | | | Format Translate | | | | | | | | Multicast RTP | | | | Burst | | | |--------------->| | | | | | | SFGMP Proxy | | | | | | | | | Xia, et al. Expires September 9, 2010 [Page 10] Internet-Draft PRAMS March 2010 | |<~ SFGMP Join ~~| | | | | | | | | | | RTP Multicast | | ----------------------------------------->|--------------->| | | | | | | | | |<'''''''''''''''''' RTCP RAMS-T ''| | | | | | '''> Unicast RTCP Messages ~~~> SFGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 2: Message flows for proxy rapid acquisition 1. Upon receiving the SFGMP Join message from RTP receiver, the Proxy Acquisition Anchor Point will perform SFGMP Proxy function defined in [RFC4605], and learn about which multicast RTP session the RTP receiver intends to join. The Proxy Acquisition Anchor Point needs to create a record in membership database to maintain the membership record for each RTP receiver. The membership database is a set of membership records to set up the mapping between multicast session and downstream interface connected to each RTP receiver. The details about how the membership database work are specified in Section 4.3.1. Additionally, the Proxy Acquisition Anchor Point needs to allocate a unique set of transport addresses, i.e., they share the same IP address of upstream interface connected to RS but different ports, for the multicast session which each RTP receiver plan to join. Then the Proxy Acquisition Anchor Point also creates a record in transport address mapping database to maintain the mapping record for each multicast session. The transport address mapping database is a set of records to set up the mapping between multicast session and the list of transport addresses. The details about how the transport address mapping database work are specified in Section 4.3.2. 2. Then Proxy Acquisition Anchor Point sends a proxy rapid acquisition request message for the multicast RTP session to the RS. The request is analogous to the RAMS-R message and includes a new flag to indicate to RS that the request is sent by Proxy Xia, et al. Expires September 9, 2010 [Page 11] Internet-Draft PRAMS March 2010 Acquisition Anchor Point. Note that proxy rapid acquisition request message also contains a similar set of parameters (e.g. bandwidth limit etc.) to indicate the capability of Proxy Acquisition Anchor Point. It is worth noting that the Proxy Acquisition Anchor Point must have knowledge whether the RTP receiver support RAMS functionality prior to sending proxy rapid acquisition request message. Otherwise, the Proxy Acquisition Anchor Point may misunderstand the SFGMP message and perform redundant rapid acquisition for the RTP receiver who has already performed RAMS itself prior to sending SFGMP message. 3. Upon receiving this proxy rapid acquisition request message, the RS decides whether or not accept it and sends a proxy rapid acquisition information message, which is analogous to RAMS-I message, to RTP receiver. If RS cannot provide a rapid acquisition service, RS rejects the request and informs Proxy Acquisition Anchor Point immediately via an proxy rapid acquisition information message. If Proxy Acquisition Anchor Point receives a message indicating that its proxy rapid acquisition request has been denied, it abandons the proxy rapid acquisition attempt and MAY immediately join the multicast session by relaying the SFGMP Join message towards its upstream multicast router for the new primary multicast session. If the primary multicast session has been subscribed by Proxy Acquisition Anchor Point (i.e., other RTP receiver in proxy acquisition domain has joined the same primary multicast session), the Proxy Acquisition Anchor Point should immediatedly forward the multicase stream to its downstream interface on which the RTP receiver attaches. If RS accepts the request, it sends an proxy rapid acquisition information message to Proxy Acquisition Anchor Point that comprises fields that can be used to describe the unicast burst (e.g., the maximum bitrate and the duration of the unicast burst) transfered between RS and Proxy Acquisition Anchor Point. A particularly important field in the proxy rapid acquisition information message carries the RTP sequence number of the first packet transmitted in the retransmission session to allow Proxy Acquisition Anchor Point to detect any missing initial packet(s). When RS accepts the request, this field MUST be populated in the proxy rapid acquisition information message and it is RECOMMENDED that the proxy rapid acquisition information message is sent early enough in the session to be useful. If RS rejects the request, this field SHALL NOT exist in the proxy rapid acquisition information message. Xia, et al. Expires September 9, 2010 [Page 12] Internet-Draft PRAMS March 2010 From the RS perspective, the Proxy Acquisition Anchor Point performs RTP receiver role of the RAMS protocol. Hence, a common RS would serve for both RAMS and proxy rapid acquisition protocol simultaneously. 4. If the request is accepted, the RS starts sending the unicast RTP burst to Proxy Acquisition Anchor Point. Because RTP receiver does not support rapid acquisition functionality and has no conception about the unicast RTP burst, so the Proxy Acquisition Anchor Point needs to translate the received unicast RTP burst into an multicast format (i.e., multicast RTP burst) before forwarding it to RTP receiver. On receiving unicast burst from the RS, the Proxy Acquisition Anchor Point firstly verifies whether the destination transport address of the unicast burst can match an existing record in its transport address mapping database defined in Section 4.3.2. If there does not exist one matched record, the Proxy Acquisition Anchor Point must silently drop the burst. If there does exist one matched record, the Proxy Acquisition Anchor Point should replace the destination transport address of the unicast burst by the transport address of the mapping multicast session. It is worth noting that the source address of the burst is unchanged because the RS is the single source in SSM defined in [RFC5760]. After that, the Proxy Acquisition Anchor Point looks up the membership database and finds out the exact downstream interface as described in Section 4.3.1. If there is an existing matched downstream interface, the Proxy Acquisition Anchor Point forwards the reconstructive multicast burst to the proper RTP receiver at an appropriate bursting rate. More details are given in Section 4.3.3. 5. The time at which the Proxy Acquisition Anchor Point joins the primary multicast session and transmits the primary multicast session to the RTP receiver will varies with different use cases. If the Proxy Acquisition Anchor Point has already joined the primary multicast session on behalf of other RTP receiver attached to it, the Proxy Acquisition Anchor Point will immediately cease transmitting the multicast burst packets when the multicast RTP burst has caught up with the primary multicast stream. Beginning at that point, the Proxy Acquisition Anchor Point should transmit the primary multicast packets instead of multicast burst packets to RTP receiver at a normal rate. If the primary multicast session which RTP receiver plans to join is not subscribed by Proxy Acquisition Anchor Point at that time, the Proxy Acquisition Anchor Point should rely on the proxy rapid Xia, et al. Expires September 9, 2010 [Page 13] Internet-Draft PRAMS March 2010 acquisition information message to explicitly notify when the Proxy Acquisition Anchor Point should forward the SFGMP Join message to its upstream multicast router for the new primary multicast session. 6. After receiving the primary multicast session, the Proxy Acquisition Anchor Point should extract the sequence number of the first RTP packet received in the primary multicast session and check whether the unicast burst has already caught up with the primary multicast session. If the unicast burst from RS has already caught up with the primary multicast session (i.e., the value in Original Sequence Number (OSN) field of the RTP retransmission payload header in the latest unicast burst packet higher than the sequence number of the first RTP packet received in the primary multicast session, the Proxy Acquisition Anchor Point should initiate a proxy rapid acquisition termination message to RS to cease the burst, as well as not forward primary multicast streams to RR until the sequence number of the primary multicast packet equal to the OSN of the RTP retransmission payload header in the latest unicast burst packet. If the OSN of the RTP retransmission payload header in the latest unicast burst packet exactlly equals to the sequence number of the first RTP packet received in the primary multicast session, the Proxy Acquisition Anchor Point should only initiate a proxy rapid acquisition termination message to RS to cease the burst, as wll as seamlessly switch to primary multicast session and forward the primary multicast streams to RR immediately. Otherwise, the Proxy Acquisition Anchor Point should continue receiving burst packets until the OSN value in the latest unicast burst packes exactlly equals to the sequence number of the latest RTP packet received in the primary multicast packet. The next process is in same order as above third paragraph. 4.3. Proxy Acquisition Anchor Point Operation In Proxy Rapid Acquisition of Multicast Session, the Proxy Acquisition Anchor Point is a intermediary network entity between the RS and RTP receiver. It is responsible for performing rapid acquisition related signaling with RS on behalf of the RTP receiver in its Proxy Acquisition Domain. Additionally, the Proxy Acquisition Anchor Point performs as SFGMP proxy device and listens for SFGMP messages sent from RTP receivers on its downstream interfaces. All SFGMP messages received on its Xia, et al. Expires September 9, 2010 [Page 14] Internet-Draft PRAMS March 2010 downstream interfaces MUST be properly processed by the Proxy Acquisition Anchor Point and the necessary database to record the mapping relationship between multicast session and RTP receiver also need to be taken into account. The more details are described in Section 4.3.1. In particular, the Proxy Acquisition Anchor Point receives unicast RTP burst from RS and translates the unicast RTP burst into multicast format RTP burst . The more translation details are described in Section 4.3.2. In order to avoid the buffer overflow on the path between Proxy Acquisition Anchor Point and RTP receiver and at RTP receiver itself, Proxy Acquisition Anchor Point must limit the multicast burst rate within the capability of RTP receiver. The more forwarding details are described in Section 4.3.3. When packet loss occurs during the burst between Proxy Acquisition Anchor Point and RS, the Proxy Acquisition Anchor Point must create its own RTCP feedback message to requesting retransmissions of the missing packets from RS. Proxy Acquisition Anchor Point acts as a regular Feedback Target in the vicinity of RTP receiver, so it has the duty to detecting any RTCP NACK message indicating packet loss on the path from Proxy Acquisition Anchor Point to RTP receiver. In such case, the Proxy Acquisition Anchor Point should perform conventional retransmission for RTP receiver. The more details are described in Section 4.3.3. 4.3.1. Membership Database Proxy Acquisition Anchor Point performs router portion of the SFGMP protocol, handles SFGMP subscription from RTP receiver on its each downstream interface and maintains a record for each downstream interface. In SSM session, the address of Distribution Source is explicitly indicated as specific source for the multicast group, as well as the filter mode must be set as inclusion mode. Therefore, only multicast group is the variable item needed to be maintained in a record of membership database associated with a specific RTP receiver. The membership database is a set of membership records of the form: (multicast group address, downstream interface to RTP receiver) Note that the membership database need to be immediately updated once the RTP receiver switches from one multicast session to another one. Xia, et al. Expires September 9, 2010 [Page 15] Internet-Draft PRAMS March 2010 4.3.2. Transport Address Mapping Database Before sending proxy rapid acquisition request message, Proxy Acquisition Anchor Point must firstly allocate a unique set of ports, P, for the multicast session which the RTP receiver plans to join. The multicast session can carry multiple multicast RTP sessions, m. In such case each multicast RTP session will be allocated a couple of ports for RTP and RTCP. The total available ports for each RTP receiver (in the SSM session) P = m*2. Note that if Proxy Acquisition Anchor Point implements RTP/RTCP port muxing [I-D.ietf-avt-rtp-and-rtcp-mux], only one port is enough for each multicast RTP session and the total available ports for each receiver P = m. At this time, Proxy Acquisition Anchor Point creats a record in its transport address mapping database to maintain the mapping for port(s) and multicast RTP session. The transport address mapping database is a set of membership records of the form: (RTP port, RTCP port, multicast group address) 4.3.3. Forwarding Packets Upon receiving the unicast burst whose destination address is Proxy Acquisition Anchor Point upstream interface's address, the Proxy Acquisition Anchor Point first lookups its transport address mapping database to verify whether the destination port matches an existing record. If there exist a matched record, the Proxy Acquisition Anchor Point will replace the destination transport address of the unicast burst by the transport address of the mapping multicast RTP session and forward the reconstructive multicast burst to its appropriate downstream interface based on membership database. When RTP receiver receives multicast burst at an accelerated rate compared to normal multicast stream, the Proxy Acquisition Anchor Point must guarantee the accelerated rate stays within the capability that RTP receiver can handle. However the RTP receiver is non- updated to support rapid acquisition, so it can not negotiate its capability with Proxy Acquisition Anchor Point, such as the buffer and bandwidth limits. It is up to Proxy Acquisition Anchor Point to estimate an amplification coefficient for each specific RTP receiver. For example, the accelerated rate may be normal primary multicast rate * 1.3 for the RTP receiver on ADSL link. Note that the accelerated rate should be value within the range normal rate < accelerated rate <= unicast burst rate. That demands Proxy Acquisition Anchor Point must has enough buffer to continuously cache the packets from RS. If packet loss occurs on the RTP receiver, Proxy Acquisition Anchor Xia, et al. Expires September 9, 2010 [Page 16] Internet-Draft PRAMS March 2010 Point must reduce the raw accelerated rate. In the meanwhile, Proxy Acquisition Anchor Point initiates its own RTCP NACK message to RS on behalf RTP receiver. 4.4. Retransmission Server Operation The RS MUST keep the RMAS related function as defined in [I-D.ietf-avt-rapid-acquisition-for-rtp] and support additional extensions defined in this document. Proxy Acquisition Anchor Point can request different multicast session on behalf of different RTP receivers simultaneously. Whereas a RAMS capable RTP receiver can only request one multicast session at a certain time, the request for a new multicast session means that RTP receiver switches from former multicast session to another one. From the above analysis, the RS MUST distinguish the request message is sent from a proy or a real RTP receiver. This can be done by checking whether the 'P' flag is set to value of 1 in rapid acquisition request message, format specified in Section 5.1. 4.5. RTP Receiver Operation When a RTP receiver attaches to an access network managed by Proxy Acquisition Anchor Point, the RTP receiver can avoid significant acquisition delay when joining a new multicast session, even if the RTP receiver lacks of supporting any rapid acquisition related functionality. So the support of rapid acquisition is completely transparent to the RTP receiver''s operation. RTP receiver only gets multicast streams from Proxy Acquisition Anchor Point at an accelerated or a normal rate. 5. Signaling Extensions This section outlines the extensions proposed to the feedback messages specified in [RFC4585]. These signaling extensions also refer RAMS messages specified in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 5.1. Proxy Rapid Acquisition Request Xia, et al. Expires September 9, 2010 [Page 17] Internet-Draft PRAMS March 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFMT=1 |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional TLV-encoded Fields (and Padding, if needed) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FCI field syntax for the RAMS Request message A Proxy Rapid Acquisition message that is sent by a Proxy Acquisition Anchor Point to a RS is referred to as the "Proxy Rapid Acquisition Request" message. A new flag (P) is included in the Proxy Rapid Acquisition Request message. The rest of the Proxy Rapid Acquisition Request message format remains the same as defined in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Proxy Rapid Acquisition Flag (P) A new flag (P) is included in the Proxy Rapid Acquisition Request message to indicate to the RS that the Rapid Acquisition Request message is a proxy rapid acquisition. The flag MUST be set to the value of 1 for proxy rapid acquisition and MUST be set to 0 for direct rapid acquisition sent by a RTP receiver. 6. SDP Extensions The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585] and a new syntax 'ssli' is added into the 'rtcp-fb' attribute in [I-D.ietf-avt-rapid-acquisition-for-rtp]to the use of RAMS messages. In this document, new SDP parameters are needed by the proposed mechanisms (and that also need to be registered with IANA). 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 "psli" The following parameter is defined in this document for use with 'nack': 'psli' stands for Proxy Synchronization Loss Indication and indicates the use of proxy rapid acquisition messages on the Proxy Acquisition Anchor Point. Xia, et al. Expires September 9, 2010 [Page 18] Internet-Draft PRAMS March 2010 6.1. Examples This section provides a declarative SDP [RFC4566] example for enabling proxy rapid acquisition of multicast RTP sessions. In this example, we refer the similar SDP parameters defined in [I-D.ietf-avt-rapid-acquisition-for-rtp]and [RFC5760]. The multicast source stream from Distribution Source (with a source IP address of 192.0.2.2) to the multicast destination address of 233.252.0.2 and port 41000. A RS including feedback target functionality (with an address of 192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute. a Proxy Acquisition Anchor Point receives multicast source stream and unicast burst stream on its upstream interface (with an address of 192.0.2.3, rtp port 41002 and rtcp port 41003). Xia, et al. Expires September 9, 2010 [Page 19] Internet-Draft PRAMS March 2010 v=0 o=alice 3203093520 3203093520 IN IP4 prams.example.com s=Proxy Rapid Acquisition Multicast Example t=0 0 a=group:FID 1 2 3 a=rtcp-unicast:rsi m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream c=IN IP4 233.252.0.2/255 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=recvonly a=rtpmap:98 MP4V-ES/90000 a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp-fb:98 nack a=rtcp-fb:98 nack psli a=ssrc:314159 cname:user@prams.example.com a=mid:1 m=video 41002 RTP/AVPF 99 i=Unicast Rapid Acq Stream (upstream interface) c=IN IP4 192.0.2.1 a=recvonly a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98; rtx-time=5000 a=mid:2 m=video 41000 RTP/AVPF 100 i=Multicast Stream (downstream interface) c=IN IP4 233.252.0.2/255 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=sendonly a=rtpmap:100 MP4V-ES/90000 a=rtcp:41001 IN IP4 192.0.2.3 a=rtcp-fb:100 nack a=ssrc:314159 cname:user@prams.example.com a=mid:3 Figure 4: Example SDP for Proxy Acquisition Anchor Point Xia, et al. Expires September 9, 2010 [Page 20] Internet-Draft PRAMS March 2010 v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=Rapid Acquisition Example t=0 0 a=group:FID 1 2 a=rtcp-unicast:rsi m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream c=IN IP4 233.252.0.2/255 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=recvonly a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack psli a=ssrc:123321 cname:iptv-ch32@rams.example.com a=rams-updates a=mid:1 m=video 41002 RTP/AVPF 99 i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 a=sendonly a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98; rtx-time=5000 a=mid:2 Figure 5: Example SDP for Retransmission Server v=0 o=alice 3203093520 3203093520 IN IP4 prams.example.com s=Proxy Rapid Acquisition Multicast Example t=0 0 a=rtcp-unicast:rsi m=video 41000 RTP/AVPF 100 i=Primary Multicast Stream c=IN IP4 233.252.0.2/255 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=recvonly a=rtpmap:100 MP4V-ES/90000 a=rtcp:41001 IN IP4 192.0.2.3 a=rtcp-fb:100 nack a=ssrc:314159 cname:user@prams.example.com Figure 6: Example SDP for RTP Receiver Xia, et al. Expires September 9, 2010 [Page 21] Internet-Draft PRAMS March 2010 7. IANA considerations TBD 8. Security Considerations Applications that are using PRAMS are analogous to the applications that are using RAMS described in the [I-D.ietf-avt-rapid-acquisition-for-rtp]. Thus, these applications are subject to the general security considerations discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. The additional security weaknesses introduced by PRAMS needs to be taken into account and a higher level of protection must be adopted. First of all, after attaching to access network with Proxy Acquisition Anchor Point support, the RTP receiver will send SFGMP join message to its upstream router. a Proxy Acquisition Anchor Point residing between the RTP receiver and its upstream router will intercept this message. Counter-measures SHOULD be taken to prevent tampered or spoofed SFGMP join messages between the Proxy Acquisition Anchor Point and RTP receiver. The integrity and authenticity mechanism can be used to prevent this security weakness. When the Proxy Acquisition Anchor Point performs Rapid acquisition on behalf of all the RTP receivers, PRAMS operation for each RTP receiver may consume a lot of resources on RAP. A series of PRAMS messages encapsulation and processing may sometimes overload the RAP. On the other hand, the Proxy Acquisition Anchor Point needs to buffer SFGMP message and establish membership database before PRAMS operation completes. Upon receiving the unicast burst packet, the Proxy Acquisition Anchor Point needs to translate unicast burst packets into multicast format packets. These operations also consume a certain resources. Therefore, the Proxy Acquisition Anchor Point may for example discard messages until its resources become available again. Since the Proxy Acquisition Anchor Point may be impersonated by a malicious node, counter measures should be taken to prevent man in middle attack and replay attack brought by RAP. For example, the channel binding mechanism described in [RFC5056] may be used to avoid a rogue intermediary node providing unverified and conflicting service information to each of the RTP receiver and the Authorization server. Xia, et al. Expires September 9, 2010 [Page 22] Internet-Draft PRAMS March 2010 9. Acknowledgments TBD 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [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. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. [I-D.ietf-avt-rapid-acquisition-for-rtp] Steeg, B. and Begen, A., "Unicast- Based Rapid Acquisition of Multicast RTP Sessions", draft-ietf-avt-rapid-acquisition-for-rtp-07 (work in progress), October 2009. [I-D.ietf-avt-rtp-and-rtcp-mux] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), Xia, et al. Expires September 9, 2010 [Page 23] Internet-Draft PRAMS March 2010 August 2007. [I-D.draft-johansson-avt-mcast-based-rams] Johansson, I., "Multicast-Based Rapid Acquisition of Multicast RTP Sessions", draft-johansson-avt-mcast-based-rams-00 (work in progress), April 2009. [I-D.draft-wang-avt-rtp-improved-rams] Wang, Y., "Improved Rapid Acquisition of Multicast Sessions", draft-wang-avt-rtp-improved-rams-01 (work in progress), October 2009. [IEEE-802.1Q] "Draft Standard for Virtual Bridged Local Area Networks P802.1Q-2003", IEEE Standards for Local and Metropolitan Area Networks , January 2003. Authors' Addresses Jinwei Xia Huawei Technologies Co.,Ltd Hui Hong Mansion Nanjing, Baixia District 210001 China Phone: +86-025-84565890 Email: xiajinwei@huawei.com Qin Wu Huawei Technologies Co.,Ltd Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd. Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: Sunseawq@huawei.com Xia, et al. Expires September 9, 2010 [Page 24] Internet-Draft PRAMS March 2010 Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Email: asaeda@wide.ad.jp URI: http://www.sfc.wide.ad.jp/~asaeda/ Xia, et al. Expires September 9, 2010 [Page 25]