AVT A. Begen Internet-Draft B. VerSteeg Intended status: Standards Track Cisco Systems Expires: April 16, 2010 October 13, 2009 Port Mapping Between Unicast and Multicast RTP Sessions draft-begen-avt-ports-for-ucast-mcast-rtp-01 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 16, 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 April 16, 2010 [Page 1] Internet-Draft Rapid Acquisition of RTP Sessions October 2009 services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Example Scenario and Parameters . . . . . . . . . . . . . 5 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Begen & VerSteeg Expires April 16, 2010 [Page 2] Internet-Draft Rapid Acquisition of RTP Sessions October 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 April 16, 2010 [Page 3] Internet-Draft Rapid Acquisition of RTP Sessions October 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 Design a scalable and distributable system. 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 April 16, 2010 [Page 4] Internet-Draft Rapid Acquisition of RTP Sessions October 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. Note that the cookies are not meant to be understood by the clients or other ALG-like devices. This allows the server to use any method of its choice to make the cookie data opaque. o Be NAT-tolerant [RFC5389] [RFC4787]. 4. Proposal We present the details of the proposed solution on an example. 4.1. Example Scenario and Parameters 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 April 16, 2010 [Page 5] Internet-Draft Rapid Acquisition of RTP Sessions October 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 clients for the primary multicast session o RS=192.0.2.1 - Address of the retransmission server Begen & VerSteeg Expires April 16, 2010 [Page 6] Internet-Draft Rapid Acquisition of RTP Sessions October 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. 4.2. Messages The proposed solution follows the steps outlined below: 1. The client ascertains server address and port number(s) from the SDP (RS, P3 and P4). 2. The client determines its port numbers (*c1 and *c2). 3. The client sends a message to the server port via a new RTCP message, called PortMappingRequest. Separate 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, the server MUST support RTP/RTCP port muxing and any PortMappingRequest message MUST be sent to port P3 on the server. 4. The server derives client address (C) and its RTP/RTCP port information (*c1 and *c2) from the received messages. 5. For each PortMappingRequest message, the server generates an opaque encapsulation (a "cookie") that conveys the addressing information using a reversible transform. 6. The server sends each cookie back to the client using a new RTCP message, called PortMappingResponse. Editor's note: Normally, each PortMappingResponse message needs to be sent back to the port where the request came from. However, this requires the client to implement RTP/RTCP port muxing on port *c1. If the client supports port muxing, then Begen & VerSteeg Expires April 16, 2010 [Page 7] Internet-Draft Rapid Acquisition of RTP Sessions October 2009 there is no need to select a port *c2 and the client needs one cookie. However, if the client does not support RTP/RTCP port muxing, both PortMappingResponse messages MUST be sent to port *c2 on the client. In that case, each PortMappingResponse message MUST indicate whether the cookie is for port *c1 or *c2. Editor's note: For the server to be able to send the PortMappingResponse for port c1 to port c2, we need to include the cookie for port *c2 when requesting the cookie for port *c1. This introduces delay and dependency (See Figure 3). Any better solutions? Editor's note: What type of a flag/field should we add to the PortMappingRequest and PortMappingResponse messages? A single- bit flag? 7. The client includes the cookie(s) when necessary in the subsequent messages sent to the server. Note that each distinct 4-tuple MUST have its own cookie, meaning that the client needs to repeat this process for each RS, P3, *c1 and *c2 combination. 8. Normal flows ensue, with the server using the addressing encapsulated in the opaque cookie(s). If the client is willing to use the RTP and RTCP ports as specified in the SDP description (i.e., P3 and P4, respectively) in the unicast session, it does not have to request port mappings or include cookies with its subsequent messages. This means that unless the necessary cookies are included in a message received by the server, the server SHALL assume the default RTP and/or RTCP port for this client. 4.3. Message Flows Figure 3 shows the message flow, where each message is appended with the (Source Address, Source Port, Destination Address, Destination Port) information. In this scenario, we assume that the client does not mux the RTP and RTCP ports. Begen & VerSteeg Expires April 16, 2010 [Page 8] Internet-Draft Rapid Acquisition of RTP Sessions October 2009 +-----------+ +----------------+ +------------+ | Multicast | | Retransmission | | RTP | | Source | | Server | | Receiver | | (S) | | (RS) | | (C) | +-----------+ +----------------+ +------------+ | | | | | | |-- (S, *, M, P1) ->|--------- RTP Multicast --------->| |-= (S, *, M, P2) ->|=-=-=-=-= RTCP Multicast -=-=-=-=>| | | | | (C, *c2, RS, P3) |<~~~~ PortMappingRequest(c2) ~~~~~| | | | | (RS, P3, C, *c2) |~~~~~~~ PortMappingResponse ~~~~~>| | | Cookie(c2) | | | | | (C, *c1, RS, P3) |<~~~~ PortMappingRequest(c1) ~~~~~| | | with Cookie(c2) | | | | | (RS, P3, C, *c2) |~~~~~~~ PortMappingResponse ~~~~~>| | | Cookie(c1) | | | | | (C, *c2, RS, P2) |<~~~ RTCP NACK with Cookie(c1) ~~~| | | | | (RS, P3, C, *c1) |....... RTP Retransmissions .....>| | | | | | | | (C, *c2, RS, P3) |<~~~~~ RTCP Receiver Reports ~~~~~| | | (for the unicast session) | | | | | (RS, P3, C, *c2) |~~~~~~~ RTCP Sender Reports ~~~~~>| | | (for the unicast session) | | | | ~~~> Unicast RTCP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow =-=> Multicast RTCP Flow Figure 3: Message flows for a retransmission from a local server Editor's note: When sending the sender reports in the unicast session, how does the server know which port the client is expecting to receive them on? Does this imply that the server needs to remember the custom RTCP port for each client? In the example above, the compound RTCP packet carrying the NACK message also carries the Cookie(c1) since the server must know which Begen & VerSteeg Expires April 16, 2010 [Page 9] Internet-Draft Rapid Acquisition of RTP Sessions October 2009 port on the client it will send the RTP retransmission packet(s) to. Some other feedback messages such as the RAMS-R message defined in [I-D.ietf-avt-rapid-acquisition-for-rtp] will result in both RTP and RTCP packets to be sent by the server to the client. The compound RTCP packet carrying such feedback message(s) must carry both Cookie(c1) and Cookie(c2). If an RTCP message from the client will not trigger any transmission from the server, it does not have to include Cookie(c1) or Cookie(c2). 5. Message Formats The PortMappingRequest 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Begen & VerSteeg Expires April 16, 2010 [Page 10] Internet-Draft Rapid Acquisition of RTP Sessions October 2009 6. Security Considerations TBC. 7. IANA Considerations TBC. 8. Acknowledgments TBC. 9. References 9.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-04 (work in progress), October 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. [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. Begen & VerSteeg Expires April 16, 2010 [Page 11] Internet-Draft Rapid Acquisition of RTP Sessions 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), August 2007. 9.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 April 16, 2010 [Page 12]