Internet DRAFT - draft-boucadair-pcp-rtp-rtcp
draft-boucadair-pcp-rtp-rtcp
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]
