idnits 2.17.1 draft-begen-avt-ports-for-ucast-mcast-rtp-01.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 date (October 13, 2009) is 5306 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) == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-04 ** 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 (~~), 3 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: April 16, 2010 October 13, 2009 7 Port Mapping Between Unicast and Multicast RTP Sessions 8 draft-begen-avt-ports-for-ucast-mcast-rtp-01 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 April 16, 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 4.1. Example Scenario and Parameters . . . . . . . . . . . . . 5 58 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 In (any-source or source-specific) multicast RTP applications, 72 destination ports, i.e., the ports on which the multicast receivers 73 receive the RTP and RTCP packets, are defined declaratively. In 74 other words, the receivers cannot choose their receive ports and the 75 sender(s) use the pre-defined ports. 77 In unicast RTP applications, the receiving end usually wants to 78 choose its receive ports for RTP and RTCP. It may convey its request 79 to the sending end through different ways, one of which is the Offer/ 80 Answer Model [RFC3264] for the Session Description Protocol (SDP) 81 [RFC4566]. 83 RTP sessions are defined based on the destination addresses 84 [RFC3550]. While the declaration and selection of the port numbers 85 are well defined and work well for multicast and unicast RTP 86 applications, respectively, the usage of the port numbers introduces 87 complications when a receiving end mixes multicast and unicast RTP 88 sessions within the same RTP application. One such scenario is that 89 the RTP packets are distributed through source-specific multicast 90 (SSM) and a receiver sends unicast RTCP feedback to a Feedback Target 91 [I-D.ietf-avt-rtcpssm] asking for a retransmission of the packets it 92 is missing over a unicast RTP session [RFC4588]. Another scenario is 93 that a receiver wants to rapidly acquire a new multicast stream and 94 receives RTP retransmissions over a unicast session before joining 95 the multicast session [I-D.ietf-avt-rapid-acquisition-for-rtp]. 96 Similar scenarios will exist in applications where some part of the 97 content is distributed through multicast while the receivers get 98 additional and/or auxiliary content through one or more unicast 99 connections (See Figure 1). 101 In this document, we present the details of a port mapping proposal 102 that will allow receivers to choose their own ports for the unicast 103 sessions in RTP applications using both multicast and unicast 104 services. 106 +-----------+ 107 | Unicast |.............. 108 | Source | : 109 | (Server) | : 110 +-----------+ : 111 v 112 +-----------+ +----------+ +-----------+ 113 | Multicast |------->| Router |---------->|Client RTP | 114 | Source | | |..........>|Application| 115 +-----------+ +----------+ +-----------+ 116 |: 117 |: +-----------+ 118 |:...............>|Client RTP | 119 +---------------->|Application| 120 +-----------+ 122 ...> Unicast RTP Flow 123 ---> Multicast RTP Flow 125 Figure 1: RTP applications simultaneously using both multicast and 126 unicast services 128 In the remainder of this document, we refer to the RTP endpoints that 129 serve other RTP endpoints over a unicast session as the Servers. The 130 receiving RTP endpoints are referred to as Clients. 132 2. Requirements Notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Design Overview 140 We have the following guidelines for the port mapping solution: 142 o Design a scalable and distributable system. This drives the 143 design towards a system in which all of the actions associated 144 with a given set of flows at a given instant in time are distinct 145 from actions on other flows. This allows the system to be 146 dynamically segmented as dictated by dynamic conditions in the 147 field. 149 o Use atomic, client-driven transactions in order to limit the 150 amount of state information maintained by the server. 152 o Use idempotent transactions in order to limit the impact to the 153 overall system when messages are lost. The state of the system 154 would thus only depend on the last successfully received message. 156 o Do not try to correlate information from messages that do not 157 fate-share. In other words, if information is logically coupled 158 to other information, send all of the data in a single transaction 159 (to the extent that this is practical). 161 o Do not introduce new vectors for attacks. 163 o Do not carry transport addresses explicitly at the application 164 layer, which would mean layer violation. 166 o Do not have any IPv4/IPv6 dependencies. To the extent that 167 addressing information is required to persist across transactions, 168 handle the addresses in a manner that allows the server to give 169 opaque address information (aka a "cookie") to the client. The 170 client then presents the opaque addressing information back to the 171 server in subsequent transactions. This allows the system to 172 maintain connectivity information without unduly burdening the 173 server(s) with state information. 175 Note that the cookies are not meant to be understood by the 176 clients or other ALG-like devices. This allows the server to use 177 any method of its choice to make the cookie data opaque. 179 o Be NAT-tolerant [RFC5389] [RFC4787]. 181 4. Proposal 183 We present the details of the proposed solution on an example. 185 4.1. Example Scenario and Parameters 187 Consider an SSM distribution network where a distribution source 188 multicasts RTP packets to a large number of clients and local 189 retransmission servers function as feedback targets to collect 190 unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. 191 When a client detects missing packets in the primary multicast 192 session, it requests retransmission(s) from one of the retransmission 193 servers. 195 We use an SSM distribution network for this example, but ASM 196 scenarios could also be used. 198 An example SDP describing this scenario can be written as: 200 v=0 201 o=ali 1122334455 1122334466 IN IP4 nack.example.com 202 s=Local Retransmissions 203 t=0 0 204 a=group:FID 1 2 205 a=rtcp-unicast:rsi 206 m=video 41000 RTP/AVPF 98 207 i=Primary Multicast Stream 208 c=IN IP4 233.252.0.2/255 209 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 210 a=rtpmap:98 MP2T/90000 211 a=rtcp:41001 IN IP4 192.0.2.1 212 a=rtcp-fb:98 nack 213 a=mid:1 214 m=video 41002 RTP/AVPF 99 215 i=Unicast Retransmission Stream 216 c=IN IP4 192.0.2.1 217 a=rtpmap:99 rtx/90000 218 a=rtcp:41003 219 a=fmtp:99 apt=98; rtx-time=5000 220 a=mid:2 222 Figure 2: Example SDP describing an SSM distribution with support for 223 retransmissions from a local server 225 In this SDP, the source stream is multicast from a distribution 226 source (with a source IP address of 192.0.2.2) to the multicast 227 destination address of 233.252.0.2 and port 41000. A retransmission 228 server including feedback target functionality (with an address of 229 192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute. 230 The RTCP port for the unicast session (41003) is specified with the 231 'rtcp' attribute. 233 Based on this SDP, we define the following parameters: 235 o S=192.0.2.2 - Address of the distribution source 237 o G=233.252.0.2 - Destination address where the primary multicast 238 stream is sent to 240 o P1=41000 - Destination (RTP) port where the primary multicast 241 stream is sent to 243 o P2=41001 - RTCP port on the retransmission server and clients for 244 the primary multicast session 246 o RS=192.0.2.1 - Address of the retransmission server 247 o P3=41002 - RTP port on the retransmission server for the unicast 248 session 250 o P4=41003 - RTCP port on the retransmission server for the unicast 251 session 253 We denote the client address by C, and *c1, and *c2 denote the RTP 254 and RTCP ports on the client for the unicast session, respectively. 255 The '*' before the port numbers means that these port numbers are 256 chosen by the client, and not assigned/imposed by the server or SDP. 257 Note that if the client implements RTP/RTCP port muxing 258 [I-D.ietf-avt-rtp-and-rtcp-mux], *c1 will equal *c2. 260 4.2. Messages 262 The proposed solution follows the steps outlined below: 264 1. The client ascertains server address and port number(s) from the 265 SDP (RS, P3 and P4). 267 2. The client determines its port numbers (*c1 and *c2). 269 3. The client sends a message to the server port via a new RTCP 270 message, called PortMappingRequest. Separate messages are 271 sourced from the ports *c1 and *c2 on the client. Note that 272 normally the message sent from port *c1 should be addressed to 273 port P3 on the server and the message sent from port *c2 should 274 be addressed to port P4 on the server. However, the former 275 message (an RTCP message being sent to an RTP port) requires the 276 server to implement RTP/RTCP port muxing on port P3 277 [I-D.ietf-avt-rtp-and-rtcp-mux]. Thus, the server MUST support 278 RTP/RTCP port muxing and any PortMappingRequest message MUST be 279 sent to port P3 on the server. 281 4. The server derives client address (C) and its RTP/RTCP port 282 information (*c1 and *c2) from the received messages. 284 5. For each PortMappingRequest message, the server generates an 285 opaque encapsulation (a "cookie") that conveys the addressing 286 information using a reversible transform. 288 6. The server sends each cookie back to the client using a new RTCP 289 message, called PortMappingResponse. 291 Editor's note: Normally, each PortMappingResponse message needs 292 to be sent back to the port where the request came from. 293 However, this requires the client to implement RTP/RTCP port 294 muxing on port *c1. If the client supports port muxing, then 295 there is no need to select a port *c2 and the client needs one 296 cookie. However, if the client does not support RTP/RTCP port 297 muxing, both PortMappingResponse messages MUST be sent to port 298 *c2 on the client. In that case, each PortMappingResponse 299 message MUST indicate whether the cookie is for port *c1 or *c2. 301 Editor's note: For the server to be able to send the 302 PortMappingResponse for port c1 to port c2, we need to include 303 the cookie for port *c2 when requesting the cookie for port *c1. 304 This introduces delay and dependency (See Figure 3). Any better 305 solutions? 307 Editor's note: What type of a flag/field should we add to the 308 PortMappingRequest and PortMappingResponse messages? A single- 309 bit flag? 311 7. The client includes the cookie(s) when necessary in the 312 subsequent messages sent to the server. Note that each distinct 313 4-tuple MUST have its own cookie, meaning that the client needs 314 to repeat this process for each RS, P3, *c1 and *c2 combination. 316 8. Normal flows ensue, with the server using the addressing 317 encapsulated in the opaque cookie(s). 319 If the client is willing to use the RTP and RTCP ports as specified 320 in the SDP description (i.e., P3 and P4, respectively) in the unicast 321 session, it does not have to request port mappings or include cookies 322 with its subsequent messages. This means that unless the necessary 323 cookies are included in a message received by the server, the server 324 SHALL assume the default RTP and/or RTCP port for this client. 326 4.3. Message Flows 328 Figure 3 shows the message flow, where each message is appended with 329 the (Source Address, Source Port, Destination Address, Destination 330 Port) information. In this scenario, we assume that the client does 331 not mux the RTP and RTCP ports. 333 +-----------+ +----------------+ +------------+ 334 | Multicast | | Retransmission | | RTP | 335 | Source | | Server | | Receiver | 336 | (S) | | (RS) | | (C) | 337 +-----------+ +----------------+ +------------+ 338 | | | 339 | | | 340 |-- (S, *, M, P1) ->|--------- RTP Multicast --------->| 341 |-= (S, *, M, P2) ->|=-=-=-=-= RTCP Multicast -=-=-=-=>| 342 | | | 343 | (C, *c2, RS, P3) |<~~~~ PortMappingRequest(c2) ~~~~~| 344 | | | 345 | (RS, P3, C, *c2) |~~~~~~~ PortMappingResponse ~~~~~>| 346 | | Cookie(c2) | 347 | | | 348 | (C, *c1, RS, P3) |<~~~~ PortMappingRequest(c1) ~~~~~| 349 | | with Cookie(c2) | 350 | | | 351 | (RS, P3, C, *c2) |~~~~~~~ PortMappingResponse ~~~~~>| 352 | | Cookie(c1) | 353 | | | 354 | (C, *c2, RS, P2) |<~~~ RTCP NACK with Cookie(c1) ~~~| 355 | | | 356 | (RS, P3, C, *c1) |....... RTP Retransmissions .....>| 357 | | | 358 | | | 359 | (C, *c2, RS, P3) |<~~~~~ RTCP Receiver Reports ~~~~~| 360 | | (for the unicast session) | 361 | | | 362 | (RS, P3, C, *c2) |~~~~~~~ RTCP Sender Reports ~~~~~>| 363 | | (for the unicast session) | 364 | | | 366 ~~~> Unicast RTCP Messages 367 ...> Unicast RTP Flow 368 ---> Multicast RTP Flow 369 =-=> Multicast RTCP Flow 371 Figure 3: Message flows for a retransmission from a local server 373 Editor's note: When sending the sender reports in the unicast 374 session, how does the server know which port the client is expecting 375 to receive them on? Does this imply that the server needs to 376 remember the custom RTCP port for each client? 378 In the example above, the compound RTCP packet carrying the NACK 379 message also carries the Cookie(c1) since the server must know which 380 port on the client it will send the RTP retransmission packet(s) to. 381 Some other feedback messages such as the RAMS-R message defined in 382 [I-D.ietf-avt-rapid-acquisition-for-rtp] will result in both RTP and 383 RTCP packets to be sent by the server to the client. The compound 384 RTCP packet carrying such feedback message(s) must carry both 385 Cookie(c1) and Cookie(c2). If an RTCP message from the client will 386 not trigger any transmission from the server, it does not have to 387 include Cookie(c1) or Cookie(c2). 389 5. Message Formats 391 The PortMappingRequest message has the following layout: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |V=2|P| FMT | PT | Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | SSRC of Packet Sender | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | SSRC of Media Source | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 4: FCI field syntax for the PortMappingRequest message 405 The PortMappingResponse message has the following layout: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |V=2|P| FMT | PT | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SSRC of Packet Sender | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | SSRC of Media Source | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 : Cookie : 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: FCI field syntax for the PortMappingResponse message 421 Editor's note: We will finalize the layout of these messages in a 422 later version. 424 6. Security Considerations 426 TBC. 428 7. IANA Considerations 430 TBC. 432 8. Acknowledgments 434 TBC. 436 9. References 438 9.1. Normative References 440 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 441 Jacobson, "RTP: A Transport Protocol for Real-Time 442 Applications", STD 64, RFC 3550, July 2003. 444 [I-D.ietf-avt-rapid-acquisition-for-rtp] 445 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 446 Based Rapid Acquisition of Multicast RTP Sessions", 447 draft-ietf-avt-rapid-acquisition-for-rtp-04 (work in 448 progress), October 2009. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 454 Description Protocol", RFC 4566, July 2006. 456 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 457 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 458 July 2006. 460 [I-D.ietf-avt-rtcpssm] 461 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 462 Extensions for Single-Source Multicast Sessions with 463 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 464 progress), March 2009. 466 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 467 with Session Description Protocol (SDP)", RFC 3264, 468 June 2002. 470 [I-D.ietf-avt-rtp-and-rtcp-mux] 471 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 472 Control Packets on a Single Port", 473 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 474 August 2007. 476 9.2. Informative References 478 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 479 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 480 RFC 4787, January 2007. 482 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 483 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 484 October 2008. 486 Authors' Addresses 488 Ali Begen 489 Cisco Systems 490 170 West Tasman Drive 491 San Jose, CA 95134 492 USA 494 Email: abegen@cisco.com 496 Bill VerSteeg 497 Cisco Systems 498 5030 Sugarloaf Parkway 499 Lawrenceville, GA 30044 500 USA 502 Email: billvs@cisco.com