| ECRIT | J. Winterbottom |
| Internet-Draft | Winterb Consulting Services |
| Updates: RFC6881, RFC5985 (if approved) | H. Tschofenig |
| Intended status: Standards Track | |
| Expires: January 22, 2016 | L. Liess |
| Deutsche Telekom | |
| July 21, 2015 |
A Routing Request Extension for the HELD Protocol
draft-ietf-ecrit-held-routing-03.txt
For cases where location servers have access to emergency routing information they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HELD protocol to support this funciton.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 22, 2016.
Copyright (c) 2015 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.
The general ECRIT calling models described in [RFC6443] and [RFC6881]require a local LoST server or network of forest guides in order to determine the address of the PSAP in the best position to handle a call. Networks of forest guides have not eventuated and while PSAPs are moving towards IP networks, LoST server deployment is not ubiquitous. Some regions and countries have expressed reluctance to deploy LoST servers making aspects of the current ECRIT architecture hard to realize.
Evolving architectures in Europe to address regulatory requirements, such as [M493], couple location and routing information in the access network whilst using a softswitch-centric approach to emergency call processing. This document describes adding an extension to the HELD protocol [RFC5985] so that a location information server can provide emergency routing information in the absence of a LoST server or network of forest guides.
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].
The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].
The term "Access Network Provider" is used as defined in [RFC5687] and incompasses both the Internet Access Provider (IAP) and Internet Service Provider (ISP).
The Internet emergency calling architecture specified in [RFC6881] describes two main models for emergency call processing. The first is a device-centric model, where a device obtains location information using a location configuration protocol, such a HELD [RFC5985], and then proceeds to determine the address of the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this model in a simplified form.
+---Location Request---+
| (1) |
+---+----+ +---V---+
| |<--Location--| LIS |
| Caller | (2) +-------+ +--------+
| | | ESRP/ |
| |----Find Service-------+ | PSAP |
+------^-+ (3) | +--------+
| | +--------V----+ ^
| +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP |
(5) +-------+
Figure 1: Device-Centric Emergency Services Model
The second approach is a softswitch-centric model, where a device initiates an emergency call and the serving softswitch detects that the call is an emergency and initiates retrieving the caller's location from a Location Information Server (LIS) using HELD [RFC5985] with identity extensions [RFC6155] [RFC6915] and then determining the route to the local PSAP using LoST [RFC5222]. Figure 2 shows the high-level protocol interactions.
+---Location Request---+
| (2) |
+---V---+ |
| LIS | |
+----+--+ +----+----+
| | |
+----Location--->| Soft |
+--------+ (3) | Switch |
| Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+
+-------------+ | | |
| LoST Server |<-Find Service--+ | |
+------+------+ (4) | |
| | |
+----------Service--------+ |
(5) |
+-----------+ |
| ESRP/PSAP |<------Call----+
+-----------+ (6)
Figure 2: Softswitch-Centric Calling Model
In the softswitch-centric model when a VSP receives an emergency call it performs two tasks. The first task is to determine the correct LIS to ask for location information, this is done using a combination of reverse DNS lookup described in [RFC7216] to acquire the serving domain name and then using [RFC5986] to determine the LIS URI. Once the location is obtained from the LIS, the VSP determines the LoST server associated with the domain serving the caller and queries it for the correct PSAP address.
LoST server discovery is a domain based activity, similar to the LIS discovery technique. However, unlike the LIS that is a domain bound service, a LoST server is a geographically bound service. This means that for a domain that spans multiple geographic regions the LoST server determined may not be able to provide a route to the necessary PSAP. When this occurs, the contacted LoST server invokes the help of other LoST servers and this requires the deployment of forest guides.
At the time of writing, several countries have expressed a reluctance to deploy public LoST servers. In countries amenable to the use of LoST and forest guides no public forest guides have been deployed. There appears little interest from the public sector in establishing a global forest guide network. These issues pose threats to both the device-centric and the softswitch-centric calling approaches in terms of them operating everywhere.
The device-centric and softswitch-centric calling models both involve the notion of a LIS bound to the serving access network. In many cases the LIS already knows the destination PSAP URI for any given location. In [RFC6881] for example, the LIS validates civic locations using a location validation procedure based on the LoST protocol [RFC5222]. The LoST validation request is similar to a LoST routing request and provides the LIS with the same PSAP routing information that a routing request would. In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider. Irrespective of the way in which the LIS learns the PSAP URI for a location, the LIS will, in a great many cases, already have this information.
This document specifies an extension to the HELD protocol so that emergency routing information can be requested from the LIS at the same time that location information is requested. The document updates [RFC6881] by requiring devices and softswitches that understand this specification to always request routing information to avoid the risk of query failure where no LoST server or forest guide network is deployed.
The LoST Protocol [RFC5222] defines a <mapping> element that describes a service region and associated service URLs. Reusing this element from LoST to provide the routing URIs was considered. However, this would have meant that several of the mandatory components in the <mapping> element would have had to contain ambiguous or misleading values. Specifically, the "source" attribute is required to contain a LoST application unique string for the authoritative server. However, in the situations described in this specification there may not be an authoritative LoST server, so any value put into this attribute would be misleading. In addition to this, routing information received in the manner described in this specification should not be cached by the receiver, so detailing when the routing information expires or was last updated is irrelevant.
The mechanism consists of adding an element to the HELD locationRequest and an element to the locationResponse.
The request element indicates that the requestor wants the LIS to provide routing information based on the location of the end-device. If the routing request is sent with no attribute then URIs for urn:service:sos are returned. If the requestor wants routing information for a specific service then they may include an optional service URN. If a service is specified, and the LIS does not understand the requested service then URIs for urn:service:sos are returned.
If the LIS understands the routing request and has routing information for the location then it includes the information in a routingInformation element returned in the locationResponse. How the LIS obtains this information is left to implementation, one possible option is that the LIS acquires it from a LoST server, other possibilities are described in Section 3.
A LIS that does not understand the routing request element ignores it and returns location as normal.
A LIS that does support the routing request element MUST support returning URIs for urn:service:sos and any regionally defined sub-services while following the URN traversal rules defined in [RFC5031].
A LIS that does understand the routing request element but can't obtain any routing information for the end-device's location MUST only return location information.
A LIS that understands the routing request element but not the specified service URN, MUST follow the URN traversal rules defined in [RFC5031].
A LIS that receives a request for emergency routing information that it understands MUST return the correct emergency routing information if it has or is able to acquire the routing information for the location of the target device.
The routing information in the location response consists of a service element identified by a service name. The service name is a urn and might contain a general emergency service urn such as urn:service:sos or might contain a specific service urn depending on what was requested and what the LIS is able to provide. A list of one or more service destinations is provided for the service name. Each destination is expressed as a URI and each URI scheme should only appear once in this list. The routing URIs are intended to be used at the time they are received. To avoid any risks of using stale routing URIs the values MUST NOT be cached by the receiving entity.
This section describes the schema extension to HELD.
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="requestRoutingInformation">
<xs:complexType name="empty">
<xs:attribute name="service" type="xs:anyUri"
use="optional" default="urn:service:sos"/>
</xs:complexType>
</xs:element>
<xs:complexType name="service">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="dest" type="xs:anyURI"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serviceUri" type="xs:anyURI"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="routingInformation" type="ri:riType"/>
<xs:complexType name="riType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="service" type="ri:service"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Figure 3 illustrates a <locationRequest> example that contains IP flow information in the request.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="emergencyRouting"> <requestRoutingInformation xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/> <flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow" layer4="tcp" layer3="ipv4"> <src> <address>192.168.1.1</address> <port>1024</port> </src> <dst> <address>10.0.0.1</address> <port>80</port> </dst> </flow> </locationRequest>
Figure 3: Example Location Request.
Figure 4 illustrates the <locationResponse> message containing two location URIs: a HTTPS and a SIP URI. Additionally, the response contains routing information.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
<routingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest>
</service>
</routingInformation>
</locationResponse>
Figure 4: Example Location Response
This document makes no changes that require privacy considerations beyond those already described in [RFC5687]. It does however extend those described in [RFC6155].
[RFC5687] describes the issues surrounding Layer 7 location configuration protocols, which this document makes no specific changes to.
[RFC6155] extends HELD beyond a simple LCP by enabling authorized third-parties to acquire location information and describes the issues in Section 4. The HELD Routing extension supports returning URIs that represent specific services operating in the Target's vicinity. This represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.
This document imposes no additional security considerations beyond those already described in [RFC5687] and [RFC6155].
This document calls for IANA to register a new XML namespace, as per the guidelines in [RFC3688].
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Routing Information Extensions</title>
</head>
<body>
<h1>Additional Element for HELD Routing Information</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the procedures in [RFC3688].
We would like to thank Wilfried Lange for sharing his views with us. We would also like to thank Bruno Chatras for his early review comments and Keith Drage ofr his more detailed review. Thanks to Roger Marshall and Randy Gellens for their helpful suggestions.
| [M493] | European Telecommunications Standards Institute, "Functional architecture to support European requirements on emergency caller location determination and transport", ES 203 178, V 1.0.5, December 2014. |
| [RFC5986] | Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010. |
| [RFC6155] | Winterbottom, J., Thomson, M., Tschofenig, H. and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March 2011. |
| [RFC6915] | Bellis, R., "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, April 2013. |
| [RFC7216] | Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, DOI 10.17487/RFC7216, April 2014. |