Network Working Group C. Holmberg Internet-Draft J. Holm Intended status: Standards Track Ericsson Expires: February 22, 2015 R. Jesske Deutsche Telekom M. Dolly ATT August 21, 2014 3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic Leg parameter draft-holmberg-dispatch-iotl-02.txt Abstract In 3rd-Generation Partnership Project (3GPP) networks, the signalling path between a calling user and a called user can be partioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The 'iotl' parameter is defined in order to fulfil requirements from the 3GPP. 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 Holmberg, et al. Expires February 22, 2015 [Page 1] Internet-Draft 3GPP IOTL August 2014 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 February 22, 2015. Copyright Notice Copyright (c) 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Originating roaming call . . . . . . . . . . . . . . . . 5 3.3. Terminating roaming call . . . . . . . . . . . . . . . . 5 3.4. Originating home to terminating home call . . . . . . . . 5 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 7 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 7 5.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 7 5.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 7 5.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 7 5.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 8 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 10 Holmberg, et al. Expires February 22, 2015 [Page 2] Internet-Draft 3GPP IOTL August 2014 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 10 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 12 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 13 A.5. Call between originating home and terminating home network . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction In a 3rd-Generation Partnership Project (3GPP) network, an end user can be attached (e.g. using a radio access network) to its own operator network (home network), or to another operator's network (visited network). In the latter case the user is referred to as a roaming user. 3GPP operator networks are often not connected directly to each other. Instead, there might be intermediate networks, referred to as 3GPP transit networks, between them. Such transit network act on SIP level or on IP level. In 3GPP networks, the signalling path between a calling user and a called user can be partioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. The traffic leg information can be used by intermediary entities to make policy decisions, related to e.g. media anchoring, signalling policy, insertion of media functions (e.g. transcoder) and charging. The figure below shows two users (Alice and Bob) and the different type of networks that the signaling might traverse. The signalling path can be divided into multiple traffic legs, and the type of traffic legs depends on how the signalling is routed. Holmberg, et al. Expires February 22, 2015 [Page 3] Internet-Draft 3GPP IOTL August 2014 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob Home + + + + + Home + ++++++++++++++++++ + + + + + + + + + +++++++++++++++++++++++ + + + + + Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob Visited Visited Figure 1: 3GPP operator network roaming roles ORIG HNW = Originating 3GPP Home Network TERM HNW = Terminating 3GPP Home Network ORIG VNW = Originating 3GPP Visited Network TERM VNW = Terminating 3GPP Visited Network TRANSIT NW = 3GPP Transit Network In Figure 1 Alice is a user initiating communication with Bob, and: Alice is attached to an originating network, which is either the home network of Alice, or a visited network (in case Alice is roaming). In both cases any originating service is provided by the home network of Alice. Bob is attached to a terminating network, which is either the home network of Bob, or a visited network (in case Bob is roaming). In both cases any terminating service is provided by the home network of Bob. A transit network, providing transit functions (e.g. translation of free phone numbers), may be included between the originating and terminating networks and between visited and home networks. This document defines a new SIP URI parameter [RFC3261], 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The 'iotl' parameter is defined in order to fulfil requirements from the 3rd-Generation Partnership Project (3GPP), but it can also be used in other network environments. Holmberg, et al. Expires February 22, 2015 [Page 4] Internet-Draft 3GPP IOTL August 2014 2. Applicability The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks. The usage of the parameter within other types of networks is undefined. 3. Use-cases 3.1. General This section describes examples of different types of traffic legs in 3GPP networks. 3.2. Originating roaming call In this case, Alice is located in a visited network. When Alice sends the initial SIP INVITE request for a call, one traffic leg (referred to as the 'visitedA-homeA' traffic leg) represents the signalling path between the UA of Alice and the home S-CSCF of Alice. 3.3. Terminating roaming call In this case, Bob is located in a visited network. When the home S-CSCF of Bob forwards the initial SIP INVITE request for a call towards Bob, one traffic leg (referred to as the 'homeB-visitedB' traffic leg) represents the signalling path between the home S-CSCF of Bob and the UA of Bob. 3.4. Originating home to terminating home call In this case, the home S-CSCF of Alice forwards the initial SIP INVITE request towards the home S-CSCF of Bob. The signalling path between the S-CSCFs represents one traffic leg (referred to as the 'homeA-homeB' traffic leg). 4. Conventions 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 [RFC2119]. 5. iotl SIP URI parameter 5.1. Usage As specified in [RFC3261], when a SIP entity inserts a SIP URI in an initial request for a dialog, or in a stand-alone request, the SIP URI will be used to route the request to another SIP entity, Holmberg, et al. Expires February 22, 2015 [Page 5] Internet-Draft 3GPP IOTL August 2014 addressed by the SIP URI, or to a SIP entity responsible for the host part of the SIP URI (e.g. a SIP registrar). If such entity represents the end of one or more traffic legs, the SIP entity inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP URI, to indicate the type(s) of traffic leg. Each parameter value indicates a type of traffic leg. For routing of a SIP request, a SIP entity can add the 'iotl' parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP URI of a Route header field [RFC3261], of an initial request for a dialog, or of an stand-alone request. If, within an initial request for a dialog, or within a stand-alone request, multiple Route header fields contain a SIP URI with a 'iotl' parameter, the 'iotl' parameter associated with the SIP URI of the topmost Route header field (or, if the SIP URI of the topmost Route header field does not contain an 'iotl' parameter, the SIP URI of the Route header field closest to the topmost) identifies the type of traffic leg. If a SIP request contains an 'iotl' parameter both in the Request-URI SIP URI, and in one or more SIP-URIs of the Route header fields, the 'iotl' parameter associated with the SIP URI of the topmost Route header field (or, if the SIP URI of the topmost Route header field does not contain an 'iotl' parameter, the SIP URI of the Route header field closest to the topmost) identifies the type of traffic leg. If a SIP request contains an 'iotl' parameter only in the Request-URI SIP URI, the 'iotl' parameter identifies the type of traffic leg. During SIP registration [RFC3261], entities can add the 'iotl' parameter to the SIP URI of a Path or Service-Route header field, if the entity is aware that SIP URI will be used to indicate the end of a specific traffic leg for initial requests for dialogs, or stand- alone requests, sent on the registration path. An entity that understands the 'iotl' parameter MUST NOT, from a SIP request, remove 'iotl' parameters from SIP URIs associated with other entities, unless the entity has means to determine that the 'iotl' parameter does not represent a valid traffic leg. This document does not specify the usage of the 'iotl' parameter within a SIP URI of a Record-Route header field [RFC3261]. Holmberg, et al. Expires February 22, 2015 [Page 6] Internet-Draft 3GPP IOTL August 2014 5.2. Parameter Values 5.2.1. General This section describes the SIP URI 'iotl' parameter values defined in this specification. 5.2.2. homeA-homeB This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) of the calling user and the home network (terminating) of the called user. In 3GPP, this traffic leg is between two S-CSCFs. 5.2.3. homeB-visitedB This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (terminating) of the called user and the visited network (terminating) in which the called user is located. In 3GPP, this traffic leg is between the home S-CSCF and the UE of the called user, or between the Service Centralization and Continuity Application Server (SCC AS) in the home network of the called user and Access Transfer Control Function (ATCF) in the visited network of the called user. 5.2.4. visitedA-homeA This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) in which the calling user is located and the home network (originating) of the calling user. In 3GPP, this traffic leg is between the UE and the home S-CSCF of the calling user, or between the P-CSCF in the visited network, serving the calling user, and the home S-CSCF of the calling user. 5.2.5. homeA-visitedA This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) and the visited network (originating) in which the calling user is located. Holmberg, et al. Expires February 22, 2015 [Page 7] Internet-Draft 3GPP IOTL August 2014 In 3GPP, this traffic leg is between the home S-CSCF of the calling user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] serving the calling user, and exists in scenarios where the home S-CSCF of the calling user forwards a request back to the visited network where the UE of the calling user is located. An example of this is when the Roaming Architecture for Voice over IMS with Local breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 5.2.6. visitedA-homeB This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) of the calling user and the home network (terminating) of the called user. In 3GPP, this traffic leg is between the Transit and Roaming Function (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF of the called user, and exists in scenarios where a request is forwarded from the visited network where the calling user is located directly to the home S-CSCF of the called user. An example of this is when the Roaming Architecture for Voice over IMS with Local breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 6. Syntax 6.1. General This section defines the ABNF for the 'iotl' SIP URI parameter. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. 6.2. ABNF The ABNF [RFC5234] grammar for the role SIP URI parameter is: uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / iotl-param / other-param iotl-param = iotl-tag "=" iotl-value ["." iotl-value] iotl-tag = "iotl" iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" / "homeA-visitedA" /" visitedA-homeB" / other-iotl other-iotl = 1*iotl-char iotl-char = alphanum / "-" ;; alphanum defined in RFC 3261 Holmberg, et al. Expires February 22, 2015 [Page 8] Internet-Draft 3GPP IOTL August 2014 7. Security Considerations There SHOULD exis a trust relationship between the networks that provide the roaming role and the networks that use the information for making policy decisions based on the role. In addition, there MUST exist an agreement between the operators for usage of the roaming role information. 8. IANA Considerations [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This specification adds one new value to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [RFC3969]. Parameter Name Predefined Values Reference ____________________________________________ iotl Yes [This RFC] 9. Acknowledgments The authors wish to thank everyone in the 3GPP community that gave comments on the initial version of this document. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] draft-holmberg-dispatch-iotl-01 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at IETF#90: o - Document name changed. o - Clarified that usage of the parameter is only defined within 3GPP networks. draft-holmberg-dispatch-iotl-00 o Added text on how to identify the traffic leg type when SIP-URIs of multiple Route header fields and/or the Request-URI contain an 'iotl' parameter. o Clarify that a traffic leg might span over multiple SIP dialogs. Holmberg, et al. Expires February 22, 2015 [Page 9] Internet-Draft 3GPP IOTL August 2014 o Added text saying that entities supporting the 'iotl' parameter must not remove a parameter from a request, if the parameter is associated with a SIP URI beloning to another entity. o Modified ABNF, in order to allow multiple iotl values for a single URI. o In IANA section, changed indication that predefined values exist. o Example call flows added. 11. Normative References [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. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Appendix A. 3GPP Examples A.1. General This section contains example call flows based on 3GPP usage of the SIP URI 'iotl' parameter. A.2. The UE registers via P-CSCF The Visited Proxy (P-CSCF) adds the iotl value 'homeB-visitedB' to the Path header field of the REGISTER request, to be used for terminating routing towards Alice. The Home Proxy (S-CSCF) adds the iotl value 'visitedA-homeA' to the Service-Route header field, to be used for originating initial/stand-alone requests from Alice. Visited Proxy Visited Proxy Home Proxy Home Proxy Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF | | | | | | REGISTER F1 | | | | Holmberg, et al. Expires February 22, 2015 [Page 10] Internet-Draft 3GPP IOTL August 2014 |--------------->| REGISTER F2 | | | | |--------------->| REGISTER F3 | | | | |--------------->| REGISTER F4 | | | | |--------------->| | | | | | | | | | 200 (OK) F5 | | | | |<---------------| | | | 200 (OK) F6 | | | | |<---------------| | | | 200 (OK) F7 | | | | |<---------------| | | | 200 (OK) F8 | | | | |<---------------| | | | F1 REGISTER Alice -> P-CSCF REGISTER sip:registrar.home1.net SIP/2.0 F2 REGISTER P-CSCF -> IBCF-V REGISTER sip:registrar.home1.net SIP/2.0 Path: F3 REGISTER IBCF-V -> IBCF-H REGISTER sip:registrar.home1.net SIP/2.0 Path: F4 REGISTER IBCF-H -> S-CSCF REGISTER sip:registrar.home1.net SIP/2.0 Path: F5 200 OK S-CSCF -> IBCF-H 200 OK Path: Service-Route: F6 200 OK IBCF-H -> IBCF-V 200 OK Path: Service-Route: F7 200 OK IBCF-V -> P-CSCF 200 OK Path: Service-Route: F8 200 OK P-CSCF -> Alice 200 OK Path: Holmberg, et al. Expires February 22, 2015 [Page 11] Internet-Draft 3GPP IOTL August 2014 Service-Route: Figure 2: The UE registers via P-CSCF A.3. Originating IMS call In the originating INVITE request from Alice, the iotl value 'visitedA-homeA', received in the Service-Route header field during registration, is added to the Route header field representing the Home Proxy S-CSCF, to indicate the traffic leg type between the Visited Proxy P-CSCF and the Home Proxy S-CSCF. Visited Proxy Visited Proxy Home Proxy Home Proxy Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE Alice -> P-CSCF INVITE sip:Bob@homeB.net SIP/2.0 Route: , F2 INVITE P-CSCF -> IBCF-V INVITE sip:Bob@homeB.net SIP/2.0 Route: , F3 INVITE IBCF-V -> IBCF-H INVITE sip:Bob@homeB.net SIP/2.0 Route: , F4 INVITE IBCF-H -> S-CSCF INVITE sip:Bob@homeB.net SIP/2.0 Route: Figure 3: Originating IMS call Holmberg, et al. Expires February 22, 2015 [Page 12] Internet-Draft 3GPP IOTL August 2014 A.4. Terminating IMS call In the terminating INVITE request towards Alice, the iotl value 'homeB-visitedB', provided to the Home Proxy S-CSCF during registration, is added to the Route header field representing the Visited Proxy P-CSCF, to indicate the traffic leg type between the Home Proxy S-CSCF and the Visited Proxy P-CSCF. Home Proxy Home Proxy Visited Proxy Visited Proxy S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE S-CSCF -> IBCF-H INVITE sip:Bob@visitedB.net SIP/2.0 Route: , IBCF-V INVITE sip:Bob@visitedB.net SIP/2.0 Route: , P-CSCF INVITE sip:Bob@visitedB.net SIP/2.0 Route: Bob INVITE sip:Bob@visitedB.net SIP/2.0 Figure 4: Terminating IMS call A.5. Call between originating home and terminating home network The S-CSCF of the originating home network adds the iotl value 'homeA-homeB' in the Request-URI of the INVITE, sent towards the S-CSCF of the terminating network, to indicate the traffic leg type between the S-CSCFs. Holmberg, et al. Expires February 22, 2015 [Page 13] Internet-Draft 3GPP IOTL August 2014 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE S-CSCF-A -> IBCF-A INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 F2 INVITE IBCF-a -> IBCF-B INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 F3 INVITE IBCF-B -> I-CSCF-B INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 F4 INVITE I-CSCF-B -> S-CSCF-B INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 Figure 5: Call between originating home and terminating home network Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg, et al. Expires February 22, 2015 [Page 14] Internet-Draft 3GPP IOTL August 2014 Jan Holm Ericsson Kistavagen 25 Stockholm16480 Sweden Email: jan.holm@ericsson.com Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany Phone: +4961515812766 Email: r.jesske@telekom.de Martin Dolly ATT 718 Clairmore Ave Lanoka Harbor 08734 USA Email: md3135@att.com Holmberg, et al. Expires February 22, 2015 [Page 15]