[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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",
   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,

   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

   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

5.  IANA considerations


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

   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

   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


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.

              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.

              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.

              Johansson, I., "Multicast-Based Rapid Acquisition of
              Multicast RTP Sessions",
              draft-johansson-avt-mcast-based-rams-00 (work in
              progress), April 2009.

              "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

   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

   Phone: +86-25-84565892
   Email: Sunseawq@huawei.com

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-8520

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/

Xia, et al.              Expires April 22, 2010                [Page 12]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/