Internet DRAFT - draft-boucadair-mmusic-ipv6-use-cases
draft-boucadair-mmusic-ipv6-use-cases
MMUSIC WG M. Boucadair
Internet-Draft France Telecom
Intended status: Informational December 1, 2011
Expires: June 3, 2012
Session Description Protocol (SDP) Alternate Connectivity (ALTC): Use
Cases
draft-boucadair-mmusic-ipv6-use-cases-00
Abstract
This memo identifies a set of use cases which motivate the
specification of Session Description Protocol (SDP) Alternate
Connectivity (ALTC) attribute. These use cases are specific to IPv4/
IPv6 co-existence, IPv4/IPv6 interworking and IPv6 migration. Both
IPv6-related unicast and multicast are covered.
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 June 3, 2012.
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
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
Boucadair Expires June 3, 2012 [Page 1]
Internet-Draft ALTC Use Cases December 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multicast Use Case . . . . . . . . . . . . . . . . . . . . . . 4
4. Introducing IPv6 into SIP-based Architectures . . . . . . . . 5
4.1. Avoid Crossing CGN Devices . . . . . . . . . . . . . . . . 5
4.2. Basic Scenario for IPv6 SIP Service Delivery . . . . . . . 6
4.3. Avoid IPv4/IPv6 Interworking . . . . . . . . . . . . . . . 7
4.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . . . . 8
4.5. Direct Communications Between IPv6-enabled User Agents . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Boucadair Expires June 3, 2012 [Page 2]
Internet-Draft ALTC Use Cases December 2011
1. Introduction
This document describes some uses cases for the Session Description
Protocol (SDP, [RFC4566]) Alternate Connectivity (ALTC) attribute.
These use cases are specific to IPv4/IPv6 co-existence, IPv4/IPv6
interworking and IPv6 migration. Both IPv6-related unicast
(Section 4) and multicast (Section 3) contexts are covered.
For the use cases listed in Section 4:
o SBE/DBE are managed by the same administrative entity.
o No connectivity issue is encountered between SBEs/DBEs.
o No IPv6 connectivity issue is to be encountered between an IPv6-
enabled UA and SBE/DBE.
o Symmetric RTP/RTCP [RFC4961] is used even for IPv6 flows so that
no complications are encountered when firewalls are placed between
the UA and DBE.
These use cases motivate the need to define a simple and backward
compatible extension to SDP to be able to convey both an IPv4 and
IPv6 addresses. [I-D.boucadair-mmusic-altc] is an example providing
such functionality. The main features of ALTC are:*
o Simple
o Backwards-compatible
o Enables IPv6 transition, where the starting point is legacy IPv4
UA's without ICE.
o Works with an IPv4-only core
o Works with middleboxes
2. Terminology
This document makes use of the following terms:
o SBE (Signaling Path Border Element) denotes a functional element,
located at the boundaries of an ITAD (IP Telephony Administrative
Domain, [RFC2871]), which is responsible for intercepting
signaling flows received from User Agents and relay them to the
core service platform. A SBE may be located at the access segment
(i.e., be the service contact point for User Agents) or be located
at the interconnection with adjacent domains ([RFC6406]). A SBE
controls one or more DBEs. SBE and DBE may be located in the same
device (e.g., SBC [RFC5853]) or be separated.
o DBE (Data Path Border Element) denotes a functional element,
located at the boundaries of an ITAD, which is responsible for
intercepting media/data flows received from User Agents and relay
them to another DBE (or media servers, e.g., announcement server
Boucadair Expires June 3, 2012 [Page 3]
Internet-Draft ALTC Use Cases December 2011
or IVR). An example of DBE is a media gateway intercepting RTP
flows. SBE may be located at the access segment (i.e., be the
service contact point for User Agents) or be located at the
interconnection with adjacent domains ([RFC6406]).
o Core service platform is a macro functional block including
session routing, interfaces to advanced services and access
control. Figure 1 provides an overview of the overall
architecture including SBE, DBE and Core service platform.
+----------+
| Core SIP |
+--------->| SPF |<---------+
| SIP +----------+ SIP |
v v
+-----------+ +-----------+
+-----+ SIP | SBE | | SBE | SIP
| S |<----->| | | |<----->
| I | +-----------+ +-----------+
| P | || ||
| | +-----------+ +-----------+
| U | RTP | DBE | RTP | DBE | RTP
| A |<----->| |<----------------->| | <----->
+-----+ +-----------+ +-----------+
SIP UA can be embedded in the CPE or in a host behind the CPE
Figure 1: Service Architecture: Overview
3. Multicast Use Case
Recently, a significant effort has been undertaken within IETF to
specify new mechanisms to interconnect IPv6-only hosts to IPv4-only
servers (e.g., [RFC6146]). This effort covered exclusively unicast
transfer mode. An ongoing initiative, called multrans, has been
launched to cover multicast issues to be encountered during IPv6
transition. The overall problem statement is documented in
[I-D.jaclee-behave-v4v6-mcast-ps].
A particular issue encountered in the context of IPv4/IPv6 co-
existence and IPv6 transition of multicast services is the discovery
of multicast group and source (refer to Section 3.4 of
[I-D.jaclee-behave-v4v6-mcast-ps]):
Boucadair Expires June 3, 2012 [Page 4]
Internet-Draft ALTC Use Cases December 2011
1. An IPv6-only receiver requesting multicast content generated by
an IPv4-only source:
(1.1) An ALG is required to help an IPv6 receiver to select the
appropriate IP address when only the IPv4 address is
advertised (e.g., using SDP); otherwise the access to the
IPv4 multicast content can not be offered to the IPv6
receiver. The ALG may be located downstream the receiver.
As such, the ALG does not know in advance whether the
receiver is dual-stack or IPv6-only. The ALG may be tuned
to insert both the original IPv4 address and corresponding
IPv6 multicast address using for instance the ALTC SDP
attribute [I-D.boucadair-mmusic-altc].
(1.2) In order to avoid involving an ALG in the path, an IPv4-
only source can advertise both its IPv4 address and IPv4-
embedded IPv6 multicast address
[I-D.boucadair-behave-64-multicast-address-format] using
for instance the ALTC SDP attribute
[I-D.venaas-behave-v4v6mc-framework].
2. A dual-stack source sending its multicast content over IPv4 and
IPv6: both IPv4 and IPv6 addresses need to be inserted in the SDP
part. A means (e.g, ALTC) is needed for this purpose.
4. Introducing IPv6 into SIP-based Architectures
4.1. Avoid Crossing CGN Devices
Some service providers are in the process of enabling DS-Lite
[RFC6333] as a means to continue delivering IPv4 services to their
customers. To avoiding crossing four levels of NAT when placing a
media session (2 NAT in DS-Lite AFTR + 2 NAT in the DBE), it is
recommended to enable IPv6 functions in some SBEs/DBEs. Therefore
DS-Lite AFTRs won't be crossed for DS-Lite serviced customers if
their UA is IPv6-enabled:
o For SIP UA embedded in the CPE, this is easy to implement since
the SIP UA [RFC3261] can be tuned to behave as IPv6-only UA when
DS-Lite is enabled. No ALTC is required for that use case.
o But for SIP User Agents located behind the CPE, a solution to
indicate both IPv4 and IPv6 are required in order to avoid
crossing the DS-Lite CGN. For the NAT traversal, PCP can be used
for that purpose [I-D.boucadair-pcp-rtp-rtcp]. This would allow
to avoid embedding SIP ALG in the DS-Lite CGN, avoid impacting the
SBE by the HNT function and reduce keepalive messages. Both DS-
Lite AFTR and SBE are not overloaded by keepalive messages.
Boucadair Expires June 3, 2012 [Page 5]
Internet-Draft ALTC Use Cases December 2011
4.2. Basic Scenario for IPv6 SIP Service Delivery
A basic solution to deliver SIP-based services using IPv4-only core
service platform to IPv6-enabled UA is to enabled IPv4/IPv6
interworking function in SBE/DBE. Signaling and media between two
SBEs and DBEs is maintained over IPv4. IPv6 is used between an IPv6-
enabled UA and a SBE/DBE.
Figure 2 shows the results of session establishment between UAs. In
this scenario, IPv4/IPv6 interworking function is invoked even when
both involved UAs are IPv6-enabled.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| | |<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
Figure 2: Basic scenario
Solutions to avoid redundant IPv4/IPv6 NAT and involving several DBEs
Boucadair Expires June 3, 2012 [Page 6]
Internet-Draft ALTC Use Cases December 2011
may be valuable to consider by service providers.
4.3. Avoid IPv4/IPv6 Interworking
For services providers wanting:
1. Means to promote the invocation of IPv6 transfer capabilities can
be enabled while no parsing error is to be experienced by core
service nodes legacy nodes
2. Optimize cost related to IPv4-IPv6 translation licenses
3. Reduce the dual-stack lifetime
4. Maintain an IPv4-only core
5. Only a set of SBE/DBE are IPv6-enabled
A solution to indicate both IPv4 and IPv6 addresses is required.
This section provides an overview of this procedure:
When a SBE receives an INVITE, it instantiates in its DBE an IPv6-
IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an
IPv4 address are returned together with other information such as
port numbers. SBE builds an SDP offer including both IPv4 and IPv6-
related information using ALTC attribute. IPv6 is indicated as
preferred connectivity type.
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::2 6000
a=altc IP4 192.0.2.2 12340
Figure 3: SDP offer updated by the SBE
The request is then forwarded to the core SPF which in its turn
forwards the requests to the terminating SBE.
o If this SBE is a legacy one, then it will ignore ALTC attributes
and use "c" line.
o If the terminating SBE is IPv6-enabled:
* If the called UA is IPv4-only, then an IPv6-IPv4 context is
created in the corresponding DBE.
* If the called UA is IPv6-enabled, then an IPv6-IPv6 context is
created in the corresponding DBE.
Figure 4 shows the result of the procedure when placing a session
between an IPv4 and IPv6 UAs while Figure 5 shows the results of
establishing a session between two IPv6-enabled UAs. The result is
still not optima since redundant NAT66 is required (Section 4.4).
Boucadair Expires June 3, 2012 [Page 7]
Internet-Draft ALTC Use Cases December 2011
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 4: Session establishement between IPv4 and IPv6 UAs
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 5: Session establishement between IPv6 UAs
4.4. DBE Bypass Procedure
For service providers wanting to involve only one DBE in the media
path, when not all SBE/DBE and UAs are IPv6-enabled, a means to
indicate both IPv4 and IPv6 addresses without inducing session
failures is required. Below is proposed an example of a proposed
procedure using ALTC attribute.
When the originating SBE receives an INVITE from an IPv6-enabled UA,
it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4
context. Both an IPv6 address and an IPv4 address are returned
together with other information such as port numbers. SBE builds an
Boucadair Expires June 3, 2012 [Page 8]
Internet-Draft ALTC Use Cases December 2011
SDP offer including both IPv4 and IPv6-related information using ALTC
attribute (Figure 6). IPv6 is indicated as preferred connectivity
type.
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::2 6000
a=altc IP4 192.0.2.2 12340
Figure 6: SDP offer updated by the SBE
The request is then forwarded to the core SPF which in its turn
forwards the requests to the terminating SBE:
o If the destination UA is IPv6 or reachable with a public IPv4
address, the SBEs only forwards the request without altering the
SDP offer. No parsing error is experienced by core service nodes
since ALTC is backward compatible.
o If the terminating SBE does not support ALTC, it will ignore this
attribute an uses the legacy procedure.
As a consequence, only one DBE is maintained in the path when one of
the involved parties is IPv6-enabled. Figure 7 shows the overall
procedure when involved UAs are IPv6-enabled.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6|
| UA |<-------->| NAT66 |<----------------------------->| UA |
+----+ +-----------+ +----+
2001:db8::1 2001:db8::2
Figure 7: DBE Bypass Overview
The main advantages of such solutions are as follows:
o DBE resources are optimized
Boucadair Expires June 3, 2012 [Page 9]
Internet-Draft ALTC Use Cases December 2011
o No redundant NAT is maintained in the path when IPv6-enabled UAs
are involved
o End-to-end delay is optimized
o The robustness of the service is optimized since the delivery of
the service relies on fewer nodes
o The signaling path is also optimized since no communication
between the SBE (through SPDF in TISPAN/IMS context) and DBE at
the terminating side is required for some sessions.
4.5. Direct Communications Between IPv6-enabled User Agents
For service providers wanting to allow direct IPv6 communications
between IPv6-enabled UAs, when not all SBE/DBE and UA are IPv6-
enabled, a means to indicate both IPv4 and IPv6 addresses without
inducing session failures is required. Below is proposed an example
of a proposed procedure using ALTC attribute.
At the SBE originating side, when the SBE receives an INVITE from the
calling IPv6 UA (Figure 8), it updates uses the ALTC to indicate two
IP addresses:
1. An IPv4 address belonging to its controlled DBE
2. The same IPv6 address and port as received in the initial offer
made by the calling IPv6
Figure 9 shows an excerpt example of the SDP offer generated by the
originating SBE.
o=- 25678 753849 IN IP6 2001:db8::1
c=IN IP6 2001:db8::1
m=audio 12340 RTP/AVP 0 8
Figure 8: SDP offer of the calling UA
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::1 6000
a=altc IP4 192.0.2.2 12340
Figure 9: SDP offer updated by the SBE
The INVITE message will be routed appropriately to the destination
SBE:
1. If the SBE is a legacy device (i.e., IPv4-only); it will ignore
IPv6 addresses and contacts its DBE to instantiate an IPv4-IPv4
context.
Boucadair Expires June 3, 2012 [Page 10]
Internet-Draft ALTC Use Cases December 2011
2. If the SBE is IPv6-enabled, it will only forwards the INVITE to
the address of contact of the called party:
A. If the called party is IPv6-enabled, the communication will
be placed using IPv6. As such no DBE is involved in the data
path as illustrated in Figure 10.
B. If not, IPv4 will be used between the originating DBE and
called UA.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<--+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | | +----+
|IPv6|-+ IPv6 RTP +-|IPv6|
| UA |<---------------------------------------------------->| UA |
+----+ +----+
2001:db8::1
Figure 10: Direct IPv6 communication
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
This document does not define any protocol nor architecture; as such
there are no security considerations to be elaborated.
7. Acknowledgments
TBC.
8. References
Boucadair Expires June 3, 2012 [Page 11]
Internet-Draft ALTC Use Cases December 2011
8.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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007.
[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.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
8.2. Informative References
[I-D.boucadair-behave-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format",
draft-boucadair-behave-64-multicast-address-format-03
(work in progress), October 2011.
[I-D.boucadair-mmusic-altc]
Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute",
draft-boucadair-mmusic-altc-04 (work in progress),
November 2011.
[I-D.boucadair-pcp-rtp-rtcp]
Boucadair, M. and S. Sivakumar, "Reserving N and N+1 Ports
with PCP", draft-boucadair-pcp-rtp-rtcp-03 (work in
progress), October 2011.
[I-D.jaclee-behave-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use
Cases", draft-jaclee-behave-v4v6-mcast-ps-03 (work in
progress), October 2011.
[I-D.venaas-behave-v4v6mc-framework]
Boucadair Expires June 3, 2012 [Page 12]
Internet-Draft ALTC Use Cases December 2011
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation",
draft-venaas-behave-v4v6mc-framework-03 (work in
progress), June 2011.
[RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
Telephony Routing over IP", RFC 2871, June 2000.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[RFC6406] Malas, D. and J. Livingood, "Session PEERing for
Multimedia INTerconnect (SPEERMINT) Architecture",
RFC 6406, November 2011.
Author's Address
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange.com
Boucadair Expires June 3, 2012 [Page 13]
