Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track S. Sivakumar
Expires: September 4, 2011 Cisco
March 03, 2011
Reservation of Pair of Ports with PCP
draft-boucadair-pcp-rtp-rtcp-01
Abstract
This document defines a new PCP Option to reserve a pair of ports in
a PCP-controlled device while preserving the parity and contiguity.
This new PCP Option eases the traversal of NAT for RTP/RTCP flows.
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 September 4, 2011.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Boucadair & Sivakumar Expires September 4, 2011 [Page 1]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
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 this PCP 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Boucadair & Sivakumar Expires September 4, 2011 [Page 2]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
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,
there is no need to implement what is commonly denoted as HNT (hosted
NAT traversal) or any keepalive scheme for media streams.
Furthermore, ALGs are not required in the NAT for this purpose.
Note that the base PCP allows to retrieve the external IP address and
port to be conveyed in the SIP signaling messages [RFC3261].
Therefore SIP Proxy Servers can be more lightweight and do not need
to support means to ease the NAT traversal of SIP messages (e.g.,
[RFC5626], [I-D.ietf-sipcore-keep], etc.). The 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).
It is worth mentioning that based on some deployments, the impact of
HNT in the proxy servers is very severe: when this function is
enabled, a device dimensioned to service 75k users can serve only 30k
users!
2. Why this PCP 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/
Boucadair & Sivakumar Expires September 4, 2011 [Page 3]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
odd port pair is still encouraged."
[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.
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 when the PCP Server returns back the Port Reservation
Option in the response.
Boucadair & Sivakumar Expires September 4, 2011 [Page 4]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
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:
name: Port Reservation Option (PORT_RESRV_OPT)
number: TBA (IANA)
purpose: Used to retrieve a pair of ports
is valid for OpCodes: MAP4, MAP6
length: 0
may appear in: both
maximum occurrences: 1
Figure 1: Port Reservation Option
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 MAPy (y=4 or 6) request. The PCP Client MAY indicate its
preferred RTP external port. This port is likely to be equal to the
internal port indicated in the PCP request. A PCP Client is
encouraged to use randomized external ports to receive/send its media
flows.
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 5.3 of
[I-D.ietf-pcp-base].
o If the answer is positive, the PCP Client retrieves the mapping
returned by the PCP Server; in particular the external port number
Boucadair & Sivakumar Expires September 4, 2011 [Page 5]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
should be even. 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.
o If the Option is not supported by the PCP Server, and according
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 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 8 of [I-D.ietf-pcp-base] for each
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, 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 5.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.
Boucadair & Sivakumar Expires September 4, 2011 [Page 6]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
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
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 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 5.3 of [I-D.ietf-pcp-base].
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 September 4, 2011 [Page 7]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-port= 6000 |
| PORT_RESERVATION_OPTION |
|---------------------------------->|
| |
| (2) PCP MAPy Response |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-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 September 4, 2011 [Page 8]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-port= 6000 |
| PORT_RESERVATION_OPTION |
|---------------------------------->|
| |
| (2) PCP MAPy Response |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-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 September 4, 2011 [Page 9]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| (1) PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-port= 6000 |
| PORT_RESERVATION_OPTION |
|---------------------------------->|
| |
| (2) PCP MAPy Response |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-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 September 4, 2011 [Page 10]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-port= 6000 |
| external-ip-address= 192.0.2.1 |
| external-port= 6000 |
| requested-lifetime= 0 |
|---------------------------------->|
| |
| PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-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 September 4, 2011 [Page 11]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
+------+ +------+
| PCP | | PCP |
|Client| |Server|
+------+ +------+
| |
| PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-port= 6000 |
| external-ip-address= 192.0.2.1 |
| external-port= 12000 |
| requested-lifetime= 0 |
|---------------------------------->|
| |
| PCP MAPy Request |
| protocol= UDP |
| target-ip-address= 198.51.100.1 |
| target-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 request the assignment of a new PCP Option code:
o PORT_RESERVATION_OPTION.
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. References
9.1. Normative References
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F.
Dupont, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-06 (work in progress), February 2011.
Boucadair & Sivakumar Expires September 4, 2011 [Page 12]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
[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.
9.2. Informative References
[I-D.ietf-sipcore-keep]
Holmberg, C., "Indication of support for keep-alive",
draft-ietf-sipcore-keep-12 (work in progress),
January 2011.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Boucadair & Sivakumar Expires September 4, 2011 [Page 13]
Internet-Draft RTP/RTCP PCP Port Reservation Option March 2011
Senthil Sivakumar
Cisco
7100 Kit Creek Road
Research Triangle Park, North Carolina 27709
USA
Email: ssenthil@cisco.com
Boucadair & Sivakumar Expires September 4, 2011 [Page 14]