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

Versions: 00 01

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]


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