idnits 2.17.1 draft-boucadair-pcp-rtp-rtcp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 15, 2012) is 4173 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 (-29) exists of draft-ietf-pcp-base-28 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP WG M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track S. Sivakumar 5 Expires: April 18, 2013 Cisco 6 October 15, 2012 8 Reserving N and N+1 Ports with PCP 9 draft-boucadair-pcp-rtp-rtcp-05 11 Abstract 13 This document defines a new PCP Option to reserve a pair of ports (N 14 and N+1) by a PCP-controlled device while preserving the parity and 15 contiguity. This PCP Option eases the NAT traversal for applications 16 having requirements on the port parity and contiguity (e.g., RTP/ 17 RTCP). 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 18, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Why N/N+1 Option is Needed? . . . . . . . . . . . . . . . . . 3 61 3. Definition of the Port Reservation Option . . . . . . . . . . 4 62 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. PCP Port Reservation Option . . . . . . . . . . . . . . . 5 65 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Illustration Examples . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Port Reservation Option Not Supported by The PCP Server . 7 69 6.2. Port Reservation Option Is Supported by The PCP Server . . 8 70 6.3. Delete the Mappings . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 This document defines a new PCP Option [I-D.ietf-pcp-base] which aims 82 to ease the traversal of RTP/RTCP based applications [RFC3550] when a 83 NAT is involved in the path. 85 The main advantage of using PCP is it does not need any further 86 feature to be supported by the outbound proxy to assist the remote 87 endpoint to successfully establish media sessions. In particular, 88 ALGs are not required in the NAT for this purpose and no dedicated 89 functions at the media gateway are needed. 91 The base PCP specification allows to retrieve the external IP address 92 and external port to be conveyed in the SIP signaling messages 93 [RFC3261]. Therefore SIP Proxy Servers do not need to support means 94 to ease the NAT traversal of SIP messages (e.g., [RFC5626], 95 [RFC6223], etc.). Another advantage of using the external IP address 96 and port is this provides a hint to the proxy server there is no need 97 to return a small expire timer (e.g., 60s). 99 This option has been implemented as reported in 100 [I-D.boucadair-pcp-nat64-experiments]; no issue has been reported in 101 that document. 103 2. Why N/N+1 Option is Needed? 105 Traditionally the voice/video applications that use RTP and RTCP 106 would specify only the RTP port that the application would use for 107 streaming the RTP data. The inherent assumption is that the RTCP 108 traffic will be sent on the next higher port. Below is provided an 109 excerpt from [RFC3550]: 111 "RTP relies on the underlying protocol(s) to provide de- 112 multiplexing of RTP data and RTCP control streams. For UDP and 113 similar protocols, RTP SHOULD use an even destination port number 114 and the corresponding RTCP stream SHOULD use the next higher (odd) 115 destination port number. For applications that take a single port 116 number as a parameter and derive the RTP and RTCP port pair from 117 that number, if an odd number is supplied then the application 118 SHOULD replace that number with the next lower (even) number to 119 use as the base of the port pair. For applications in which the 120 RTP and RTCP destination port numbers are specified via explicit, 121 separate parameters (using a signaling protocol or other means), 122 the application MAY disregard the restrictions that the port 123 numbers be even/odd and consecutive although the use of an even/ 124 odd port pair is still encouraged." 126 [RFC3605] defines an explicit "a=RTCP" SDP attribute for some 127 applications using a distinct port than RTP+1. Even though [RFC3605] 128 defines a new attribute for explicitly specifying the RTCP attribute 129 for the SDP based applications, but since it is not a MUST to use 130 this attribute, there are still applications that are not compliant 131 with this RFC. There are also non-SDP based applications that use 132 RTP/RTCP like H323, that make the assumption that RTCP streaming will 133 happen on RTP+1 port. 135 In order for these applications to work across NAT, the NAT device 136 must have an application layer gateway, that would allocate two 137 consecutive ports. In a PCP context, a similar functionality need to 138 be provided for the PCP Client to request two consecutive ports and 139 the PCP Server to allocate and respond with the information of the 140 allocated port. 142 This document describes the mechanism to request a pair of 143 consecutive ports for a PCP-controlled device and the corresponding 144 mechanism for the PCP Server to allocate and respond to the port 145 allocation request. 147 It is acknowledged that modern applications adopt new approaches 148 (e.g., use the same port for both RTP and RTCP) which does not 149 encounter the problem raised above. This document do not target 150 those applications but "legacy" ones. 152 3. Definition of the Port Reservation Option 154 3.1. Requirements 156 The PCP Option used to reserve a port pair should meet the following 157 requirements: 159 1. Preserve the port parity as discussed in Section 4.2.2 of 160 [RFC4787]. 162 2. Preserve port contiguity as discussed in Section 4.2.3 of 163 [RFC4787] (i.e., RTCP = RTP+1). 165 3.2. Rationale 167 Since PCP does not support a mechanism to include multiple port 168 numbers in the same request/response, only the RTP port is explicitly 169 signaled in PCP messages. The companion port (i.e., RTCP port) is 170 reserved too by the PCP Server. 172 3.3. PCP Port Reservation Option 174 The format of the PCP Port Reservation Option is defined in Figure 1. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |PORT_RESRV_OPT | Reserved | 0..0 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 This Option: 184 Option Name: Port Reservation Option (PORT_RESRV_OPT) 185 Number: TBA (IANA) 186 Purpose: Used to retrieve a pair of ports 187 Valid for Opcodes: MAP 188 Length: 0 189 May appear in: both request and response 190 Maximum occurrences: 1 192 Figure 1: Port Reservation Option (a.k.a., N/N+1 port) 194 4. Client Behaviour 196 To retrieve a pair of ports following the requirements listed in 197 Section 3.1, the PCP Client adds the Port Reservation Option to its 198 PCP MAP request. The PCP Client MAY indicate its preferred external 199 port. This port number is likely to be equal to the internal port 200 indicated in the PCP request. 202 Once a response is received from the PCP Server, the PCP Client 203 checks whether the Port Reservation Option is supported by the peer 204 PCP Server following the procedure defined in Section 7.3 of 205 [I-D.ietf-pcp-base]. 207 If the answer is positive, the PCP Client retrieves the mapping 208 returned by the PCP Server; in particular the external port number 209 should be even. For the RTP case, this port is indicated to the 210 remote peer as the port number used for RTP flows; RTCP is assumed 211 to use the returned external port number + 1. 213 If the Port Reservation Option is not supported by the PCP Server, 214 and according to the port quota, only the RTP port can be signaled 215 to the remote endpoint (e.g., SDP offer/answer [RFC4566]). RTCP 216 flows are likely to fail if no mechanism to assist the traversal 217 of RTCP flows is supported (e.g., "a=RTCP" attribute). 219 When a pair of ports is retrieved from the PCP Server, two mappings 220 are instantiated in both the PCP Server and PCP Client. For explicit 221 deletion of these mappings, the PCP Client and PCP Server follow the 222 procedure defined in Section 11.5 of [I-D.ietf-pcp-base] for each 223 port mapping. 225 To reduce the delay to establish media sessions, the PCP Client MAY 226 reserve a pair of ports once the (SIP) registration phase has been 227 successfully completed. These pair of ports will be included in SDP 228 offers/answsers for instance. 230 5. Server Behaviour 232 Upon receiving the Port Reservation Option in a PCP request, the PCP 233 Server validates the request for the supported OpCode values. If an 234 unrecognized value is received a Invalid request error is returned to 235 the PCP Client (e.g., using MALFORMED_REQUEST error). The reason for 236 rejecting the request could be an invalid internal IP address, 237 invalid Internal port, etc. 239 For a valid request, the PCP Server collects the Internal port and 240 the hinted external port and verify against any administrative rules 241 to allow or disallow the PCP Client from making this request. An 242 example of an administrative rule will be by fulfilling the request 243 it would put the client over its administratively allowed limits. In 244 those cases, the PCP Server will treat this as an error and this is 245 handled the same way as described in [I-D.ietf-pcp-base] for the 246 denial of honoring the request with the appropriate Opcode. 248 To handle the PCP Reservation Option by the PCP Server, the procedure 249 defined in Section 7.3 of [I-D.ietf-pcp-base] should be followed. 250 When PCP Reservation Option is not supported, the PCP Server MUST 251 treat the request as any PCP request to create an individual mapping. 252 If port parity preservation is supported by the PCP Server, an even 253 port is likely to be returned to the PCP Client. Otherwise, a port 254 is returned if the port quota is not reached. 256 The following describes the behavior of the PCP Server when the PCP 257 Reservation Option is supported. 259 The PCP Server should request the controlling NAT device to allocate 260 a pair of consecutive ports. If there is a hinted external port 261 present in the request, the server MAY try to honor the request. The 262 PCP Server MUST honor the parity by requesting the allocation of 263 ports that match the parity. However, there is no guarantee that the 264 hinted external ports are available or be allocated. Two mappings 265 are therefore instantiated by the PCP Server with the same lifetime 266 value. These mappings are treated as any individual mapping. 268 If a mapping already exists and the PCP Reservation Option can be 269 honored, the PCP Server instantiate the companion mapping and sends 270 back a positive answer to the requesting PCP Client. 272 If the port allocation failed either because of the unavailability of 273 ports or the port parity could not be honored, the PCP Server SHOULD 274 reserve only one external port. The PCP Server SHOULD indicate in 275 the response that the PCP Reservation Option has not been honored as 276 specified in Section 6.3 of [I-D.ietf-pcp-base]. 278 If the request contains the PREFER_FAILURE option and one or both 279 hinted external ports (i.e., the hinted external port number and 280 hinted external port number + 1) cannot be allocated, the PCP Server 281 MUST reply with result code CANNOT_PROVIDE_EXTERNAL_PORT. 283 6. Illustration Examples 285 This section provides a list of examples to illustrate the usage of 286 PCP Port Reservation Option. 288 6.1. Port Reservation Option Not Supported by The PCP Server 290 Figure 2 shows an example of the flow exchange which is observed when 291 the PORT_RESERVATION_OPTION is not supported by the PCP Server. 293 +------+ +------+ 294 | PCP | | PCP | 295 |Client| |Server| 296 +------+ +------+ 297 | (1) PCP MAP Request | 298 | protocol= UDP | 299 | internal-ip-address= 198.51.100.1 | 300 | internal-port= 6000 | 301 | PORT_RESERVATION_OPTION | 302 |---------------------------------->| 303 | | 304 | (2) PCP MAP Response | 305 | protocol= UDP | 306 | internal-ip-address= 198.51.100.1 | 307 | internal-port= 6000 | 308 | external-ip-address= 192.0.2.1 | 309 | external-port= 15659 | 310 | assigned-lifetime= 3600 | 311 | UNSUPP_OPTION(PORT_RESRV_OPT) | 312 |<----------------------------------| 313 | | 315 Figure 2: Flow Example of a PCP Server which does not support the 316 Port Reservation Option 318 6.2. Port Reservation Option Is Supported by The PCP Server 320 Figure 3 and Figure 4 illustrate two examples of the flow exchanges 321 which are observed when the PORT_RESERVATION_OPTION is supported by 322 the PCP Server. Figure 3 shows an example of a PCP Server supporting 323 the option and honoring the requested external port number. Figure 4 324 shows an example of a PCP Server supporting the option but not 325 honoring the requested external port number. 327 +------+ +------+ 328 | PCP | | PCP | 329 |Client| |Server| 330 +------+ +------+ 331 | (1) PCP MAP Request | 332 | protocol= UDP | 333 | internal-ip-address= 198.51.100.1 | 334 | internal-port= 6000 | 335 | PORT_RESERVATION_OPTION | 336 |---------------------------------->| 337 | | 338 | (2) PCP MAP Response | 339 | protocol= UDP | 340 | internal-ip-address= 198.51.100.1 | 341 | internal-port= 6000 | 342 | external-ip-address= 192.0.2.1 | 343 | external-port= 6000 | 344 | assigned-lifetime= 3600 | 345 | PORT_RESERVATION_OPTION | 346 |<----------------------------------| 347 | | 349 Figure 3: Flow Example of a PCP Server supporting the option and 350 honoring the hinted external port 351 +------+ +------+ 352 | PCP | | PCP | 353 |Client| |Server| 354 +------+ +------+ 355 | (1) PCP MAP Request | 356 | protocol= UDP | 357 | internal-ip-address= 198.51.100.1 | 358 | internal-port= 6000 | 359 | PORT_RESERVATION_OPTION | 360 |---------------------------------->| 361 | | 362 | (2) PCP MAP Response | 363 | protocol= UDP | 364 | internal-ip-address= 198.51.100.1 | 365 | internal-port= 6000 | 366 | external-ip-address= 192.0.2.1 | 367 | external-port= 12000 | 368 | assigned-lifetime= 3600 | 369 | PORT_RESERVATION_OPTION | 370 |<----------------------------------| 371 | | 373 Figure 4: Flow Example of a PCP Server supporting the option but not 374 honoring the hinted external port 376 6.3. Delete the Mappings 378 Figure 5 and Figure 6 shows the exchanges that occur to delete the 379 created mappings. 381 +------+ +------+ 382 | PCP | | PCP | 383 |Client| |Server| 384 +------+ +------+ 385 | PCP MAP Request | 386 | protocol= UDP | 387 | internal-ip-address= 198.51.100.1 | 388 | internal-port= 6000 | 389 | external-ip-address= 192.0.2.1 | 390 | external-port= 6000 | 391 | requested-lifetime= 0 | 392 |---------------------------------->| 393 | | 394 | PCP MAP Request | 395 | protocol= UDP | 396 | internal-ip-address= 198.51.100.1 | 397 | internal-port= 6001 | 398 | external-ip-address= 192.0.2.1 | 399 | external-port= 6001 | 400 | requested-lifetime= 0 | 401 |---------------------------------->| 402 | | 404 Figure 5: Flow example to delete the mappings 405 +------+ +------+ 406 | PCP | | PCP | 407 |Client| |Server| 408 +------+ +------+ 409 | | 410 | PCP MAP Request | 411 | protocol= UDP | 412 | internal-ip-address= 198.51.100.1 | 413 | internal-port= 6000 | 414 | external-ip-address= 192.0.2.1 | 415 | external-port= 12000 | 416 | requested-lifetime= 0 | 417 |---------------------------------->| 418 | | 419 | PCP MAP Request | 420 | protocol= UDP | 421 | internal-ip-address= 198.51.100.1 | 422 | internal-port= 6001 | 423 | external-ip-address= 192.0.2.1 | 424 | external-port= 12001 | 425 | requested-lifetime= 0 | 426 |---------------------------------->| 427 | | 429 Figure 6: Flow example to delete the mappings (2) 431 7. IANA Considerations 433 This document requests the assignment of a new PCP Option code: 434 Option Name Value 435 ----------------- ----- 436 PORT_RESERVATION_OPTION TBA 438 8. Security Considerations 440 This document does not introduce any security issue in addition to 441 what is taken into account in [I-D.ietf-pcp-base]. 443 9. Acknowledgments 445 Many thanks to S. Perrault for his comments. 447 10. References 448 10.1. Normative References 450 [I-D.ietf-pcp-base] 451 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 452 Selkirk, "Port Control Protocol (PCP)", 453 draft-ietf-pcp-base-28 (work in progress), October 2012. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 459 A., Peterson, J., Sparks, R., Handley, M., and E. 460 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 461 June 2002. 463 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 464 Jacobson, "RTP: A Transport Protocol for Real-Time 465 Applications", STD 64, RFC 3550, July 2003. 467 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 468 in Session Description Protocol (SDP)", RFC 3605, 469 October 2003. 471 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 472 Description Protocol", RFC 4566, July 2006. 474 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 475 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 476 RFC 4787, January 2007. 478 10.2. Informative References 480 [I-D.boucadair-pcp-nat64-experiments] 481 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 482 Queiroz, "PCP NAT64 Experiments", 483 draft-boucadair-pcp-nat64-experiments-00 (work in 484 progress), September 2012. 486 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 487 Initiated Connections in the Session Initiation Protocol 488 (SIP)", RFC 5626, October 2009. 490 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 491 RFC 6223, April 2011. 493 Authors' Addresses 495 Mohamed Boucadair 496 France Telecom 497 Rennes, 35000 498 France 500 Email: mohamed.boucadair@orange.com 502 Senthil Sivakumar 503 Cisco 504 7100 Kit Creek Road 505 Research Triangle Park, North Carolina 27709 506 USA 508 Email: ssenthil@cisco.com