idnits 2.17.1 draft-vanelburg-sipping-private-network-indication-03.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2009) is 5537 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) == Outdated reference: A later version (-05) exists of draft-drage-sipping-service-identification-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. van Elburg 3 Internet-Draft Ericsson Telecommunicatie B.V. 4 Intended status: Informational K. Drage 5 Expires: August 23, 2009 Alcatel-Lucent 6 February 19, 2009 8 The Session Initiation Protocol (SIP) P-Private-Network-Indication 9 Private-Header (P-Header) 10 draft-vanelburg-sipping-private-network-indication-03.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 23, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document describes why a private network indication is needed. 50 A private network indication allows other nodes in a network to treat 51 private network traffic to a different set of rules then public 52 network traffic. The indication also distinguishes one private 53 network from another private network. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Business communication . . . . . . . . . . . . . . . . . . 4 60 1.3. Indication types . . . . . . . . . . . . . . . . . . . . . 5 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Public network traffic . . . . . . . . . . . . . . . . . . 6 64 3.2. Private network traffic . . . . . . . . . . . . . . . . . 6 65 3.3. Trust domain . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Application of terminology . . . . . . . . . . . . . . . . . . 7 67 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Overview of solution . . . . . . . . . . . . . . . . . . . . . 11 69 7. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.1. UA behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.2. Proxy behaviour . . . . . . . . . . . . . . . . . . . . . 12 72 7.2.1. Private-Network-Indication generation . . . . . . . . 12 73 7.2.2. Private-Network-Indication consumption . . . . . . . . 12 74 7.2.3. Private-Network-Indication removal . . . . . . . . . . 12 75 8. P-Private-Network-Indication header field definition . . . . . 12 76 9. Security considerations . . . . . . . . . . . . . . . . . . . 13 77 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 13.1. Normative references . . . . . . . . . . . . . . . . . . . 14 82 13.2. Informative references . . . . . . . . . . . . . . . . . . 15 83 Appendix A. Alternative solutions discussed . . . . . . . . . . . 15 84 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 A.2. Attribute on existing header . . . . . . . . . . . . . . . 16 86 A.3. Token value on existing header . . . . . . . . . . . . . . 16 87 A.4. Resource-Priority header . . . . . . . . . . . . . . . . . 16 88 A.5. P-Asserted-Service header . . . . . . . . . . . . . . . . 16 89 A.6. Request-Disposition header . . . . . . . . . . . . . . . . 17 90 A.7. P-Access-Network-Information . . . . . . . . . . . . . . . 17 91 A.8. URI parameter . . . . . . . . . . . . . . . . . . . . . . 17 92 A.9. New header . . . . . . . . . . . . . . . . . . . . . . . . 17 93 A.9.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 94 A.9.2. Full SIP header field . . . . . . . . . . . . . . . . 17 95 A.9.3. New P-header . . . . . . . . . . . . . . . . . . . . . 17 96 Appendix B. Revision Information . . . . . . . . . . . . . . . . 18 97 B.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . . 18 98 B.2. version 01 . . . . . . . . . . . . . . . . . . . . . . . . 18 99 B.3. version 02 . . . . . . . . . . . . . . . . . . . . . . . . 18 100 B.4. version 03 . . . . . . . . . . . . . . . . . . . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 1.1. General 107 ETSI TISPAN defines Next Generation Networks (NGN) which uses the 108 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia 109 Subsystem) which in turn uses SIP (RFC3261 [RFC3261]) as its main 110 signalling protocol. (For more information on the IMS, a detailed 111 description can be found in 3GPP TS 23.228 [3GPP.23.228] and 3GPP TS 112 24.229 [3GPP.24.229].) 114 1.2. Business communication 116 In the context of its work on business communiction support in public 117 next generation networks (NGN), ETSI TISPAN has identified a 118 framework [ETSI.181.019] for the support of business communication 119 capabilities by the NGN. As well as the direct attachment of Next 120 Generation Corporate Network (NGCN) equipment, this includes the 121 capability to "host" functionality relating to the enterprise network 122 within the NGN itself. 124 These hosting arrangements are: 125 a) virtual leased line, where NGCN sites are interconnected through 126 the NGN; 127 b) business trunking application, where the NGN hosts transit 128 capabilities between NGCN's, break-in capabilities from NGN to 129 NGCN and break-out capabilities from NGCN to NGN; and 130 c) hosted enterprise services, where an NGN hosts originating and/or 131 terminating business communication capabilities for business 132 communication users that are directly attached to an NGN. 134 ETSI TISPAN has requirements that can be met by the introduction of 135 an explicit indication for private network traffic. 137 The traffic generated or received by an NGN on behalf of a private 138 network can be either: 139 o public network traffic: traffic sent to the NGN for processing 140 according to normal rules of the NGN. This type of traffic is 141 known as public network traffic; 142 o private network traffic: traffic sent to the NGN for processing 143 according to an agreed set of rules specific to an enterprise. 144 This type of traffic is known as private network traffic. Private 145 network traffic is normally within a single enterprise, but 146 private network traffic can also exist between two different 147 enterprises if not precluded for regulatory reasons. 149 1.3. Indication types 151 A private network indication as proposed by this document should not 152 be confused with an indication to the local user that the remote user 153 is in the same private network. This has traditionally resulted in 154 PBXs providing distinctive ringing on incoming calls, but has also 155 been used as input to services provided to the end user, e.g. 156 different forwarding conditions and so on. Traditionally, this has 157 only been applied where the call does not enter the public network at 158 all, but we regard that limitation as a technical limitation rather 159 than as one precluded by the desires of the service (i.e. 160 traditionally there has been no special indication of this from the 161 public network). Without such an indication one would have to rely 162 on calling line identity, which would need to be reliable and 163 trusted, to avoid a false indication that this is a private network 164 internal call when it is in fact someone wishing to use that 165 indication for fraudulent purposes. There may be a need for such a 166 explicit indication, but that is not covered by this document. 168 Rather private network indication as proposed by this document is an 169 indication to each and every network element traversed that this is 170 private network traffic as opposed to public network traffic. This 171 indication is not for the end user on the private network. It is an 172 indication that special service arrangements apply for an enterprise, 173 and therefore it is an indication of service on behalf of an 174 enterprise, not an indication of service to an end private network 175 (NGCN) user. 177 In order to allow NGN IMS nodes to perform different processing ETSI 178 TISPAN formulated the following requirements on NGN: 179 1. The NGN shall distinguish public network traffic from private 180 network traffic. 181 2. The NGN shall distinguish private network traffic belonging to 182 one enterprise from that belonging to another enterprise. 184 To summarize a few example reasons for a public telecommunication 185 network to make the distinction between the two types of traffic: 186 o Different regulations apply to the two types of traffic, most 187 notably lawful intercept requirements. Another example is 188 emergency calls may be handled differently depending on the type 189 of traffic. 190 o Different charging regimes may apply. 191 o Call recording for business reasons (e.g. quality control, 192 training, non-repudiation) might apply only to a specific type of 193 traffic. 194 o Different levels of signalling and/or media transparency may apply 195 to the different types of traffic. 197 The indication is not regarded as appropriate as an indication from 198 the end UA attached to an NGCN or hosted enterprise service equipment 199 in the NGN. In this case any mixture of traffic from the same device 200 relates to two or more distinct users, one belonging to the 201 enterprise network and receiving service from that enterprise 202 network, and one belonging to the NGN and receiving service from that 203 network. Any distinction between the traffic types from such a 204 device should be based on the authentication performed. 206 There are several reasons why there is a need for an explicit 207 indication in the signalling: 208 1. As calling and target addresses can not in all cases be used to 209 determine whether a certain call is to be treated as private or 210 public network traffic. 211 2. Separate nodes in the network need to be able to act on the type 212 of traffic being handled, when implicit schemes would be used it 213 would require distribution of such enterprise specific logic over 214 multiple nodes of multiple operators. That is clearly not a 215 manageable architecture. 216 3. There may be cases where treating the call as a public network 217 call although both participants are from the same enterprise is 218 advantageous to the enterprise. 220 Given the above background this document will formulate requirements 221 on SIP for support of an explicit private network indication. 223 2. Conventions 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in BCP 14, RFC 2119 228 [RFC2119]. 230 3. Definitions 232 3.1. Public network traffic 234 Traffic sent to or received from a public telecommunication network 235 for processing according to the normal rules. 237 3.2. Private network traffic 239 Traffic sent to or received from a public telecommunication network 240 for processing according to an agreed set of rules specific to an 241 enterprise or a community of closely related enterprises. 243 3.3. Trust domain 245 The term Trust Domain in this document is taken from RFC3324 246 [RFC3324]. A trust domain applies to the private network indication. 247 The rules for specifying such a trust domain are specified in RFC3324 248 [RFC3324] which require the filling out a Spec (T). 250 The Spec (T) need not specify the same contents and trust domain 251 boundaries that are used for other headers like the P-Asserted- 252 Identity. 254 4. Application of terminology 256 Figure 1 shows the interconnection of sites belonging to two 257 enterprise networks using the public network. Traffic in the public 258 network relating to the interconnection of the two sites of 259 enterprise 1 are tagged as private network traffic relating to 260 enterprise 1. In certain cases an enterprise can also choose to send 261 traffic from one enterprise site to another enterprise site as public 262 network traffic when this is beneficial to the enterprise. Traffic 263 in the public network relating to the interconnection of the two 264 sites of enterprise 2 are tagged as private network traffic relating 265 to enterprise 2. Enterprise 1 also generates traffic to public 266 phones and this is public network traffic (untagged in the public 267 network). 269 +------------------------------+ 270 | private network | 271 +------------+ |<===========traffic==========>| +------------+ 272 | enterprise | | (enterprise 1) | | enterprise | 273 | 1 +-----+------------------------------+-----+ 1 ! 274 | site 1 | | | | site 2 | 275 +------------+ | +---+-----| | 276 | public | | | | 277 /--\ |<=========network========>| | +------------+ 278 o /\ o | traffic | | 279 / \----------+--------------------------+ | 280 +----+ | | 281 public | | 282 phone | | 283 | private network | 284 +------------+ |<===========traffic==========>| +------------+ 285 | enterprise | | (enterprise 2) | | enterprise | 286 | 2 +-----+------------------------------+-----+ 2 ! 287 | site 1 | | | | site 2 | 288 +------------+ | | +------------+ 289 | | 290 +------------------------------+ 292 Figure 1 294 Figure 2 shows the interconnection of sites belonging to an 295 enterprise networks using the public network, and supported in the 296 public network by a server providing a business trunking application. 297 The business trunking application providing routeing capabilities for 298 the enterprise traffic, and supports the identification of calls to 299 and from public network users, break-in and break out of that 300 traffic. (Note that the business trunking application may consist of 301 a concatenation of application logic provided to the originating 302 enterprise site and application logic that is provided to the 303 terminatig enterprise site.) Traffic in the public network relating 304 to the interconnection of the two sites of enterprise 1 are tagged as 305 private network traffic relating to enterprise 1. The business 306 trunking application also routes traffic to public phones and this is 307 public network traffic (untagged in the public network). 309 +-------------------------------------------------+ 310 | private network | 311 +------------+ |<===========traffic============>+------------+ | 312 | enterprise | | (enterprise 1) | | | 313 | 1 +-----+--------------------------------+ | | 314 | site 1 | | | business | | 315 +------------+ | +-----+ trunking | | 316 | public | | application| | 317 /--\ |<=========network========>| +--+ | | 318 o /\ o | traffic | | | | | 319 / \----------+--------------------------+ | | | | 320 +----+ | | +------------+ | 321 public | | | 322 phone | | | 323 | private network | | 324 +------------+ |<===========traffic=========>| | 325 | enterprise | | (enterprise 1) | | 326 | 1 +-----+-----------------------------+ | 327 | site 2 | | | 328 +------------+ | | 329 | | 330 +-------------------------------------------------+ 332 Figure 2 334 Figure 3 shows the interconnection of a site belonging to an 335 enterprise network to a server providing a hosted enterprise service 336 application (also known as Centrex). The hosted enterprise service 337 application supports phones belonging to the enterprise and is also 338 able to route traffic to or from public network phones using break-in 339 or break-out functionality. Traffic in the public network relating 340 to the interconnection of the site of enterprise 1 and the hosted 341 enterprise service belonging to enterprise 1 are tagged as private 342 network traffic relating to enterprise 1. The hosted enterprise 343 service application also routes traffic to public phones and this is 344 public network traffic (untagged in the public network). Traffic 345 from the enterprise phones would not normally be tagged (such a tag 346 is added at the server providing the hosted enterprise services 347 application. (Note that the hosted enterprise service logic may be 348 preceded or subseded by a business trunking application that offers 349 services on behalf of an enterprise site.) 350 +-------------------------------------------------+ 351 | private network | 352 +------------+ |<===========traffic============>+------------+ | 353 | enterprise | | (enterprise 1) | | | 354 | 1 +-----+--------------------------------+ hosted | | 355 | site 1 | | | enterprise | | 356 +------------+ | +-----+ service | | 357 | public | | enterprise | | 358 /--\ |<=========network========>| +--+ 1 | | 359 o /\ o | traffic | | | | | 360 / \----------+--------------------------+ | | | | 361 +----+ | | +------------+ | 362 public | | | 363 phone | | | 364 | private network | | 365 /--\ |<===========traffic=========>| | 366 o /\ o | (enterprise 1) | | 367 / \----------+-----------------------------+ | 368 +----+ | | 369 enterprise | | 370 phone | | 371 +-------------------------------------------------+ 373 Figure 3 375 5. Requirements 377 This section lists the requirements on SIP derived from consideration 378 in Section 1: 379 R1: It is REQUIRED that an indication can be send in SIP initial 380 requests for a dialog or SIP standalone requests that indicates 381 that the request or associated session is to be treated 382 according to the rules of private network traffic. 383 R2: The indication from R1 can be inserted by a SIP proxy belonging 384 to an administrative entity where for onward routeing, the 385 traffic within that administrative entity needs to be so 386 distinguished. The indication is not needed where the traffic 387 is assumed to be all public, or where the traffic is assumed to 388 be all private. 389 R3: The indication from R1 can be removed by a SIP proxy belonging 390 to an administrative entity where for onward routeing, the 391 traffic no longer needs to be so distinguished. An example 392 exists where the traffic reaches an NGCN site where the traffic 393 is now assumed to all private network traffic. Another example 394 is on the final hop to the UA. 396 R4: It is REQUIRED that the indication from R1 allows entities to 397 determine the set of rules that are applicable, these rules may 398 be enterprise specific. 399 R5: It is REQUIRED that the indication from R1 allows entities 400 receiving it to distinguish private network traffic from 401 different enterprises. 402 R6: The identifier to distinguish private network traffic belonging 403 to one enterprise from that belonging to another enterprise must 404 be globally unique. Business communication arrangements for any 405 particular enterprise can be expected to span multiple NGN 406 operators potentially in multiple countries. 407 R7: The indication from R1 relates primarily to the SIP signaling. 408 Applying the same concept to media may be possible, but is not 409 necessarily meaningful where media is routed differently from 410 signalling. 412 6. Overview of solution 414 The mechanism proposed in this document relies on a new header field 415 called 'Private-Network-Indication' that contains an private network 416 identifier expressed as a domain name, for example: 418 P-Private-Network-Indication: ericsson.com 420 A proxy server which handles a message can, based on authentication 421 of the source of a message and configuration or local policy, insert 422 such a Private-Network-Indication header field into the message and 423 forward it to other trusted proxies to be handled as private network 424 traffic. A proxy that is about to forward a message to a proxy 425 server or UA that it does not trust MUST remove the Private-Network- 426 Indication header. 428 The private network identifier expressed as a domain name allows it 429 to be globally unique identifier associated with the enterprise. 430 Domain name is used as it allows reuse of a company owned internet 431 domain name, without requiring an additional private network 432 identifier registry. When the enterprise needs more then one 433 identifier it can freely add subdomains that it has under its own 434 control. 436 The formal syntax for the Private-Network-Indication header is 437 presented in Section 8. 439 7. Behaviour 441 7.1. UA behaviour 443 Use of this extension by UA's is not foreseen. Therefore there is no 444 particular UA behaviour specified in connection to the Private- 445 Network-Indication header field. 447 7.2. Proxy behaviour 449 7.2.1. Private-Network-Indication generation 451 Proxies that are responsible for determining certain traffic is to be 452 treated as private network traffic or contain a breakin function that 453 converts incoming public network traffic to private network traffic 454 MUST insert a Private-Network-Indication header field in to requests 455 for a dialog or requests for a standalone transaction where the value 456 MUST be set to the private network identifier corresponding to the 457 enterprise to which the traffic belongs. 459 7.2.2. Private-Network-Indication consumption 461 Proxies that are responsible for applying different processing 462 behaviours to specific private network traffic as to public network 463 traffic MUST support this extension. The Private-Network-Indication 464 header MUST NOT be used by a proxy in case it is received on a 465 request it received from an entity that it does not trust, in such 466 case it MUST be removed before the request is forwarded. 468 7.2.3. Private-Network-Indication removal 470 Proxies that are at the edge of the trustdomain or contain a breakout 471 function that converts incoming private network traffic to public 472 network traffic MUST remove the Private-Network-Indication header 473 field before forwarding a request that contains such a header with a 474 value. 476 8. P-Private-Network-Indication header field definition 478 This document defines the SIP P-Private-Network-Indication header. 479 This header field can be added by a proxy to initial requests for a 480 dialog or standalone requests. The presence of the P-Private- 481 Network-Indication header field signifies to proxies that understand 482 this header field that the request is to be treated as private 483 network traffic. The P-Private-Network-Indication header field 484 contains a domain name value that allows the private network traffic 485 to be associated with an enterprise to which it belongs and that 486 allow proxies that understand this header to process the request 487 according to the request processing behaviours configured for a 488 specific enterprise. 490 The augmented Backus-Naur Form (BNF) (RFC5234 [RFC5234]) syntax of 491 the P-Private-Network-Indication header field is the following: 493 P-Private-Network-Indication = 494 "P-Private-Network-Indication" HCOLON PNI-value 495 *(SEMI PNI-param) 496 PNI-param = generic-param 497 PNI-value = hostname 499 EQUAL, HCOLON, SEMI, hostname and generic-param are defined in 500 RFC3261 [RFC3261]. 502 The following is an example of a P-Private-Network-Indication header 503 field: 505 P-Private-Network-Indication: ericsson.com 507 9. Security considerations 509 The private network indication being defined in this document is to 510 be used in an environment where elements are trusted and where 511 attackers are not supposed to have access to the protocol messages 512 between those elements. Traffic protection between network elements 513 is sometimes achieved by using IPsec and sometimes by physically 514 protecting the network. In any case, the environment where the 515 private network indication will be used ensures the integrity and the 516 confidentiality of the contents of this header field. 518 A private network indication received from an untrusted node MUST NOT 519 be used and the information MUST be removed from a request or 520 response before it is forwarded to entities in the trust domain. 522 There is a security risk if a private network indication is allowed 523 to propagate out of the trust domain where it was generated. In that 524 case sensitive information would be revealed by such a breach. To 525 prevent such a breach from happening: Proxies MUST NOT insert the 526 information when forwarding requests to a next hop located outside 527 the trust domain. When forwarding the request to a trusted node, 528 proxies MUST NOT insert the header unless they have sufficient 529 knowledge that the route set includes another proxy in the trust 530 domain that understands the header, such as the own proxy. There is 531 no automatic mechanism to learn the support for this specification. 532 Proxies MUST remove the information when forwarding requests to 533 untrusted nodes or when the proxy does not have knowledge of any 534 other proxy in the route set that is able to understand the header. 536 10. Applicability 538 According to RFC 3427 [RFC3427], P-headers have a limited 539 applicability. Specifications of P-headers such as this RFC need to 540 clearly document the useful scope of the proposal, and explain its 541 limitations and why it is not suitable for the general use of SIP on 542 the Internet. 544 The P-Private-Network-Indication header field is intended to be used 545 in controlled closed networks like 3GPP IMS and ETSI TISPAN NGN 546 networks. The P-Private-Network-Indication header field does not 547 seem useful in a general internet environment. 549 11. IANA considerations 551 This document defines a new SIP header field: P-Private-Network- 552 Indication. This header field needs to be registered by the IANA in 553 the SIP Parameters registry under the Header Fields subregistry. 555 12. Acknowledgments 557 The authors thank Bruno Chatras, John Elwell and Salvatore Loreto for 558 providing comments on an early version of this draft. 560 13. References 562 13.1. Normative references 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 568 A., Peterson, J., Sparks, R., Handley, M., and E. 569 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 570 June 2002. 572 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 573 Identity", RFC 3324, November 2002. 575 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 576 and B. Rosen, "Change Process for the Session Initiation 577 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 579 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 580 Specifications: ABNF", STD 68, RFC 5234, January 2008. 582 13.2. Informative references 584 [ETSI.181.019] 585 ETSI, "Telecommunication and Internet converged Services 586 and Protocols for Advanced Networking (TISPAN); Business 587 Communication Requirements", ETSI TS 181 019 V2, 588 July 2007. 590 [3GPP.23.228] 591 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 592 TS 23.228 V8. 594 [3GPP.24.229] 595 3GPP, "Internet Protocol (IP) multimedia call control 596 protocol based on Session Initiation Protocol (SIP) and 597 Session Description Protocol (SDP); Stage 3", 3GPP 598 TS 24.229 V8. 600 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 601 Header (P-Header) Extensions to the Session Initiation 602 Protocol (SIP) for the 3rd-Generation Partnership Project 603 (3GPP)", RFC 3455, January 2003. 605 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 606 Preferences for the Session Initiation Protocol (SIP)", 607 RFC 3841, August 2004. 609 [I-D.drage-sipping-service-identification] 610 Drage, K., "A Session Initiation Protocol (SIP) Extension 611 for the Identification of Services", 612 draft-drage-sipping-service-identification-02 (work in 613 progress), October 2008. 615 Appendix A. Alternative solutions discussed 617 A.1. General 619 It would be technical possible, but extremely complex to perform this 620 function without an explicit indication. For example, a logical 621 distinction of proxies to handle private network traffic relating to 622 enterprise 1, enterprise 2 and the public network traffic could be 623 made by assigning different SIP URIs to these logical entities. This 624 is not regarded as a viable solution. 626 Several solutions have been raised and whether or not they are 627 suitable and fulfill the requirements need to be discussed: 628 o Attribute on existing header? 629 o Token on some existing header? 630 o Resource-Priority header? 631 o P-Asserted-Service header? 632 o Request-Disposition header? 633 o P-Access-Network-Information header? 634 o URI parameter? 635 o New P-header? 636 o New header? 638 A.2. Attribute on existing header 640 A.3. Token value on existing header 642 A.4. Resource-Priority header 644 Some of the distinctive functions are already provided for in this 645 header. A potential mechanism would be to define a namespace for 646 private network traffic. It would however be impossible to define a 647 namespace for each enterprise, and therefore some additional 648 parameter would need to be defined to carry the unique identifier of 649 the particular enterprise to which the private network traffic 650 relates. Successful usage may also require a tightening of the 651 procedures for use of the Resource-Priority header (much at the 652 moment is left to the particular application of this header). 654 Private network traffic may, but is not necessarily handled with a 655 different priority then public network traffic. Use of the Resource- 656 Priority header however seems to imply that the main focus of the 657 indication is on prioritizing private network traffic. This may 658 render use of the Resource-Priority header as less appropriate for 659 our particular purpose. 661 A.5. P-Asserted-Service header 663 The services envisaged by the P-Asserted-Service header field 664 (draft-drage-sipping-service-identification 665 [I-D.drage-sipping-service-identification]) are those applied to the 666 end user. The end user in these cases is the end user of the 667 enterprise or NGCN, not the enterprise itself. Therefore this header 668 is not considered suitable for this problem. 670 A.6. Request-Disposition header 672 The Request-Disposition header field (RFC3841 [RFC3841]) specifies 673 caller preferences for how a server should process a request. The 674 caller in these cases is the end user of the enterprise or NGCN, not 675 the enterprise itself. Therefore this header is not considered 676 suitable for this problem. Further RFC3841 explicitly states that 677 the set of request disposition directives is not extensible. 679 A.7. P-Access-Network-Information 681 The P-Access-Network-Info header field (RFC3455 [RFC3455]) contains 682 information about the access network that a UA uses to get IP 683 connectivity. However the access that one uses does not define the 684 private network that a call that one sets up is to be part of. 686 Particular examples that illustrate this: 687 o A Hosted Enterprise Services user (i.e. Centrex) uses the access 688 of the operator while still being able to setup calls that will 689 turn out to be private network traffic. 690 o A corporate network UE that attaches to an operator network, but 691 receives services from its home corporate network. 693 A.8. URI parameter 695 A marking on the entities within the Via header that are treating 696 this as private network traffic. Potential marking on the route 697 header of entities that are expected to treat it as private network 698 traffic. 700 A.9. New header 702 A.9.1. General 704 If none of the existing headers is appropriate a logical step is to 705 define a new header for the private network indication. 707 A.9.2. Full SIP header field 709 A full SIP header is appropriate when the usage of this information 710 element is more general then closed networks like ETSI TISPAN NGN or 711 3GPP IMS. 713 A.9.3. New P-header 715 In case no general usage is foreseen other then usage in closed 716 networks like those specified by ETSI TISPAN NGN or 3GPP IMS a 717 P-header seems the appropriate choice. 719 Appendix B. Revision Information 721 B.1. version 00 722 1. 2008-02-18, Initial version 724 B.2. version 01 725 1. 2008-02-23, Added a solution based on a new header. Added 726 Overview, Behaviour and Header Definition sections. Updated the 727 trust domain definition. Improved some of the existing text 728 based on comments from John Elwell. 730 B.3. version 02 731 1. 2008-07-11, Changed to a P-header. Changed title. Added 732 Terminology application and Applicability sections. Moved the 733 Potential solutions section to appendix Alternative solutions 734 discussed. 736 B.4. version 03 737 1. 2009-02-19, Updated boilerplate. 739 Authors' Addresses 741 Hans Erik van Elburg 742 Ericsson Telecommunicatie B.V. 743 Ericssonstraat 2 744 Rijen 5121 ML 745 The Netherlands 747 Email: HansErik.van.Elburg@ericsson.com 749 Keith Drage 750 Alcatel-Lucent 751 The Quadrant, Stonehill Green, Westlea 752 Swindon SN5 7DJ 753 UK 755 Email: drage@alcatel-lucent.com