PCP for SIP Deployments in Managed Networks
draft-boucadair-pcp-sip-ipv6-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Mohamed Boucadair | ||
| Last updated | 2015-02-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-boucadair-pcp-sip-ipv6-03
Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Informational February 23, 2015
Expires: August 27, 2015
PCP for SIP Deployments in Managed Networks
draft-boucadair-pcp-sip-ipv6-03
Abstract
This document discusses how PCP (Port Control Protocol) can be used
in SIP deployments in managed networks.
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 August 27, 2015.
Copyright Notice
Copyright (c) 2015 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
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.
Boucadair Expires August 27, 2015 [Page 1]
Internet-Draft PCP & SIP February 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. PCP Features . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Learn External IP Address and Port . . . . . . . . . . . 3
2.2. Learn and Set the Lifetime of Mapping Entries . . . . . . 4
2.3. Allow Unidirectional Media Flows . . . . . . . . . . . . 4
2.4. Preserve Port Parity . . . . . . . . . . . . . . . . . . 4
2.5. Preserve Port Contiguity . . . . . . . . . . . . . . . . 4
2.6. Learn PREFIX64 . . . . . . . . . . . . . . . . . . . . . 4
2.7. Compliant with "a=rtcp" Attribute . . . . . . . . . . . . 5
2.8. DSCP Marking Policy . . . . . . . . . . . . . . . . . . . 5
3. Avoid Crossing CGNs . . . . . . . . . . . . . . . . . . . . . 5
3.1. Avoid NAT64 . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Avoid Crossing DS-Lite AFTR . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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). In addition, the
outbound proxy does not need any further feature to be supported in
order 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.
This document discusses how PCP can be used in SIP deployments
(including IPv6 considerations).
The benefits of using PCP for SIP deployments are listed below:
o Avoid embedding an ALG in the middleboxes. Note, ALGs are not
recommended since the evolution of the service would depend on the
ALG maintenance.
Boucadair Expires August 27, 2015 [Page 2]
Internet-Draft PCP & SIP February 2015
o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to
be embedded in the SIP server. Intermediate NATs and firewalls
are transparent to the SIP service platform.
o Avoid overloading the network with keepalive message to maintain
the mapping in intermediate middleboxes.
o Work without requiring symmetric RTP/RTCP [RFC4961].
o Not require symmetric SIP to work (i.e., rport [RFC3581]).
o Easily support unidirectional sessions.
o Does not encounter issues with early media.
o The combination of PCP and ALTC [RFC6947] allows to optimize
IPv4-IPv6 interworking function resources.
o Because there is no need for connectivity checks, session
establishment delay is not impacted (pairs of ports can be pre-
reserved).
Experimentation results, including SIP flow examples, are documented
in [I-D.boucadair-pcp-nat64-experiments].
Even in deployments where ICE [RFC5245] is required, PCP can be of
great help as discussed in [I-D.penno-rtcweb-pcp] for the WebRTC
case.
The document targets SIP deployments in managed networks. It can
also be used as part of SIP-based services delivery in the context of
network-located residential gateway effort [WT-317].
2. PCP Features
2.1. Learn External IP Address and Port
The PCP base specification allows to create mappings in PCP-
controlled devices and therefore prepare for receiving incoming
packets. A SIP User Agent can use PCP to create one mapping for SIP
signalling messages and other mappings for media session purposes.
The SIP UA uses the external IP address and port number to build SIP
headers. In particular, this information is used to build the VIA
and CONTACT headers.
Boucadair Expires August 27, 2015 [Page 3]
Internet-Draft PCP & SIP February 2015
The external IP address and port(s) instantiated for media streams,
are used to build the SDP offer/answer. In particular, the "c" line
and "m" lines.
2.2. Learn and Set the Lifetime of Mapping Entries
PCP allows to discover and to set the lifetime of mapping
instantiated in intermediate middleboxes.
The discovery of the lifetime of a mapping avoids overloading the
network and SIP servers with frequent messages. This is in
particular important for cellular devices. According to [Power], the
consumption of a cellular device with a keep-alive interval equal to
20 seconds (that is the default value in [RFC3948] for example) is 29
mA (2G)/34 mA (3G). This consumption is reduced to 16 mA (2G)/24 mA
(3G) when the interval is increased to 40 seconds, to 9.1 mA (2G)/16
mA (3G) if the interval is equal to 150 seconds, and to 7.3 mA
(2G)/14 mA (3G) if the interval is equal to 180 seconds. When no
keep-alive is issued, the consumption would be 5.2 mA (2G)/6.1 mA
(3G). The impact of keepalive messages would be more severe if
multiple applications are issuing those messages (e.g., SIP, IPsec,
etc.).
2.3. Allow Unidirectional Media Flows
As a consequence of instantiating mappings for media/session flows,
incoming packets can be successfully forwarded to the appropriate SIP
UA. Particularly, unidirectional media flows (e.g., announcement
server) will be forwarded accordingly.
2.4. Preserve Port Parity
For deployments relying on classic RTP/RTCP odd/even port numbers
assignment scheme, PORT_SET option [I-D.ietf-pcp-port-set] can be use
by a SIP UA to request port parity be preserved by the PCP server.
2.5. Preserve Port Contiguity
For deployments assuming RTCP port number can be deduced from the RTP
port number, PORT_SET option [I-D.ietf-pcp-port-set] can be used by a
SIP UA to retrieve a pair of contiguous ports from the PCP server.
2.6. Learn PREFIX64
If the SIP UA is located behind a NAT64 device [RFC6146], the option
defined in [RFC7225] can be used to retrieve the PREFIX64 used by
that NAT64 device. The retrieved prefix will be used to locally
build an IPv6-converted IPv4 address corresponding to the IPv4
Boucadair Expires August 27, 2015 [Page 4]
Internet-Draft PCP & SIP February 2015
address included in the SDP message received from a remote IPv4-only
SIP UA in a SDP offer or answer.
2.7. Compliant with "a=rtcp" Attribute
The base PCP specification can be used to retrieve the port number to
be singled if "a=rtcp" attribute is in use [RFC3550].
2.8. DSCP Marking Policy
PCP can be used to discover the DSCP value to be used when sending
real-time flows or to create a mapping that matches a DSCP marking.
This can be achieved using the DSCP option defined in
[I-D.boucadair-pcp-extensions]. DSCP setting value is configured by
the network and not the SIP UA.
This feature can be used as an input for DSCP marking in some
deployments such as [I-D.ietf-tsvwg-rtcweb-qos].
3. Avoid Crossing CGNs
3.1. Avoid NAT64
Because an IPv6-only SIP UA is not aware of the connectivity
capabilities of the remote UA, the IPv6-only SIP UA uses the ALTC
attribute [RFC6947] to signal the assigned IPv6 address and the IPv4
address learned via PCP.
If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will
be used to place the session. If the remote SIP UA is IPv4-only,
IPv4 transfer capabilities will be used. NAT64 devices will be
crossed only if the remote UA is IPv4-only.
3.2. Avoid Crossing DS-Lite AFTR
SIP UAs co-located with the B4 [RFC6333] or located behind the CPE
can behave as dual-stack UAs:
o Native IPv6 address is assigned locally.
o The external IPv4 address and port is retrieved using PCP
To avoid unnecessary invocation of AFTR resources, ALTC attribute is
used to signal both IPv4 and IPv6 addresses. If the remote SIP UA is
IPv6-enabled, IPv6 transfer capabilities will be used to place the
session (i.e., the flows will avoid crossing the DS-Lite AFTR
device). If the remote SIP UA is IPv4-only, IPv4 transfer
Boucadair Expires August 27, 2015 [Page 5]
Internet-Draft PCP & SIP February 2015
capabilities will be used. AFTR devices will be crossed only if the
remote UA is IPv4-only.
4. Security Considerations
PCP-related security considerations are discussed in [RFC6887].
5. IANA Considerations
This document does not require any action from IANA.
6. Acknowledgements
Many thanks for T. Reddy and S. Kiesel for their review.
7. References
7.1. Normative References
[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.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
7.2. Informative References
[I-D.boucadair-pcp-extensions]
Boucadair, M., Penno, R., and D. Wing, "Some Extensions to
Port Control Protocol (PCP)", draft-boucadair-pcp-
extensions-03 (work in progress), April 2012.
[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.
Boucadair Expires August 27, 2015 [Page 6]
Internet-Draft PCP & SIP February 2015
[I-D.ietf-pcp-port-set]
Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou,
T., and S. Perreault, "Port Control Protocol (PCP)
Extension for Port Set Allocation", draft-ietf-pcp-port-
set-07 (work in progress), November 2014.
[I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
Polk, "DSCP and other packet markings for RTCWeb QoS",
draft-ietf-tsvwg-rtcweb-qos-03 (work in progress),
November 2014.
[I-D.penno-rtcweb-pcp]
Penno, R., Reddy, T., Wing, D., and M. Boucadair, "PCP
Considerations for WebRTC Usage", draft-penno-rtcweb-
pcp-00 (work in progress), May 2013.
[Power] Haverinen, H., Siren, J., and P. Eronen, "Energy
Consumption of Always-On Applications in WCDMA Networks",
April 2007, <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=4212635>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC
6223, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
Boucadair Expires August 27, 2015 [Page 7]
Internet-Draft PCP & SIP February 2015
[RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "The Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute", RFC 6947, May
2013.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, May 2014.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", RFC
7362, September 2014.
[WT-317] Broadband Forum, "Network Enhanced Residential Gateway
(NERG)", 2015, <https://www.broadband-forum.org/technical/
technicalwip.php>.
Author's Address
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Boucadair Expires August 27, 2015 [Page 8]