AVT A. Begen
Internet-Draft B. VerSteeg
Intended status: Standards Track Cisco Systems
Expires: March 19, 2010 September 15, 2009
Port Mapping Between Unicast and Multicast RTP Sessions
draft-begen-avt-ports-for-ucast-mcast-rtp-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 March 19, 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 presents the details of a port mapping proposal that
will allow RTP receivers to choose their own ports for the unicast
sessions in RTP applications using both multicast and unicast
Begen & VerSteeg Expires March 19, 2010 [Page 1]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Begen & VerSteeg Expires March 19, 2010 [Page 2]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
1. Introduction
In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In
other words, the receivers cannot choose their receive ports and the
sender(s) use the pre-defined ports.
In unicast RTP applications, the receiving end usually wants to
choose its receive ports for RTP and RTCP. It may convey its request
to the sending end through different ways, one of which is the Offer/
Answer Model [RFC3264] for the Session Description Protocol (SDP)
[RFC4566].
RTP sessions are defined based on the destination addresses
[RFC3550]. While the declaration and selection of the port numbers
are well defined and work well for multicast and unicast RTP
applications, respectively, the usage of the port numbers introduces
complications when a receiving end mixes multicast and unicast RTP
sessions within the same RTP application. One such scenario is that
the RTP packets are distributed through source-specific multicast
(SSM) and a receiver sends unicast RTCP feedback to a Feedback Target
[I-D.ietf-avt-rtcpssm] asking for a retransmission of the packets it
is missing over a unicast RTP session [RFC4588]. Another scenario is
that a receiver wants to rapidly acquire a new multicast stream and
receives RTP retransmissions over a unicast session before joining
the multicast session [I-D.ietf-avt-rapid-acquisition-for-rtp].
Similar scenarios will exist in applications where some part of the
content is distributed through multicast while the receivers get
additional and/or auxiliary content through one or more unicast
connections (See Figure 1).
In this document, we present the details of a port mapping proposal
that will allow receivers to choose their own ports for the unicast
sessions in RTP applications using both multicast and unicast
services.
Begen & VerSteeg Expires March 19, 2010 [Page 3]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
+-----------+
| Unicast |..............
| Source | :
| (Server) | :
+-----------+ :
v
+-----------+ +----------+ +-----------+
| Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application|
+-----------+ +----------+ +-----------+
|:
|: +-----------+
|:...............>|Client RTP |
+---------------->|Application|
+-----------+
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 1: RTP applications simultaneously using both multicast and
unicast services
In the remainder of this document, we refer to the RTP endpoints that
serve other RTP endpoints over a unicast session as the Servers. The
receiving RTP endpoints are referred to as Clients.
2. Requirements Notation
The key words "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].
3. Design Overview
We have the following guidelines for the port mapping solution:
o A scalable, distributable system is desirable. This drives the
design towards a system in which all of the actions associated
with a given set of flows at a given instant in time are distinct
from actions on other flows. This allows the system to be
dynamically segmented as dictated by dynamic conditions in the
field.
o Use atomic, client-driven transactions in order to limit the
amount of state information maintained by the server.
Begen & VerSteeg Expires March 19, 2010 [Page 4]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
o Use idempotent transactions in order to limit the impact to the
overall system when messages are lost. The state of the system
would thus only depend on the last successfully received message.
o Do not try to correlate information from messages that do not
fate-share. In other words, if information is logically coupled
to other information, send all of the data in a single transaction
(to the extent that this is practical).
o Do not introduce new vectors for attacks.
o Do not carry transport addresses explicitly at the application
layer, which would mean layer violation.
o Do not have any IPv4/IPv6 dependencies. To the extent that
addressing information is required to persist across transactions,
handle the addresses in a manner that allows the server to give
opaque address information (aka a "cookie") to the client. The
client then presents the opaque addressing information back to the
server in subsequent transactions. This allows the system to
maintain connectivity information without unduly burdening the
server(s) with state information.
o Be NAT-tolerant [RFC5389] [RFC4787].
4. Proposal
We present the details of the proposed solution on an example.
Consider an SSM distribution network where a distribution source
multicasts RTP packets to a large number of clients and local
retransmission servers function as feedback targets to collect
unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm].
When a client detects missing packets in the primary multicast
session, it requests retransmission(s) from one of the retransmission
servers.
We use an SSM distribution network for this example, but ASM
scenarios could also be used.
An example SDP describing this scenario can be written as:
Begen & VerSteeg Expires March 19, 2010 [Page 5]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
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=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=mid:1
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000
a=mid:2
Figure 2: Example SDP describing an SSM distribution with support for
retransmissions from a local server
In this SDP, the source stream is multicast from a 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 retransmission
server including feedback target functionality (with an address of
192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute.
The RTCP port for the unicast session (41003) is specified with the
'rtcp' attribute.
Based on this SDP, we define the following parameters:
o S=192.0.2.2 (Address of the distribution source)
o G=233.252.0.2 (Destination address where the primary multicast
stream is sent to)
o P1=41000 (Destination (RTP) port where the primary multicast
stream is sent to)
o P2=41001 (RTCP port on the retransmission server and client for
the primary multicast session)
o RS=192.0.2.1 (Address of the retransmission server)
Begen & VerSteeg Expires March 19, 2010 [Page 6]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
o P3=41002 (RTP port on the retransmission server for the unicast
session)
o P4=41003 (RTCP port on the retransmission server for the unicast
session)
We denote the client address by C, and *c1, and *c2 denote the RTP
and RTCP ports on the client for the unicast session, respectively.
The '*' before the port numbers means that these port numbers are
chosen by the client, and not assigned/imposed by the server or SDP.
Note that if the client implements RTP/RTCP port muxing
[I-D.ietf-avt-rtp-and-rtcp-mux], *c1 will equal *c2.
The proposed solution follows the steps outlined below:
1. Client ascertains server address and port number(s) from the SDP
(RS, P3 and P4)
2. Client determines client port numbers (*c1 and *c2)
3. Client sends separate messages to the server port(s) via a new
RTCP message, called PortMappingRequest. These messages are
sourced from the ports *c1 and *c2 on the client. Note that
normally the message sent from port *c1 should be addressed to
port P3 on the server and the message sent from port *c2 should
be addressed to port P4 on the server. However, the former
message (an RTCP message being sent to an RTP port) requires the
server to implement RTP/RTCP port muxing on port P3
[I-D.ietf-avt-rtp-and-rtcp-mux]. Thus, signaling of port P4 in
the SDP is redundant.
4. Server derives client address (C) and its RTP/RTCP port
information (*c1 and *c2) from the received messages.
5. Server generates an opaque encapsulation (a "cookie") that
conveys the addressing information using a reversible transform.
6. Server sends the cookie back to the client using a new RTCP
message, called PortMappingResponse.
7. Client includes the cookie in subsequent messages sent to the
server. Note that each distinct 5-tuple would have its own
cookie, meaning that the client needs to repeat this process for
each RS, P3, P4, *c1 and *c2 combination.
8. Normal flows ensue, with the server using the addressing
encapsulated in the opaque cookie
Begen & VerSteeg Expires March 19, 2010 [Page 7]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
Figure 3 shows the message flow, where each message is appended with
the (Source Address, Source Port, Destination Address, Destination
Port) information.
+-----------+ +----------------+ +------------+
| Multicast | | Retransmission | | RTP |
| Source | | Server | | Receiver |
| (S) | | (RS) | | (C) |
+-----------+ +----------------+ +------------+
| | |
| | |
|-- (S, *, M, P1) ->|--------- RTP Multicast --------->|
|-= (S, *, M, P2) ->|=-=-=-=-= RTCP Multicast -=-=-=-=>|
| | |
| (C, *c1, RS, P3) |<~~~~~~~~ Cookie Request ~~~~~~~~~|
| (RS, P3, C, *c1) | |
| |~~~~~~~~~ Cookie Receive ~~~~~~~~>|
| | |
| | |
| (C, *c2, RS, P3) |<~~~~~~~~ Cookie Request ~~~~~~~~~|
| | |
| (RS, P3, C, *c2) |~~~~~~~~~ Cookie Receive ~~~~~~~~>|
| | |
| | |
| (C, *c1, RS, P3) |<~~~~ RTCP NACK (with Cookie) ~~~~|
| | |
| (RS, P3, C, *c1) |....... RTP Retransmissions .....>|
| | |
| | |
| (C, *c2, RS, P3) |<~~ RTCP Reports (with Cookie) ~~~|
| | |
| (RS, P3, C, *c2) |~~~~~~~~~~ RTCP Reports ~~~~~~~~~>|
| | |
| | |
~~~> Unicast RTCP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
=-=> Multicast RTCP Flow
Figure 3: Message flows for a retransmission from a local server
The PortMappingRequest message has the following layout:
Begen & VerSteeg Expires March 19, 2010 [Page 8]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: FCI field syntax for the PortMappingRequest message
The PortMappingResponse message has the following layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the PortMappingResponse message
Editor's note: We will finalize the layout of these messages in a
later version.
5. Security Considerations
TBC.
6. IANA Considerations
TBC.
7. Acknowledgments
TBC.
Begen & VerSteeg Expires March 19, 2010 [Page 9]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
8. References
8.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-03 (work in
progress), September 2009.
[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.
[I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[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),
August 2007.
Begen & VerSteeg Expires March 19, 2010 [Page 10]
Internet-Draft Rapid Acquisition of RTP Sessions September 2009
8.2. Informative References
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Authors' Addresses
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Bill VerSteeg
Cisco Systems
5030 Sugarloaf Parkway
Lawrenceville, GA 30044
USA
Email: billvs@cisco.com
Begen & VerSteeg Expires March 19, 2010 [Page 11]