idnits 2.17.1 draft-begen-avt-ports-for-ucast-mcast-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 15, 2009) is 5337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4585' is defined on line 392, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft B. VerSteeg 4 Intended status: Standards Track Cisco Systems 5 Expires: March 19, 2010 September 15, 2009 7 Port Mapping Between Unicast and Multicast RTP Sessions 8 draft-begen-avt-ports-for-ucast-mcast-rtp-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 19, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document presents the details of a port mapping proposal that 47 will allow RTP receivers to choose their own ports for the unicast 48 sessions in RTP applications using both multicast and unicast 49 services. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 55 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 In (any-source or source-specific) multicast RTP applications, 68 destination ports, i.e., the ports on which the multicast receivers 69 receive the RTP and RTCP packets, are defined declaratively. In 70 other words, the receivers cannot choose their receive ports and the 71 sender(s) use the pre-defined ports. 73 In unicast RTP applications, the receiving end usually wants to 74 choose its receive ports for RTP and RTCP. It may convey its request 75 to the sending end through different ways, one of which is the Offer/ 76 Answer Model [RFC3264] for the Session Description Protocol (SDP) 77 [RFC4566]. 79 RTP sessions are defined based on the destination addresses 80 [RFC3550]. While the declaration and selection of the port numbers 81 are well defined and work well for multicast and unicast RTP 82 applications, respectively, the usage of the port numbers introduces 83 complications when a receiving end mixes multicast and unicast RTP 84 sessions within the same RTP application. One such scenario is that 85 the RTP packets are distributed through source-specific multicast 86 (SSM) and a receiver sends unicast RTCP feedback to a Feedback Target 87 [I-D.ietf-avt-rtcpssm] asking for a retransmission of the packets it 88 is missing over a unicast RTP session [RFC4588]. Another scenario is 89 that a receiver wants to rapidly acquire a new multicast stream and 90 receives RTP retransmissions over a unicast session before joining 91 the multicast session [I-D.ietf-avt-rapid-acquisition-for-rtp]. 92 Similar scenarios will exist in applications where some part of the 93 content is distributed through multicast while the receivers get 94 additional and/or auxiliary content through one or more unicast 95 connections (See Figure 1). 97 In this document, we present the details of a port mapping proposal 98 that will allow receivers to choose their own ports for the unicast 99 sessions in RTP applications using both multicast and unicast 100 services. 102 +-----------+ 103 | Unicast |.............. 104 | Source | : 105 | (Server) | : 106 +-----------+ : 107 v 108 +-----------+ +----------+ +-----------+ 109 | Multicast |------->| Router |---------->|Client RTP | 110 | Source | | |..........>|Application| 111 +-----------+ +----------+ +-----------+ 112 |: 113 |: +-----------+ 114 |:...............>|Client RTP | 115 +---------------->|Application| 116 +-----------+ 118 ...> Unicast RTP Flow 119 ---> Multicast RTP Flow 121 Figure 1: RTP applications simultaneously using both multicast and 122 unicast services 124 In the remainder of this document, we refer to the RTP endpoints that 125 serve other RTP endpoints over a unicast session as the Servers. The 126 receiving RTP endpoints are referred to as Clients. 128 2. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Design Overview 136 We have the following guidelines for the port mapping solution: 138 o A scalable, distributable system is desirable. This drives the 139 design towards a system in which all of the actions associated 140 with a given set of flows at a given instant in time are distinct 141 from actions on other flows. This allows the system to be 142 dynamically segmented as dictated by dynamic conditions in the 143 field. 145 o Use atomic, client-driven transactions in order to limit the 146 amount of state information maintained by the server. 148 o Use idempotent transactions in order to limit the impact to the 149 overall system when messages are lost. The state of the system 150 would thus only depend on the last successfully received message. 152 o Do not try to correlate information from messages that do not 153 fate-share. In other words, if information is logically coupled 154 to other information, send all of the data in a single transaction 155 (to the extent that this is practical). 157 o Do not introduce new vectors for attacks. 159 o Do not carry transport addresses explicitly at the application 160 layer, which would mean layer violation. 162 o Do not have any IPv4/IPv6 dependencies. To the extent that 163 addressing information is required to persist across transactions, 164 handle the addresses in a manner that allows the server to give 165 opaque address information (aka a "cookie") to the client. The 166 client then presents the opaque addressing information back to the 167 server in subsequent transactions. This allows the system to 168 maintain connectivity information without unduly burdening the 169 server(s) with state information. 171 o Be NAT-tolerant [RFC5389] [RFC4787]. 173 4. Proposal 175 We present the details of the proposed solution on an example. 177 Consider an SSM distribution network where a distribution source 178 multicasts RTP packets to a large number of clients and local 179 retransmission servers function as feedback targets to collect 180 unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. 181 When a client detects missing packets in the primary multicast 182 session, it requests retransmission(s) from one of the retransmission 183 servers. 185 We use an SSM distribution network for this example, but ASM 186 scenarios could also be used. 188 An example SDP describing this scenario can be written as: 190 v=0 191 o=ali 1122334455 1122334466 IN IP4 nack.example.com 192 s=Local Retransmissions 193 t=0 0 194 a=group:FID 1 2 195 a=rtcp-unicast:rsi 196 m=video 41000 RTP/AVPF 98 197 i=Primary Multicast Stream 198 c=IN IP4 233.252.0.2/255 199 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 200 a=rtpmap:98 MP2T/90000 201 a=rtcp:41001 IN IP4 192.0.2.1 202 a=rtcp-fb:98 nack 203 a=mid:1 204 m=video 41002 RTP/AVPF 99 205 i=Unicast Retransmission Stream 206 c=IN IP4 192.0.2.1 207 a=rtpmap:99 rtx/90000 208 a=rtcp:41003 209 a=fmtp:99 apt=98; rtx-time=5000 210 a=mid:2 212 Figure 2: Example SDP describing an SSM distribution with support for 213 retransmissions from a local server 215 In this SDP, the source stream is multicast from a distribution 216 source (with a source IP address of 192.0.2.2) to the multicast 217 destination address of 233.252.0.2 and port 41000. A retransmission 218 server including feedback target functionality (with an address of 219 192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute. 220 The RTCP port for the unicast session (41003) is specified with the 221 'rtcp' attribute. 223 Based on this SDP, we define the following parameters: 225 o S=192.0.2.2 (Address of the distribution source) 227 o G=233.252.0.2 (Destination address where the primary multicast 228 stream is sent to) 230 o P1=41000 (Destination (RTP) port where the primary multicast 231 stream is sent to) 233 o P2=41001 (RTCP port on the retransmission server and client for 234 the primary multicast session) 236 o RS=192.0.2.1 (Address of the retransmission server) 237 o P3=41002 (RTP port on the retransmission server for the unicast 238 session) 240 o P4=41003 (RTCP port on the retransmission server for the unicast 241 session) 243 We denote the client address by C, and *c1, and *c2 denote the RTP 244 and RTCP ports on the client for the unicast session, respectively. 245 The '*' before the port numbers means that these port numbers are 246 chosen by the client, and not assigned/imposed by the server or SDP. 247 Note that if the client implements RTP/RTCP port muxing 248 [I-D.ietf-avt-rtp-and-rtcp-mux], *c1 will equal *c2. 250 The proposed solution follows the steps outlined below: 252 1. Client ascertains server address and port number(s) from the SDP 253 (RS, P3 and P4) 255 2. Client determines client port numbers (*c1 and *c2) 257 3. Client sends separate messages to the server port(s) via a new 258 RTCP message, called PortMappingRequest. These messages are 259 sourced from the ports *c1 and *c2 on the client. Note that 260 normally the message sent from port *c1 should be addressed to 261 port P3 on the server and the message sent from port *c2 should 262 be addressed to port P4 on the server. However, the former 263 message (an RTCP message being sent to an RTP port) requires the 264 server to implement RTP/RTCP port muxing on port P3 265 [I-D.ietf-avt-rtp-and-rtcp-mux]. Thus, signaling of port P4 in 266 the SDP is redundant. 268 4. Server derives client address (C) and its RTP/RTCP port 269 information (*c1 and *c2) from the received messages. 271 5. Server generates an opaque encapsulation (a "cookie") that 272 conveys the addressing information using a reversible transform. 274 6. Server sends the cookie back to the client using a new RTCP 275 message, called PortMappingResponse. 277 7. Client includes the cookie in subsequent messages sent to the 278 server. Note that each distinct 5-tuple would have its own 279 cookie, meaning that the client needs to repeat this process for 280 each RS, P3, P4, *c1 and *c2 combination. 282 8. Normal flows ensue, with the server using the addressing 283 encapsulated in the opaque cookie 285 Figure 3 shows the message flow, where each message is appended with 286 the (Source Address, Source Port, Destination Address, Destination 287 Port) information. 289 +-----------+ +----------------+ +------------+ 290 | Multicast | | Retransmission | | RTP | 291 | Source | | Server | | Receiver | 292 | (S) | | (RS) | | (C) | 293 +-----------+ +----------------+ +------------+ 294 | | | 295 | | | 296 |-- (S, *, M, P1) ->|--------- RTP Multicast --------->| 297 |-= (S, *, M, P2) ->|=-=-=-=-= RTCP Multicast -=-=-=-=>| 298 | | | 299 | (C, *c1, RS, P3) |<~~~~~~~~ Cookie Request ~~~~~~~~~| 300 | (RS, P3, C, *c1) | | 301 | |~~~~~~~~~ Cookie Receive ~~~~~~~~>| 302 | | | 303 | | | 304 | (C, *c2, RS, P3) |<~~~~~~~~ Cookie Request ~~~~~~~~~| 305 | | | 306 | (RS, P3, C, *c2) |~~~~~~~~~ Cookie Receive ~~~~~~~~>| 307 | | | 308 | | | 309 | (C, *c1, RS, P3) |<~~~~ RTCP NACK (with Cookie) ~~~~| 310 | | | 311 | (RS, P3, C, *c1) |....... RTP Retransmissions .....>| 312 | | | 313 | | | 314 | (C, *c2, RS, P3) |<~~ RTCP Reports (with Cookie) ~~~| 315 | | | 316 | (RS, P3, C, *c2) |~~~~~~~~~~ RTCP Reports ~~~~~~~~~>| 317 | | | 318 | | | 320 ~~~> Unicast RTCP Messages 321 ...> Unicast RTP Flow 322 ---> Multicast RTP Flow 323 =-=> Multicast RTCP Flow 325 Figure 3: Message flows for a retransmission from a local server 327 The PortMappingRequest message has the following layout: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |V=2|P| FMT | PT | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | SSRC of Packet Sender | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | SSRC of Media Source | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 4: FCI field syntax for the PortMappingRequest message 341 The PortMappingResponse message has the following layout: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |V=2|P| FMT | PT | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | SSRC of Packet Sender | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | SSRC of Media Source | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Cookie | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 5: FCI field syntax for the PortMappingResponse message 357 Editor's note: We will finalize the layout of these messages in a 358 later version. 360 5. Security Considerations 362 TBC. 364 6. IANA Considerations 366 TBC. 368 7. Acknowledgments 370 TBC. 372 8. References 374 8.1. Normative References 376 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 377 Jacobson, "RTP: A Transport Protocol for Real-Time 378 Applications", STD 64, RFC 3550, July 2003. 380 [I-D.ietf-avt-rapid-acquisition-for-rtp] 381 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 382 Based Rapid Acquisition of Multicast RTP Sessions", 383 draft-ietf-avt-rapid-acquisition-for-rtp-03 (work in 384 progress), September 2009. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 390 Description Protocol", RFC 4566, July 2006. 392 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 393 "Extended RTP Profile for Real-time Transport Control 394 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 395 July 2006. 397 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 398 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 399 July 2006. 401 [I-D.ietf-avt-rtcpssm] 402 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 403 Extensions for Single-Source Multicast Sessions with 404 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 405 progress), March 2009. 407 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 408 with Session Description Protocol (SDP)", RFC 3264, 409 June 2002. 411 [I-D.ietf-avt-rtp-and-rtcp-mux] 412 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 413 Control Packets on a Single Port", 414 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 415 August 2007. 417 8.2. Informative References 419 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 420 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 421 RFC 4787, January 2007. 423 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 424 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 425 October 2008. 427 Authors' Addresses 429 Ali Begen 430 Cisco Systems 431 170 West Tasman Drive 432 San Jose, CA 95134 433 USA 435 Email: abegen@cisco.com 437 Bill VerSteeg 438 Cisco Systems 439 5030 Sugarloaf Parkway 440 Lawrenceville, GA 30044 441 USA 443 Email: billvs@cisco.com