AVT Working Group J. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: April 22, 2010 H. Asaeda Keio University October 19, 2009 Network-based Rapid Acquisition of Multicast RTP Sessions draft-xia-avt-proxy-rapid-acquisition-00 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 April 22, 2010. Copyright Notice 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 This document describes a network-based rapid acquisition mechanism Xia, et al. Expires April 22, 2010 [Page 1] Internet-Draft PRAMS October 2009 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 specified in [RFC4605] from the RTP receiver and launching the required rapid acquisition signaling instead of the RTP receiver. This network-based rapid acquisition of multicast RTP session in this document is referred to as Proxy Rapid Acquisition of Multicast Sessions (PRAMS). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proxy Rapid Acquisition Motivation . . . . . . . . . . . . . . 4 4. Proxy Rapid Acquisition Overview . . . . . . . . . . . . . . . 5 4.1. Proxy Rapid Acquisition Architecture . . . . . . . . . . . 5 4.2. Proxy Rapid Acquisition Message Flows . . . . . . . . . . 7 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Xia, et al. Expires April 22, 2010 [Page 2] Internet-Draft PRAMS October 2009 1. Introduction The AVT working group has recently been working on specifying extensions to the unicast feedback for SSM sessions [I-D.ietf-avt-rtcpssm]. 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. In order to reduce the acquisition time, these extensions 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. However, this requirement may lead its deployment difficulties. This document proposes a network-based 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 retransmission server and an RTP receiver. In order for this to work, a proxy acquisition function is introduced in the access network, and performs the rapid acquisition related signaling with a retransmission server on behalf of the RTP receiver attached to the access network managed by the proxy acquisition function. Therefore, this protocol is called Proxy Rapid Acquisition of Multicast Sessions (PRAMS). The document is organized as follows: in section 3, we describe the motivation to extend Rapid Acquisition of Multicast RTP Sessions, in section 4, we present an overview of the protocol design. 2. Terminology The keywords "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]. All terms in this document are defined in [RFC4585], [I-D.ietf-avt-rtcpssm], [I-D.ietf-avt-rapid-acquisition-for-rtp] and [RFC4605]. In addition or in replacement of these, the following terms are defined or redefined: Access Network An access network is a collection of fixed or mobile network components allowing access to the Internet all belonging to a single operational domain. It may consist of multiple wire or Xia, et al. Expires April 22, 2010 [Page 3] Internet-Draft PRAMS October 2009 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.). Rapid Acquisition Proxy (RAP) The Rapid Acquisition Proxy functions is an aggregation switch that manages the rapid acquisition related signaling for RTP receivers attached to its access network. It is responsible for receiving the RTP receivers' SFGMP Join/Leave messages and performing rapid acquisition related signaling with the retransmission server (RS). In this document, the Rapid Acquisition Proxy MUST support the SFGMP Proxy functionality specified in [RFC4605]. RTP Receiver (RR) Throughout this document, the term "RTP Receiver" referes to the entity whose rapid acquisition related functionality is managed by the network. As a result, the RTP Receiver is not required to participate in any rapid acquisition related signaling for achieving Rapid Acquisition of Multicast RTP Sessions in the access network managed by the RAP. 3. Proxy Rapid Acquisition Motivation All current rapid acquisition methods utilize an auxiliary high- bitrate unicast or multicast burst triggered by the RR to reduce the acquisition time. The common characteristic of these methods is that software update, system resource allocation or hardware modification are required on RR 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 RRs 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, RR needs to frequently acquire the network state information frequently because it varies over time. Furthermore, the RR needs to inform Xia, et al. Expires April 22, 2010 [Page 4] Internet-Draft PRAMS October 2009 the retransmission server about the bandwidth and/or bitrate that the RR can handle. In such case, extra complexity is introduced on RR to handle these fuctions. 3. The rapid acquisition signalling messages will consume radio resources and the RR's power when RR 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. The problems listed above can be addressed naturally by Proxy Rapid Acquisition of Multicast Sessions (PRAMS). PRAMS does not raise any serious backward compatibility issue. For RR that does not understand the rapid acquisition, the RAP must prevent any rapid acquisition related signaling from RR. On the contrary, for a rapid acquisiton capable RR, the RAP must be transparent to RAMS messages from/to the RR without any interference. So PRAMS can be used with any legacy RR or with an enhanced RR with existing rapid acquisition functionality support. PRAMS is a robust rapid acquisition management architecture that can accommodate with multifarious technologies and requirements. The above observations, justify the development of the PRAMS protocol as an efficient alternative to RAMS. The details of how a RAP performs rapid acquisition on behalf of the RR are described in the following sections. 4. Proxy Rapid Acquisition Overview 4.1. Proxy Rapid Acquisition Architecture PRAMS provides network-based 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 April 22, 2010 [Page 5] Internet-Draft PRAMS October 2009 +----------------------------------------------+ | Retransmission Server | | (RS) | +----------------------------------------------+ ^ ^ : | ' : | ' : | ' v +-----------+ +----------+ +----------+ | | | |'''''''''''>| | | Multicast |------->| Router |...........>| RAP | | Source | | |<~~~~~~~~~~~| | | | | |----------->| | +-----------+ +----------+ +----------+ / ^ ^ \ / ~ ~ \ / ~ ~ \ / ~ ~ \ / ~ ~ \ / ~ ~ \ v ~ ~ v +----------+ +----------+ | | | | | RTP | | RTP | | Receiver | | Receiver | | (RR1) | | (RR2) | +----------+ +----------+ '''> Unicast RTCP Messages ~~~> SFGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 1: Flow diagram for network-based rapid acquisition The core functional entity in the PRAMS infrastructure is the Rapid Acquisition Proxy (RAP). The RAP is the entity that performs the rapid acquisition related signaling on behalf of a RR and resides in the access network to which the RR attaches. The RAP is responsible for detecting SFGMP messages [RFC4605] from the RTP receiver and launching the required rapid acquisition signaling on behalf of RR. Furthermore, upon receiving unicast burst from RS, the RAP MUST translate the unicast burst into RR understandable multicast format. In this sense, RR is not directly involved in any rapid acquisition related operation. The Retransmission Server (RS) is defined as the combined functionality of the Feedback Target, Burst Source and Retransmission Xia, et al. Expires April 22, 2010 [Page 6] Internet-Draft PRAMS October 2009 Source specified in [I-D.ietf-avt-rapid-acquisition-for-rtp] and in [I-D.ietf-avt-rtcpssm]. It is possible that an operator may collocate a Rapid Acquisition Proxy (RAP) is co-located with a Retransmission Server (RS). In such case, how the RS transmits bursts to the RAP is an implementation issue which is outside the scope of this document. In this document, only the split scenario where the Rapid Acquisition Proxy (RAP) is separated from Retransmission Server (RS) is taken into account. Note that, the PRAMS protocol must ensure that no latency remains tolerable and there is no and other significantly negative impact when providing a burst to the RR. However, in the case where a RR supports rapid acquisition and launches rapid acquisition signaling itself, the RAP should be transparent to the RAMS messages sent from/to the RR. 4.2. Proxy Rapid Acquisition Message Flows Figure 2 shows the signaling flow for Proxy Rapid Acquisition of Multicast Sessions (PRAMS). +----------------+ +----------+ +-------------+ +-----------+ | 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 Transfer | | | | | | | | Multicast RTP | | | | Burst | Xia, et al. Expires April 22, 2010 [Page 7] Internet-Draft PRAMS October 2009 | | |--------------->| | | | | | | SFGMP Proxy | | | | | | | | | | |<~ SFGMP Join ~~| | | | | | | | | | | RTP Multicast | | ----------------------------------------->|--------------->| | | | | | | | | |<'''''''''''''''''' RTCP RAMS-T ''| | | | | | '''> Unicast RTCP Messages ~~~> SFGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 2: Message flows for network-based rapid acquisition 1. Upon receiving the SFGMP Join message from RR, the RAP must support SFGMP Proxy function defined in [RFC4605], and learn about which multicast RTP session the RR intends to join. Additionally, the RAP creates a record in membership database to maintain the membership record of each RR. The membership database is a set of membership records to set up the mapping between multicast session and downstream interface connected to each RR. The details about how the membership database work are specified in [RFC4605]. 2. Then RAP sends a proxy rapid acquisition request message for the multicast RTP session to the Retransmission Server (RS) address of that session. The request is analogous to the RAMS-R message and contains a similar set of parameters (e.g. bandwidth limit etc.) . The specific details on how the RAP obtains these parameters is outside the scope of this document. 3. Upon accepting this proxy rapid acquisition request message, the RS sends a proxy rapid acquisition information message, which is analogous to RAMS-I message and also contains information to describe the unicast burst. From the RS perspective, the RAP performs RR role of the RAMS protocol. Hence, a common RS would serve for both RAMS and PRAMS protocols simultaneously. Xia, et al. Expires April 22, 2010 [Page 8] Internet-Draft PRAMS October 2009 4. If the request is accepted, the RS starts sending the unicast RTP burst to RAP. In order to avoid RR involving in rapid acquisition related operation, the RAP MUST translate the received unicast RTP burst into an RR-understandable multicast format (i.e. multicast RTP burst in Figure 2). 5. The time at which the RAP joins the primary multicast session and transmits the primary multicast session to the RR will varies with different use cases. If the RAP has already joined the primary multicast session on behalf of other RTP receivers attached to it, the RAP will immediately cease transmitting the multicast burst packets after the multicast RTP burst has caught up with the primary multicast stream. Beginning at that point, the RAP transmits the primary multicast packets instead of multicast burst packets to RR. On the other hand, if the RR is the first one to join the primary multicast session, the RAP should adopt a similar mechanism to that described in [I-D.ietf-avt-rapid-acquisition-for-rtp], and rely on the RS to explicitly notify when RAP 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 RAP immediately sends a proxy rapid acquisition termination message to the RS to stop the unicast burst. This termination message is analogous to the RAMS-T message and also contains the sequence number of the first RTP packet received in the primary multicast session. 5. IANA considerations TBD 6. 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 RAP support, the RR will send SFGMP join message to its upstream router. a RAP Xia, et al. Expires April 22, 2010 [Page 9] Internet-Draft PRAMS October 2009 residing between the RR and its upstream router will intercept this message. Counter-measures SHOULD be taken to prevent tampered or spoofed SFGMP join messages between the RAP and RR. The integrity and authenticity mechanism can be used to prevent this security weakness. When the RAP performs Rapid acquisition on behalf of all the RRs, PRAMS operation for each RR 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 RAP needs to buffer SFGMP message and establish membership database before PRAMS operation completes. Upon receiving the unicast burst packet, the RAP needs to translate unicast burst packets into multicast format packets. These operations also consume a certain resources. Therefore, the RAP may for example discard messages until its resources become available again. Since the RAP 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 RR and the Authorization server. 7. Acknowledgments TBD 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Xia, et al. Expires April 22, 2010 [Page 10] Internet-Draft PRAMS October 2009 [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. [I-D.ietf-avt-rtcpssm] Schooler, R., Ott, J., and J. Chesterfield, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-18.txt (work in progress), March 2009. [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-04 (work in progress), October 2009. [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. [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 Xia, et al. Expires April 22, 2010 [Page 11] Internet-Draft PRAMS October 2009 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 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 April 22, 2010 [Page 12]