PCP WG M. Boucadair Internet-Draft France Telecom Intended status: Standards Track S. Sivakumar Expires: April 18, 2013 Cisco October 15, 2012 Reserving N and N+1 Ports with PCP draft-boucadair-pcp-rtp-rtcp-05 Abstract This document defines a new PCP Option to reserve a pair of ports (N and N+1) by a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for applications having requirements on the port parity and contiguity (e.g., RTP/ RTCP). Requirements Language 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 RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 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 Boucadair & Sivakumar Expires April 18, 2013 [Page 1] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Why N/N+1 Option is Needed? . . . . . . . . . . . . . . . . . 3 3. Definition of the Port Reservation Option . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PCP Port Reservation Option . . . . . . . . . . . . . . . 5 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 6. Illustration Examples . . . . . . . . . . . . . . . . . . . . 7 6.1. Port Reservation Option Not Supported by The PCP Server . 7 6.2. Port Reservation Option Is Supported by The PCP Server . . 8 6.3. Delete the Mappings . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Boucadair & Sivakumar Expires April 18, 2013 [Page 2] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 1. Introduction This document defines a new PCP Option [I-D.ietf-pcp-base] which aims to ease the traversal of RTP/RTCP based applications [RFC3550] when a NAT is involved in the path. The main advantage of using PCP is it does not need any further feature to be supported by the outbound proxy to assist the remote endpoint to successfully establish media sessions. In particular, ALGs are not required in the NAT for this purpose and no dedicated functions at the media gateway are needed. The base PCP specification allows to retrieve the external IP address and external port to be conveyed in the SIP signaling messages [RFC3261]. Therefore SIP Proxy Servers do not need to support means to ease the NAT traversal of SIP messages (e.g., [RFC5626], [RFC6223], etc.). Another advantage of using the external IP address and port is this provides a hint to the proxy server there is no need to return a small expire timer (e.g., 60s). This option has been implemented as reported in [I-D.boucadair-pcp-nat64-experiments]; no issue has been reported in that document. 2. Why N/N+1 Option is Needed? Traditionally the voice/video applications that use RTP and RTCP would specify only the RTP port that the application would use for streaming the RTP data. The inherent assumption is that the RTCP traffic will be sent on the next higher port. Below is provided an excerpt from [RFC3550]: "RTP relies on the underlying protocol(s) to provide de- multiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/ odd port pair is still encouraged." Boucadair & Sivakumar Expires April 18, 2013 [Page 3] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 [RFC3605] defines an explicit "a=RTCP" SDP attribute for some applications using a distinct port than RTP+1. Even though [RFC3605] defines a new attribute for explicitly specifying the RTCP attribute for the SDP based applications, but since it is not a MUST to use this attribute, there are still applications that are not compliant with this RFC. There are also non-SDP based applications that use RTP/RTCP like H323, that make the assumption that RTCP streaming will happen on RTP+1 port. In order for these applications to work across NAT, the NAT device must have an application layer gateway, that would allocate two consecutive ports. In a PCP context, a similar functionality need to be provided for the PCP Client to request two consecutive ports and the PCP Server to allocate and respond with the information of the allocated port. This document describes the mechanism to request a pair of consecutive ports for a PCP-controlled device and the corresponding mechanism for the PCP Server to allocate and respond to the port allocation request. It is acknowledged that modern applications adopt new approaches (e.g., use the same port for both RTP and RTCP) which does not encounter the problem raised above. This document do not target those applications but "legacy" ones. 3. Definition of the Port Reservation Option 3.1. Requirements The PCP Option used to reserve a port pair should meet the following requirements: 1. Preserve the port parity as discussed in Section 4.2.2 of [RFC4787]. 2. Preserve port contiguity as discussed in Section 4.2.3 of [RFC4787] (i.e., RTCP = RTP+1). 3.2. Rationale Since PCP does not support a mechanism to include multiple port numbers in the same request/response, only the RTP port is explicitly signaled in PCP messages. The companion port (i.e., RTCP port) is reserved too by the PCP Server. Boucadair & Sivakumar Expires April 18, 2013 [Page 4] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 3.3. PCP Port Reservation Option The format of the PCP Port Reservation Option is defined in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PORT_RESRV_OPT | Reserved | 0..0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Option: Option Name: Port Reservation Option (PORT_RESRV_OPT) Number: TBA (IANA) Purpose: Used to retrieve a pair of ports Valid for Opcodes: MAP Length: 0 May appear in: both request and response Maximum occurrences: 1 Figure 1: Port Reservation Option (a.k.a., N/N+1 port) 4. Client Behaviour To retrieve a pair of ports following the requirements listed in Section 3.1, the PCP Client adds the Port Reservation Option to its PCP MAP request. The PCP Client MAY indicate its preferred external port. This port number is likely to be equal to the internal port indicated in the PCP request. Once a response is received from the PCP Server, the PCP Client checks whether the Port Reservation Option is supported by the peer PCP Server following the procedure defined in Section 7.3 of [I-D.ietf-pcp-base]. If the answer is positive, the PCP Client retrieves the mapping returned by the PCP Server; in particular the external port number should be even. For the RTP case, this port is indicated to the remote peer as the port number used for RTP flows; RTCP is assumed to use the returned external port number + 1. If the Port Reservation Option is not supported by the PCP Server, and according to the port quota, only the RTP port can be signaled to the remote endpoint (e.g., SDP offer/answer [RFC4566]). RTCP flows are likely to fail if no mechanism to assist the traversal Boucadair & Sivakumar Expires April 18, 2013 [Page 5] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 of RTCP flows is supported (e.g., "a=RTCP" attribute). When a pair of ports is retrieved from the PCP Server, two mappings are instantiated in both the PCP Server and PCP Client. For explicit deletion of these mappings, the PCP Client and PCP Server follow the procedure defined in Section 11.5 of [I-D.ietf-pcp-base] for each port mapping. To reduce the delay to establish media sessions, the PCP Client MAY reserve a pair of ports once the (SIP) registration phase has been successfully completed. These pair of ports will be included in SDP offers/answsers for instance. 5. Server Behaviour Upon receiving the Port Reservation Option in a PCP request, the PCP Server validates the request for the supported OpCode values. If an unrecognized value is received a Invalid request error is returned to the PCP Client (e.g., using MALFORMED_REQUEST error). The reason for rejecting the request could be an invalid internal IP address, invalid Internal port, etc. For a valid request, the PCP Server collects the Internal port and the hinted external port and verify against any administrative rules to allow or disallow the PCP Client from making this request. An example of an administrative rule will be by fulfilling the request it would put the client over its administratively allowed limits. In those cases, the PCP Server will treat this as an error and this is handled the same way as described in [I-D.ietf-pcp-base] for the denial of honoring the request with the appropriate Opcode. To handle the PCP Reservation Option by the PCP Server, the procedure defined in Section 7.3 of [I-D.ietf-pcp-base] should be followed. When PCP Reservation Option is not supported, the PCP Server MUST treat the request as any PCP request to create an individual mapping. If port parity preservation is supported by the PCP Server, an even port is likely to be returned to the PCP Client. Otherwise, a port is returned if the port quota is not reached. The following describes the behavior of the PCP Server when the PCP Reservation Option is supported. The PCP Server should request the controlling NAT device to allocate a pair of consecutive ports. If there is a hinted external port present in the request, the server MAY try to honor the request. The PCP Server MUST honor the parity by requesting the allocation of ports that match the parity. However, there is no guarantee that the Boucadair & Sivakumar Expires April 18, 2013 [Page 6] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 hinted external ports are available or be allocated. Two mappings are therefore instantiated by the PCP Server with the same lifetime value. These mappings are treated as any individual mapping. If a mapping already exists and the PCP Reservation Option can be honored, the PCP Server instantiate the companion mapping and sends back a positive answer to the requesting PCP Client. If the port allocation failed either because of the unavailability of ports or the port parity could not be honored, the PCP Server SHOULD reserve only one external port. The PCP Server SHOULD indicate in the response that the PCP Reservation Option has not been honored as specified in Section 6.3 of [I-D.ietf-pcp-base]. If the request contains the PREFER_FAILURE option and one or both hinted external ports (i.e., the hinted external port number and hinted external port number + 1) cannot be allocated, the PCP Server MUST reply with result code CANNOT_PROVIDE_EXTERNAL_PORT. 6. Illustration Examples This section provides a list of examples to illustrate the usage of PCP Port Reservation Option. 6.1. Port Reservation Option Not Supported by The PCP Server Figure 2 shows an example of the flow exchange which is observed when the PORT_RESERVATION_OPTION is not supported by the PCP Server. Boucadair & Sivakumar Expires April 18, 2013 [Page 7] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 +------+ +------+ | PCP | | PCP | |Client| |Server| +------+ +------+ | (1) PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | PORT_RESERVATION_OPTION | |---------------------------------->| | | | (2) PCP MAP Response | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | external-ip-address= 192.0.2.1 | | external-port= 15659 | | assigned-lifetime= 3600 | | UNSUPP_OPTION(PORT_RESRV_OPT) | |<----------------------------------| | | Figure 2: Flow Example of a PCP Server which does not support the Port Reservation Option 6.2. Port Reservation Option Is Supported by The PCP Server Figure 3 and Figure 4 illustrate two examples of the flow exchanges which are observed when the PORT_RESERVATION_OPTION is supported by the PCP Server. Figure 3 shows an example of a PCP Server supporting the option and honoring the requested external port number. Figure 4 shows an example of a PCP Server supporting the option but not honoring the requested external port number. Boucadair & Sivakumar Expires April 18, 2013 [Page 8] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 +------+ +------+ | PCP | | PCP | |Client| |Server| +------+ +------+ | (1) PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | PORT_RESERVATION_OPTION | |---------------------------------->| | | | (2) PCP MAP Response | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | external-ip-address= 192.0.2.1 | | external-port= 6000 | | assigned-lifetime= 3600 | | PORT_RESERVATION_OPTION | |<----------------------------------| | | Figure 3: Flow Example of a PCP Server supporting the option and honoring the hinted external port Boucadair & Sivakumar Expires April 18, 2013 [Page 9] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 +------+ +------+ | PCP | | PCP | |Client| |Server| +------+ +------+ | (1) PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | PORT_RESERVATION_OPTION | |---------------------------------->| | | | (2) PCP MAP Response | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | external-ip-address= 192.0.2.1 | | external-port= 12000 | | assigned-lifetime= 3600 | | PORT_RESERVATION_OPTION | |<----------------------------------| | | Figure 4: Flow Example of a PCP Server supporting the option but not honoring the hinted external port 6.3. Delete the Mappings Figure 5 and Figure 6 shows the exchanges that occur to delete the created mappings. Boucadair & Sivakumar Expires April 18, 2013 [Page 10] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 +------+ +------+ | PCP | | PCP | |Client| |Server| +------+ +------+ | PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | external-ip-address= 192.0.2.1 | | external-port= 6000 | | requested-lifetime= 0 | |---------------------------------->| | | | PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6001 | | external-ip-address= 192.0.2.1 | | external-port= 6001 | | requested-lifetime= 0 | |---------------------------------->| | | Figure 5: Flow example to delete the mappings Boucadair & Sivakumar Expires April 18, 2013 [Page 11] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 +------+ +------+ | PCP | | PCP | |Client| |Server| +------+ +------+ | | | PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6000 | | external-ip-address= 192.0.2.1 | | external-port= 12000 | | requested-lifetime= 0 | |---------------------------------->| | | | PCP MAP Request | | protocol= UDP | | internal-ip-address= 198.51.100.1 | | internal-port= 6001 | | external-ip-address= 192.0.2.1 | | external-port= 12001 | | requested-lifetime= 0 | |---------------------------------->| | | Figure 6: Flow example to delete the mappings (2) 7. IANA Considerations This document requests the assignment of a new PCP Option code: Option Name Value ----------------- ----- PORT_RESERVATION_OPTION TBA 8. Security Considerations This document does not introduce any security issue in addition to what is taken into account in [I-D.ietf-pcp-base]. 9. Acknowledgments Many thanks to S. Perrault for his comments. 10. References Boucadair & Sivakumar Expires April 18, 2013 [Page 12] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 10.1. Normative References [I-D.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-28 (work in progress), October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 10.2. Informative References [I-D.boucadair-pcp-nat64-experiments] Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. Queiroz, "PCP NAT64 Experiments", draft-boucadair-pcp-nat64-experiments-00 (work in progress), September 2012. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC 6223, April 2011. Boucadair & Sivakumar Expires April 18, 2013 [Page 13] Internet-Draft PCP Port Reservation Option (N/N+1) October 2012 Authors' Addresses Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com Senthil Sivakumar Cisco 7100 Kit Creek Road Research Triangle Park, North Carolina 27709 USA Email: ssenthil@cisco.com Boucadair & Sivakumar Expires April 18, 2013 [Page 14]