One document matched: draft-xia-avt-proxy-rapid-acquisition-00.txt
AVT Working Group J. Xia
Internet-Draft Q. Wu
Intended status: Standards Track Huawei
Expires: April 22, 2010 H. Asaeda
Keio University
October 19, 2009
Network-based Rapid Acquisition of Multicast RTP Sessions
draft-xia-avt-proxy-rapid-acquisition-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a network-based rapid acquisition mechanism
Xia, et al. Expires April 22, 2010 [Page 1]
Internet-Draft PRAMS October 2009
which reduces acquisition delay for an RTP receiver without
supporting any rapid acquisition related functionality. The network
is responsible for managing rapid acquisition on behalf of the RTP
receiver, including detecting SFGMP message specified in [RFC4605]
from the RTP receiver and launching the required rapid acquisition
signaling instead of the RTP receiver. This network-based rapid
acquisition of multicast RTP session in this document is referred to
as Proxy Rapid Acquisition of Multicast Sessions (PRAMS).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proxy Rapid Acquisition Motivation . . . . . . . . . . . . . . 4
4. Proxy Rapid Acquisition Overview . . . . . . . . . . . . . . . 5
4.1. Proxy Rapid Acquisition Architecture . . . . . . . . . . . 5
4.2. Proxy Rapid Acquisition Message Flows . . . . . . . . . . 7
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Xia, et al. Expires April 22, 2010 [Page 2]
Internet-Draft PRAMS October 2009
1. Introduction
The AVT working group has recently been working on specifying
extensions to the unicast feedback for SSM sessions
[I-D.ietf-avt-rtcpssm]. There is a large amount of interest from the
IETF community in extending the protocol to support some real,
practical and immediate use-cases for rapid acquisition. In order to
reduce the acquisition time, these extensions primarily require the
RTP receiver to support rapid acquisition related functionality,
including the ability to solicit or terminate the burst and provide
required parameters to the network. These extensions will be
implemented by receiver's software, and maybe hardware, to
accommodate the requirement. However, this requirement may lead its
deployment difficulties.
This document proposes a network-based rapid acquisition approach
without RTP receiver involvement by extending RTCP Rapid Acquisition
[I-D.ietf-avt-rapid-acquisition-for-rtp] . This approach does not
require the RTP receiver to be involved in the exchange of signaling
messages between a retransmission server and an RTP receiver. In
order for this to work, a proxy acquisition function is introduced in
the access network, and performs the rapid acquisition related
signaling with a retransmission server on behalf of the RTP receiver
attached to the access network managed by the proxy acquisition
function. Therefore, this protocol is called Proxy Rapid Acquisition
of Multicast Sessions (PRAMS).
The document is organized as follows: in section 3, we describe the
motivation to extend Rapid Acquisition of Multicast RTP Sessions, in
section 4, we present an overview of the protocol design.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All terms in this document are defined in [RFC4585],
[I-D.ietf-avt-rtcpssm], [I-D.ietf-avt-rapid-acquisition-for-rtp] and
[RFC4605]. In addition or in replacement of these, the following
terms are defined or redefined:
Access Network
An access network is a collection of fixed or mobile network
components allowing access to the Internet all belonging to a
single operational domain. It may consist of multiple wire or
Xia, et al. Expires April 22, 2010 [Page 3]
Internet-Draft PRAMS October 2009
wireless interface technologies (e.g. XDSL, MSTP, 802.16e,
Universal Mobile Telecommunications System (UMTS), etc.)
interconnected with multiple types of backhaul interconnections
(such as Synchronous Optical Network (SONET), Metro Ethernet,
etc.).
Rapid Acquisition Proxy (RAP)
The Rapid Acquisition Proxy functions is an aggregation switch
that manages the rapid acquisition related signaling for RTP
receivers attached to its access network. It is responsible for
receiving the RTP receivers' SFGMP Join/Leave messages and
performing rapid acquisition related signaling with the
retransmission server (RS). In this document, the Rapid
Acquisition Proxy MUST support the SFGMP Proxy functionality
specified in [RFC4605].
RTP Receiver (RR)
Throughout this document, the term "RTP Receiver" referes to the
entity whose rapid acquisition related functionality is managed by
the network. As a result, the RTP Receiver is not required to
participate in any rapid acquisition related signaling for
achieving Rapid Acquisition of Multicast RTP Sessions in the
access network managed by the RAP.
3. Proxy Rapid Acquisition Motivation
All current rapid acquisition methods utilize an auxiliary high-
bitrate unicast or multicast burst triggered by the RR to reduce the
acquisition time. The common characteristic of these methods is that
software update, system resource allocation or hardware modification
are required on RR to support rapid acquisition related
functionality. This limits broad usage even if the updates are
small. The followings are the specific issues that should be taken
into account:
1. A large number of the RRs lacking rapid acquisition capability
have been largely deployed. It is required lots of efforts for
each vendor to adopt rapid acquisition on all variants of
Windows, Android, iPhone, Linux and BSD systems. Additionally,
it will be impossible to support older models for which support
has been discontinued.
2. To avoid congestion possibility on the access network, RR needs
to frequently acquire the network state information frequently
because it varies over time. Furthermore, the RR needs to inform
Xia, et al. Expires April 22, 2010 [Page 4]
Internet-Draft PRAMS October 2009
the retransmission server about the bandwidth and/or bitrate that
the RR can handle. In such case, extra complexity is introduced
on RR to handle these fuctions.
3. The rapid acquisition signalling messages will consume radio
resources and the RR's power when RR is a mobile terminal. The
situation becomes worse in the case where all rapid acquisition
messages are sent multiple times against the possibility of
message loss.
The problems listed above can be addressed naturally by Proxy Rapid
Acquisition of Multicast Sessions (PRAMS). PRAMS does not raise any
serious backward compatibility issue. For RR that does not
understand the rapid acquisition, the RAP must prevent any rapid
acquisition related signaling from RR. On the contrary, for a rapid
acquisiton capable RR, the RAP must be transparent to RAMS messages
from/to the RR without any interference. So PRAMS can be used with
any legacy RR or with an enhanced RR with existing rapid acquisition
functionality support. PRAMS is a robust rapid acquisition
management architecture that can accommodate with multifarious
technologies and requirements.
The above observations, justify the development of the PRAMS protocol
as an efficient alternative to RAMS. The details of how a RAP
performs rapid acquisition on behalf of the RR are described in the
following sections.
4. Proxy Rapid Acquisition Overview
4.1. Proxy Rapid Acquisition Architecture
PRAMS provides network-based rapid acquisition support to an RTP
receiver (RR) without requiring its participation in any rapid
acquisition related signaling. The architecture for PRAMS is shown
in Figure 1.
Xia, et al. Expires April 22, 2010 [Page 5]
Internet-Draft PRAMS October 2009
+----------------------------------------------+
| Retransmission Server |
| (RS) |
+----------------------------------------------+
^ ^ :
| ' :
| ' :
| ' v
+-----------+ +----------+ +----------+
| | | |'''''''''''>| |
| Multicast |------->| Router |...........>| RAP |
| Source | | |<~~~~~~~~~~~| |
| | | |----------->| |
+-----------+ +----------+ +----------+
/ ^ ^ \
/ ~ ~ \
/ ~ ~ \
/ ~ ~ \
/ ~ ~ \
/ ~ ~ \
v ~ ~ v
+----------+ +----------+
| | | |
| RTP | | RTP |
| Receiver | | Receiver |
| (RR1) | | (RR2) |
+----------+ +----------+
'''> Unicast RTCP Messages
~~~> SFGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 1: Flow diagram for network-based rapid acquisition
The core functional entity in the PRAMS infrastructure is the Rapid
Acquisition Proxy (RAP). The RAP is the entity that performs the
rapid acquisition related signaling on behalf of a RR and resides in
the access network to which the RR attaches. The RAP is responsible
for detecting SFGMP messages [RFC4605] from the RTP receiver and
launching the required rapid acquisition signaling on behalf of RR.
Furthermore, upon receiving unicast burst from RS, the RAP MUST
translate the unicast burst into RR understandable multicast format.
In this sense, RR is not directly involved in any rapid acquisition
related operation.
The Retransmission Server (RS) is defined as the combined
functionality of the Feedback Target, Burst Source and Retransmission
Xia, et al. Expires April 22, 2010 [Page 6]
Internet-Draft PRAMS October 2009
Source specified in [I-D.ietf-avt-rapid-acquisition-for-rtp] and in
[I-D.ietf-avt-rtcpssm].
It is possible that an operator may collocate a Rapid Acquisition
Proxy (RAP) is co-located with a Retransmission Server (RS). In such
case, how the RS transmits bursts to the RAP is an implementation
issue which is outside the scope of this document. In this document,
only the split scenario where the Rapid Acquisition Proxy (RAP) is
separated from Retransmission Server (RS) is taken into account.
Note that, the PRAMS protocol must ensure that no latency remains
tolerable and there is no and other significantly negative impact
when providing a burst to the RR. However, in the case where a RR
supports rapid acquisition and launches rapid acquisition signaling
itself, the RAP should be transparent to the RAMS messages sent
from/to the RR.
4.2. Proxy Rapid Acquisition Message Flows
Figure 2 shows the signaling flow for Proxy Rapid Acquisition of
Multicast Sessions (PRAMS).
+----------------+ +----------+ +-------------+ +-----------+
| Retransmission | | | | Rapid | | RTP |
| Server | | Router | | Acquisition | | Receiver |
| (RS) | | | | Proxy(RAP) | | (RR) |
+----------------+ +----------+ +-------------+ +-----------+
| | | |
| RTP Multicast | |
----------------------------------------->|--------------->|
| | | |
| | | |
| | |<~ SFGMP Join ~~|
| | | |
| | | |
|<'''''''''''''RTCP Proxy RAMS-R ''| |
| | | |
| | | |
|'' (RTCP Proxy RAMS-I)'''''''''''>| |
| | | |
| | | |
|.. Unicast RTP Burst ............>| |
| | | |
| | | |
| | Format Transfer |
| | | |
| | | Multicast RTP |
| | | Burst |
Xia, et al. Expires April 22, 2010 [Page 7]
Internet-Draft PRAMS October 2009
| | |--------------->|
| | | |
| | SFGMP Proxy |
| | | |
| | | |
| |<~ SFGMP Join ~~| |
| | | |
| | | |
| RTP Multicast | |
----------------------------------------->|--------------->|
| | | |
| | | |
|<'''''''''''''''''' RTCP RAMS-T ''| |
| | | |
'''> Unicast RTCP Messages
~~~> SFGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 2: Message flows for network-based rapid acquisition
1. Upon receiving the SFGMP Join message from RR, the RAP must
support SFGMP Proxy function defined in [RFC4605], and learn
about which multicast RTP session the RR intends to join.
Additionally, the RAP creates a record in membership database to
maintain the membership record of each RR. The membership
database is a set of membership records to set up the mapping
between multicast session and downstream interface connected to
each RR. The details about how the membership database work are
specified in [RFC4605].
2. Then RAP sends a proxy rapid acquisition request message for the
multicast RTP session to the Retransmission Server (RS) address
of that session. The request is analogous to the RAMS-R message
and contains a similar set of parameters (e.g. bandwidth limit
etc.) . The specific details on how the RAP obtains these
parameters is outside the scope of this document.
3. Upon accepting this proxy rapid acquisition request message, the
RS sends a proxy rapid acquisition information message, which is
analogous to RAMS-I message and also contains information to
describe the unicast burst. From the RS perspective, the RAP
performs RR role of the RAMS protocol. Hence, a common RS would
serve for both RAMS and PRAMS protocols simultaneously.
Xia, et al. Expires April 22, 2010 [Page 8]
Internet-Draft PRAMS October 2009
4. If the request is accepted, the RS starts sending the unicast RTP
burst to RAP. In order to avoid RR involving in rapid
acquisition related operation, the RAP MUST translate the
received unicast RTP burst into an RR-understandable multicast
format (i.e. multicast RTP burst in Figure 2).
5. The time at which the RAP joins the primary multicast session and
transmits the primary multicast session to the RR will varies
with different use cases. If the RAP has already joined the
primary multicast session on behalf of other RTP receivers
attached to it, the RAP will immediately cease transmitting the
multicast burst packets after the multicast RTP burst has caught
up with the primary multicast stream. Beginning at that point,
the RAP transmits the primary multicast packets instead of
multicast burst packets to RR.
On the other hand, if the RR is the first one to join the primary
multicast session, the RAP should adopt a similar mechanism to
that described in [I-D.ietf-avt-rapid-acquisition-for-rtp], and
rely on the RS to explicitly notify when RAP should forward the
SFGMP Join message to its upstream multicast router for the new
primary multicast session.
6. After receiving the primary multicast session, the RAP
immediately sends a proxy rapid acquisition termination message
to the RS to stop the unicast burst. This termination message is
analogous to the RAMS-T message and also contains the sequence
number of the first RTP packet received in the primary multicast
session.
5. IANA considerations
TBD
6. Security Considerations
Applications that are using PRAMS are analogous to the applications
that are using RAMS described in the
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Thus, these applications
are subject to the general security considerations discussed in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. The additional security
weaknesses introduced by PRAMS needs to be taken into account and a
higher level of protection must be adopted.
First of all, after attaching to access network with RAP support, the
RR will send SFGMP join message to its upstream router. a RAP
Xia, et al. Expires April 22, 2010 [Page 9]
Internet-Draft PRAMS October 2009
residing between the RR and its upstream router will intercept this
message. Counter-measures SHOULD be taken to prevent tampered or
spoofed SFGMP join messages between the RAP and RR. The integrity
and authenticity mechanism can be used to prevent this security
weakness.
When the RAP performs Rapid acquisition on behalf of all the RRs,
PRAMS operation for each RR may consume a lot of resources on RAP. A
series of PRAMS messages encapsulation and processing may sometimes
overload the RAP. On the other hand, the RAP needs to buffer SFGMP
message and establish membership database before PRAMS operation
completes. Upon receiving the unicast burst packet, the RAP needs to
translate unicast burst packets into multicast format packets. These
operations also consume a certain resources. Therefore, the RAP may
for example discard messages until its resources become available
again.
Since the RAP may be impersonated by a malicious node, counter
measures should be taken to prevent man in middle attack and replay
attack brought by RAP. For example, the channel binding mechanism
described in [RFC5056] may be used to avoid a rogue intermediary node
providing unverified and conflicting service information to each of
the RR and the Authorization server.
7. Acknowledgments
TBD
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
Xia, et al. Expires April 22, 2010 [Page 10]
Internet-Draft PRAMS October 2009
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[I-D.ietf-avt-rtcpssm]
Schooler, R., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18.txt (work in
progress), March 2009.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B. and Begen, A., "Unicast- Based Rapid Acquisition
of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-04 (work in
progress), October 2009.
[I-D.draft-johansson-avt-mcast-based-rams]
Johansson, I., "Multicast-Based Rapid Acquisition of
Multicast RTP Sessions",
draft-johansson-avt-mcast-based-rams-00 (work in
progress), April 2009.
[IEEE-802.1Q]
"Draft Standard for Virtual Bridged Local Area Networks
P802.1Q-2003", IEEE Standards for Local and Metropolitan
Area Networks , January 2003.
Authors' Addresses
Jinwei Xia
Huawei Technologies Co.,Ltd
Hui Hong Mansion
Nanjing, Baixia District 210001
China
Phone: +86-025-84565890
Email: xiajinwei@huawei.com
Xia, et al. Expires April 22, 2010 [Page 11]
Internet-Draft PRAMS October 2009
Qin Wu
Huawei Technologies Co.,Ltd
Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
Email: Sunseawq@huawei.com
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
Xia, et al. Expires April 22, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:59 |