idnits 2.17.1 draft-holmberg-dispatch-iotl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2014) is 3652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This RFC' is mentioned on line 337, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft J. Holm 4 Intended status: Standards Track Ericsson 5 Expires: October 27, 2014 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 April 25, 2014 11 SIP URI Inter Operator Traffic Leg parameter 12 draft-holmberg-dispatch-iotl-00.txt 14 Abstract 16 In telecommunication networks, the signalling path between a calling 17 user and a called user can be divided into smaller parts, referred to 18 as traffic legs. Each traffic leg may span networks belonging to 19 different operators, and will have its own characteristics that can 20 be different from other traffic legs in the same call. The 21 directionality in traffic legs relates to a SIP request creating a 22 dialogue and stand-alone SIP request. 24 This document defines a new SIP URI parameter, 'iotl', which can be 25 used in a SIP URI to indicate that the entity associated with the 26 address, or an entity responsible for the host part of the address, 27 represents the end of a specific traffic leg. 29 The 'iotl' parameter is defined in order to fulfil requirements from 30 the 3rd-Generation Partnership Project (3GPP), but it can also be 31 used in other network environments. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 27, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Originating roaming call . . . . . . . . . . . . . . . . 4 71 2.3. Terminating roaming call . . . . . . . . . . . . . . . . 4 72 2.4. Originating home to terminating home call . . . . . . . . 5 73 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5 75 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 5 77 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 78 4.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 6 79 4.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 6 80 4.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 6 81 4.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 6 82 4.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 7 83 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 89 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 93 1. Introduction 95 In a telecommunication network, an end user can be attached (e.g. 96 using a radio access network) to its own operator network (home 97 network), or to another operator's network (visited network). In the 98 latter case the user is referred to as a roaming user. 100 Telecommunication operator networks are often not connected directly 101 to each other. Instead, there might be intermediate networks, 102 referred to as transit networks, between them. A transit network 103 might act on a SIP level or on IP level. 105 In telecommunication networks, the signalling path between a calling 106 user and a called user can be divided into smaller parts, referred to 107 as traffic legs. Each traffic leg may span networks belonging to 108 different operators, and will have its own characteristics that can 109 be different from other traffic legs in the same call. The 110 directionality in traffic legs relates to a SIP request creating a 111 dialogue and stand-alone SIP request. 113 The traffic leg information can be used by intermediary entities to 114 make policy decisions, related to e.g. media anchoring, signalling 115 policy, insertion of media functions (e.g. transcoder) and charging. 117 The figure below shows two users (Alice and Bob) and the different 118 type of networks that the signaling might traverse. The signalling 119 path can be divided into multiple traffic legs, and the type of 120 traffic legs depends on how the signalling is routed. 122 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 123 Home + + + + + Home 124 + ++++++++++++++++++ + + 125 + + + 126 + + + 127 + +++++++++++++++++++++++ + 128 + + + + 129 Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 130 Visited Visited 132 Figure 1: Telecommunication operator network roaming roles 134 ORIG HNW = Originating Home Network 136 TERM HNW = Terminating Home Network 138 ORIG VNW = Originating Visited Network 140 TERM VNW = Terminating Visited Network 142 In Figure 1 Alice is a user initiating communication with Bob, and: 144 Alice is attached to an originating network, which is either the home 145 network of Alice, or a visited network (in case Alice is roaming). 146 In both cases any originating service is provided by the home network 147 of Alice. 149 Bob is attached to a terminating network, which is either the home 150 network of Bob, or a visited network (in case Bob is roaming). In 151 both cases any terminating service is provided by the home network of 152 Bob. 154 A transit network, providing transit functions (e.g. translation of 155 free phone numbers), may be included between the originating and 156 terminating networks and between visited and home networks. 158 This document defines a new SIP URI parameter [RFC3261], 'iotl', 159 which can be used in a SIP URI to indicate that the entity associated 160 with the address, or an entity responsible for the host part of the 161 address, represents the end of a specific traffic leg. 163 The 'iotl' parameter is defined in order to fulfil requirements from 164 the 3rd-Generation Partnership Project (3GPP), but it can also be 165 used in other network environments. 167 2. Use-cases 169 2.1. General 171 This section describes examples of different types of traffic legs in 172 3GPP networks. 174 2.2. Originating roaming call 176 In this case, Alice is located in a visited network. When Alice 177 sends the initial SIP INVITE request for a call, one traffic leg 178 (referred to as the 'visitedA-homeA' traffic leg) represents the 179 signalling path between the UA of Alice and the home S-CSCF of Alice. 181 2.3. Terminating roaming call 183 In this case, Bob is located in a visited network. When the home 184 S-CSCF of Bob forwards the initial SIP INVITE request for a call 185 towards Bob, one traffic leg (referred to as the 'homeB-visitedB' 186 traffic leg) represents the signalling path between the home S-CSCF 187 of Bob and the UA of Bob. 189 2.4. Originating home to terminating home call 191 In this case, the home S-CSCF of Alice forwards the initial SIP 192 INVITE request towards the home S-CSCF of Bob. The signalling path 193 between the S-CSCFs represents one traffic leg (referred to as the 194 'homeA-homeB' traffic leg). 196 3. Conventions 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 4. iotl SIP URI parameter 204 4.1. Usage 206 As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 207 initial request for a dialog, or in a stand-alone request, the SIP 208 URI will be used to route the request to another SIP entity, 209 addressed by the SIP URI, or to a SIP entity responsible for the host 210 part of the SIP URI (e.g. a SIP registrar). If such entity 211 represents the end of a traffic leg, the SIP entity inserting the SIP 212 URI can add a SIP URI 'iotl' parameter to the SIP URI, to indicate 213 the type of traffic leg. 215 For routing of a SIP request, a SIP entity can add the 'iotl' 216 parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP 217 URI of a Route header field [RFC3261], of an initial request for a 218 dialog, or of an stand-alone request. 220 During SIP registration [RFC3261], entities can add the 'iotl' 221 parameter to the SIP URI of a Path or Service-Route header field, if 222 the entity is aware that SIP URI will be used to indicate the end of 223 a specific traffic leg for initial requests for dialogs, or stand- 224 alone requests, sent on the registration path. 226 This document does not specify the usage of the 'iotl' parameter 227 within a SIP URI of a Record-Route header field [RFC3261]. 229 4.2. Parameter Values 231 4.2.1. General 233 This section describes the SIP URI 'iotl' parameter values defined in 234 this specification. 236 4.2.2. homeA-homeB 238 This value indicates that a SIP entity responsible for the host part 239 of the SIP URI associated with the parameter represents the end of a 240 traffic leg between the home network (originating) of the calling 241 user and the home network (terminating) of the called user. 243 In 3GPP, this traffic leg is between two S-CSCFs. 245 4.2.3. homeB-visitedB 247 This value indicates that the SIP entity addressed by the SIP URI 248 associated with the parameter represents the end of a traffic leg 249 between the home network (terminating) of the called user and the 250 visited network (terminating) in which the called user is located. 252 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 253 the called user, or between the Service Centralization and Continuity 254 Application Server (SCC AS) in the home network of the called user 255 and Access Transfer Control Function (ATCF) in the visited network of 256 the called user. 258 4.2.4. visitedA-homeA 260 This value indicates that a SIP entity responsible for the host part 261 of the SIP URI associated with the parameter represents the end of a 262 traffic leg between the visited network (originating) in which the 263 calling user is located and the home network (originating) of the 264 calling user. 266 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 267 the calling user, or between the P-CSCF in the visited network, 268 serving the calling user, and the home S-CSCF of the calling user. 270 4.2.5. homeA-visitedA 272 This value indicates that the SIP entity addressed by the SIP URI 273 associated with the parameter represents the end of a traffic leg 274 between the home network (originating) and the visited network 275 (originating) in which the calling user is located. 277 In 3GPP, this traffic leg is between the home S-CSCF of the calling 278 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 279 serving the calling user, and exists in scenarios where the home 280 S-CSCF of the calling user forwards a request back to the visited 281 network where the UE of the calling user is located. An example of 282 this is when the Roaming Architecture for Voice over IMS with Local 283 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 285 4.2.6. visitedA-homeB 287 This value indicates that a SIP entity responsible for the host part 288 of the SIP URI associated with the parameter represents represents 289 the end of a traffic leg between the visited network (originating) of 290 the calling user and the home network (terminating) of the called 291 user. 293 In 3GPP, this traffic leg is between the Transit and Roaming Function 294 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 295 of the called user, and exists in scenarios where a request is 296 forwarded from the visited network where the calling user is located 297 directly to the home S-CSCF of the called user. An example of this 298 is when the Roaming Architecture for Voice over IMS with Local 299 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 301 5. Syntax 303 5.1. General 305 This section defines the ABNF for the 'iotl' SIP URI parameter. The 306 ABNF defined in this specification is conformant to RFC 5234 307 [RFC5234]. 309 5.2. ABNF 311 The ABNF [RFC5234] grammar for the role SIP URI parameter is: 313 uri-parameter = transport-param / user-param / method-param / ttl-param 314 / maddr-param / lr-param / iotl-param / other-param 315 iotl-param = iotl-tag "=" iotl-value 316 iotl-tag = "iotl" 317 iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" 318 / "homeA-visitedA" /" visitedA-homeB" / gen-value 320 6. Security Considerations 322 There SHOULD exis a trust relationship between the networks that 323 provide the roaming role and the networks that use the information 324 for making policy decisions based on the role. In addition, there 325 MUST exist an agreement between the operators for usage of the 326 roaming role information. 328 7. IANA Considerations 330 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 331 document.] This specification adds one new value to the IANA 332 registration in the "SIP/SIPS URI Parameters" registry as defined in 333 [RFC3969]. 335 Parameter Name Predefined Values Reference 336 ____________________________________________ 337 iotl NO [This RFC] 339 8. Acknowledgments 341 The authors wish to thank everyone in the 3GPP community that gave 342 comments on the initial version of this document. 344 9. Change Log 346 [RFC EDITOR NOTE: Please remove this section when publishing] 348 10. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 354 A., Peterson, J., Sparks, R., Handley, M., and E. 355 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 356 June 2002. 358 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 359 (IANA) Uniform Resource Identifier (URI) Parameter 360 Registry for the Session Initiation Protocol (SIP)", BCP 361 99, RFC 3969, December 2004. 363 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 364 Specifications: ABNF", STD 68, RFC 5234, January 2008. 366 Authors' Addresses 368 Christer Holmberg 369 Ericsson 370 Hirsalantie 11 371 Jorvas 02420 372 Finland 374 Email: christer.holmberg@ericsson.com 375 Jan Holm 376 Ericsson 377 Kistavagen 25 378 Stockholm16480 379 Sweden 381 Email: jan.holm@ericsson.com 383 Roland Jesske 384 Deutsche Telekom 385 Heinrich-Hertz-Strasse 3-7 386 Darmstadt 64307 387 Germany 389 Phone: +4961515812766 390 Email: r.jesske@telekom.de 392 Martin Dolly 393 ATT 394 718 Clairmore Ave 395 Lanoka Harbor 08734 396 USA 398 Email: md3135@att.com