idnits 2.17.1 draft-ietf-ecrit-held-routing-01.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2015) is 3332 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) ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft Winterb Consulting Services 4 Updates: RFC6881, RFC5985 H. Tschofenig 5 (if approved) 6 Intended status: Standards Track L. Liess 7 Expires: September 8, 2015 Deutsche Telekom 8 March 7, 2015 10 A Routing Request Extension for the HELD Protocol 11 draft-ietf-ecrit-held-routing-01.txt 13 Abstract 15 In many circumstances public LoST servers or a distributed network of 16 forest guides linking public LoST servers is not available. The 17 general ECRIT calling models breakdown without publically accessible 18 LoST servers. Sometimes location servers may have access to 19 emergency routing information. This document defines an extension to 20 the HELD protocol so a location request can include a request for 21 routing information and allowing the subsequent location response to 22 include routing information. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 8, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 63 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. URN sub-namespace registration for 68 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 10 69 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The general ECRIT calling models described in [RFC6443] and 79 [RFC6881]require a local LoST server or network of forest guides in 80 order to determine the address of the PSAP in the best position to 81 handle a call. Networks of forest guides have not eventuated and 82 while PSAPs are moving towards IP networks, LoST server deployment is 83 not ubiquitous. Some regions and countries have expressed reluctance 84 to deploy LoST servers making aspects of the current ECRIT 85 architecture hard to realize. 87 Evolving architectures in Europe to address regulatory requirements, 88 such as [M493], couple location and routing information in the access 89 network whilst using a softswitch-centric approach to emergency call 90 processing. This document describes adding an extension to the HELD 91 protocol [RFC5985] so that a location information server can provide 92 emergency routing information in the absence of a LoST server or 93 network of forest guides. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 103 The term "Access Network Provider" is used as defined in [RFC5687] 104 and incompasses both the Internet Access Provider (IAP) and Internet 105 Service Provider (ISP). 107 3. Motivation 109 The Internet emergency calling architecture specified in [RFC6881] 110 describes two main models for emergency call processing. The first 111 is a device-centric model, where a device obtains location 112 information using a location configuration protocol, such a HELD 113 [RFC5985], and then proceeds to determine the address of the next hop 114 closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 115 model in a simplified form. 117 +---Location Request---+ 118 | (1) | 119 +---+----+ +---V---+ 120 | |<--Location--| LIS | 121 | Caller | (2) +-------+ +--------+ 122 | | | ESRP/ | 123 | |----Find Service-------+ | PSAP | 124 +------^-+ (3) | +--------+ 125 | | +--------V----+ ^ 126 | +-----Service----| LoST Server | | 127 | (4) +-------------+ +---+---+ 128 +-------------Call Initiation------------>| VSP | 129 (5) +-------+ 131 Figure 1: Device-Centric Emergency Services Model 133 The second approach is a softswitch-centric model, where a device 134 initiates and emergency call and the serving softswitch detects that 135 the call is an emergency and initiates retrieving the caller's 136 location from a Location Information Server (LIS) using HELD 137 [RFC5985] with identity extensions [RFC6155] [RFC6915] and then 138 determining the route to the local PSAP using LoST [RFC5222]. 139 Figure 2 shows the high-level protocol interactions. 141 +---Location Request---+ 142 | (2) | 143 +---V---+ | 144 | LIS | | 145 +----+--+ +----+----+ 146 | | | 147 +----Location--->| Soft | 148 +--------+ (3) | Switch | 149 | Caller |------Call Initiation------------> | | 150 +--------+ (1) +-+-^---+-+ 151 +-------------+ | | | 152 | LoST Server |<-Find Service--+ | | 153 +------+------+ (4) | | 154 | | | 155 +----------Service--------+ | 156 (5) | 157 +-----------+ | 158 | ESRP/PSAP |<------Call----+ 159 +-----------+ (6) 161 Figure 2: Softswitch-Centric Calling Model 163 In the softswitch-centric model when a VSP receives an emergency call 164 it performs two tasks. The first task is to determine the correct 165 LIS to ask for location information, this is done using a combination 166 of reverse DNS lookup described in [RFC7216] to acquire the serving 167 domain name and then using [RFC5986] to determine the LIS URI. Once 168 the location is obtained from the LIS, the VSP determines the LoST 169 server associated with the domain serving the caller and queries it 170 for the correct PSAP address. 172 LoST server discovery is a domain based activity, similar to the LIS 173 discovery technique. However, unlike the LIS that is a domain bound 174 service, a LoST server is a geographically bound service. This means 175 that for a domain that spans multiple geographic regions the LoST 176 server determined may not be able to provide a route to the necessary 177 PSAP. When this occurs, the contacted LoST server invokes the help 178 of other LoST servers and this requires the deployment of forest 179 guides. 181 At the time of writing, several countries have expressed a reluctance 182 to deploy public LoST servers. In countries amenable to the use of 183 LoST and forest guides no public forest guides have been deployed. 184 There appears little interest from the public sector in establishing 185 a global forest guide network. These issues pose threats to both the 186 device-centric and the softswitch-centric calling approaches in terms 187 of them operating everywhere. 189 The device-centric and softswitch-centric calling models both involve 190 the notion of a LIS bound to the serving access network. In many 191 cases the LIS already knows the destination PSAP URI for any given 192 location. In [RFC6881] for example, the LIS validates civic 193 locations using a location validation procedure based on the LoST 194 protocol [RFC5222]. The LoST validation request is similar to a LoST 195 routing request and provides the LIS with the same PSAP routing 196 information that a routing request would. In other cases, the LIS 197 knows the correct PSAP for a given location at provisioning time, or 198 the access network might always route to the same emergency provider. 199 Irrespective of the way in which the LIS learns the PSAP URI for a 200 location, the LIS will, in a great many cases, already have this 201 information. 203 This document specifies an extension to the HELD protocol so that 204 emergency routing information can be requested from the LIS at the 205 same time that location information is requested. The document 206 updates [RFC6881] by requiring devices and softswitches that 207 understand this specification to always request routing information 208 to avoid the risk of query failure where no LoST server or forest 209 guide network is deployed. 211 4. Mechanism 213 The mechanism consists of adding an element to the HELD 214 locationRequest and an element to the locationResponse. 216 The request element indicates that the requestor wants the LIS to 217 provide routing information based on the location of the end-device. 218 If the routing request is sent with no attribute then URIs for 219 urn:service:sos are returned. If the requestor wants routing 220 information for a specific service then they may include an optional 221 service URN. If a service is specified, and the LIS does not 222 understand the requested service then URIs for urn:service:sos are 223 returned. 225 If the LIS understands the routing request and has routing 226 information for the location then it includes the information in a 227 routingInformation element returned in the locationResponse. How the 228 LIS obtains this information is left to implementation, one possible 229 option is that the LIS acquires it from a LoST server, other 230 possibilities are described in Section 3. 232 A LIS that does not understand the routing request element ignores it 233 and returns location as normal. 235 A LIS that does support the routing request element SHALL support 236 returning URIs for urn:service:sos 238 A LIS that does understand the routing request element but can't 239 obtain any routing information for the end-device's location SHALL 240 only return location information. 242 A LIS that understands the routing request element but not the 243 specified service URN, returns the routing URIs for the 244 urn:service:sos service. 246 The routing information in the location response consists of a 247 service element identified by a service name. The service name is a 248 urn and might contain a general emergency service urn such as 249 urn:service:sos or might contain a specific service urn depending on 250 what was requested and what the LIS is able to provide. A list of 251 one or more service destinations is provided for the service name. 252 Each destination is expressed as a URI and each URI scheme should 253 only appear once in this list. The routing URIs are intended to be 254 used at the time they are received. To avoid any risks of using 255 stale routing URIs the values MUST NOT be cached by the receiving 256 entity. 258 The LoST Protocol [RFC5222] defines a element that 259 describes a service region and associated service URLs. Reusing this 260 element from LoST to provide the routing URIs was considered. 261 However, this would have meant that several of the mandatory 262 components in the element would have had to contain 263 ambiguous or misleading values. Specifically, the "source" attribute 264 is required to contain a LoST application unique string for the 265 authoritative server. However, in the situations described in this 266 specification there may not be an authoritative LoST server, so any 267 value put into this attribute would be misleading. In addition to 268 this, routing information received in the manner described in this 269 specification should not be cached by the receiver, so detailing when 270 the routing information expires or was last updated is irrelevant. 272 5. HELD Schema Extension 274 This section describes the schema extension to HELD. 276 277 284 285 286 288 289 291 292 293 294 295 297 298 300 301 302 304 305 306 307 308 309 310 312 313 314 315 316 318 320 6. Examples 322 Figure 3 illustrates a example that contains IP 323 flow information in the request. 325 328 331 333 334
192.168.1.1
335 1024 336 337 338
10.0.0.1
339 80 340 341 342 344 Figure 3: Example Location Request. 346 Figure 4 illustrates the message containing two 347 location URIs: a HTTPS and a SIP URI. Additionally, the response 348 contains routing information. 350 351 352 353 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 354 355 356 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 357 358 360 362 363 sip:112@example.com 364 sips:112@example.com 365 xmpp:112@example.com 366 367 369 371 Figure 4: Example Location Response 373 7. Privacy Considerations 375 This document makes no changes that require privacy considerations 376 beyond those already described in [RFC5985] and [RFC6155]. 378 8. Security Considerations 380 This document imposes no additional security considerations beyond 381 those already described in [RFC5985] and [RFC6155]. 383 9. IANA Considerations 385 9.1. URN sub-namespace registration for 386 'urn:ietf:params:xml:ns:geopriv:held:ri' 388 This document calls for IANA to register a new XML namespace, as per 389 the guidelines in [RFC3688]. 391 URI: urn:ietf:params:xml:ns:geopriv:held:ri 393 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 394 James Winterbottom (a.james.winterbottom@gmail.com). 396 XML: 398 BEGIN 399 400 402 403 404 HELD Routing Information Extensions 405 406 407

Additional Element for HELD Routing Information

408

urn:ietf:params:xml:ns:geopriv:held:ri

409 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 410 with the RFC number for this specification.]] 411

See RFCXXXX.

412 413 414 END 416 9.2. XML Schema Registration 418 This section registers an XML schema as per the procedures in 419 [RFC3688]. 421 URI: urn:ietf:params:xml:schema:geopriv:held:ri 423 Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), 424 James Winterbottom (a.james.winterbottom@gmail.com). 426 The XML for this schema can be found as the entirety of Section 5 427 of this document. 429 10. Acknowledgements 431 We would like to thank Wilfried Lange for sharing his views with us. 432 We would also like to thank Bruno Chatras for his early review 433 comments and Bernd Henschel for his support. Thanks to Roger 434 Marshall and Randy Gellens for their helpful suggestions. 436 11. References 438 11.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 444 January 2004. 446 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 447 Tschofenig, "LoST: A Location-to-Service Translation 448 Protocol", RFC 5222, August 2008. 450 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 451 Location Configuration Protocol: Problem Statement and 452 Requirements", RFC 5687, March 2010. 454 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 455 RFC 5985, September 2010. 457 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 458 "Framework for Emergency Calling Using Internet 459 Multimedia", RFC 6443, December 2011. 461 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 462 Communications Services in Support of Emergency Calling", 463 BCP 181, RFC 6881, March 2013. 465 11.2. Informative References 467 [M493] European Telecommunications Standards Institute, 468 "Functional architecture to support European requirements 469 on emergency caller location determination and transport", 470 ES 203 178, V 1.0.5, December 2014. 472 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 473 Location Information Server (LIS)", RFC 5986, 474 September 2010. 476 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 477 Barnes, "Use of Device Identity in HTTP-Enabled Location 478 Delivery (HELD)", RFC 6155, March 2011. 480 [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled 481 Location Delivery (HELD)", RFC 6915, April 2013. 483 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 484 (LIS) Discovery Using IP Addresses and Reverse DNS", 485 RFC 7216, April 2014. 487 Authors' Addresses 489 James Winterbottom 490 Winterb Consulting Services 491 Gwynneville, NSW 2500 492 AU 494 Phone: +61 448 266004 495 Email: a.james.winterbottom@gmail.com 497 Hannes Tschofenig 498 Halls in Tirol 6060 499 Austria 501 Phone: 502 Email: Hannes.Tschofenig@gmx.net 503 URI: http://www.tschofenig.priv.at 505 Laura Liess 506 Deutsche Telekom Networks 507 Deutsche Telekom Allee 7 508 Darmstadt, Hessen 64295 509 Germany 511 Phone: 512 Email: L.Liess@telekom.de 513 URI: http://www.telekom.de