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]