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]