A Routing Request Extension for the HELD Protocol
draft-ietf-ecrit-held-routing-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (ecrit WG) | |
|---|---|---|---|
| Authors | James Winterbottom , Hannes Tschofenig , Laura Liess | ||
| Last updated | 2015-04-05 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
(of
-04)
Ready with Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ecrit-held-routing-02
ECRIT J. Winterbottom
Internet-Draft Winterb Consulting Services
Updates: RFC6881, RFC5985 H. Tschofenig
(if approved)
Intended status: Standards Track L. Liess
Expires: October 7, 2015 Deutsche Telekom
April 5, 2015
A Routing Request Extension for the HELD Protocol
draft-ietf-ecrit-held-routing-02.txt
Abstract
In many circumstances public LoST servers or a distributed network of
forest guides linking public LoST servers is not available. The
general ECRIT calling models breakdown without publically accessible
LoST servers. Sometimes location servers may have access to
emergency routing information. This document defines an extension to
the HELD protocol so a location request can include a request for
routing information and allowing the subsequent location response to
include routing information.
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
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 October 7, 2015.
Copyright Notice
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
Winterbottom, et al. Expires October 7, 2015 [Page 1]
Internet-Draft HELD Routing April 2015
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 10
9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Winterbottom, et al. Expires October 7, 2015 [Page 2]
Internet-Draft HELD Routing April 2015
1. Introduction
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.
2. Terminology
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).
Winterbottom, et al. Expires October 7, 2015 [Page 3]
Internet-Draft HELD Routing April 2015
3. Motivation
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 and 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.
Winterbottom, et al. Expires October 7, 2015 [Page 4]
Internet-Draft HELD Routing April 2015
+---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.
Winterbottom, et al. Expires October 7, 2015 [Page 5]
Internet-Draft HELD Routing April 2015
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.
4. Mechanism
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 SHALL support
Winterbottom, et al. Expires October 7, 2015 [Page 6]
Internet-Draft HELD Routing April 2015
returning URIs for urn:service:sos
A LIS that does understand the routing request element but can't
obtain any routing information for the end-device's location SHALL
only return location information.
A LIS that understands the routing request element but not the
specified service URN, returns the routing URIs for the
urn:service:sos service.
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.
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.
Winterbottom, et al. Expires October 7, 2015 [Page 7]
Internet-Draft HELD Routing April 2015
5. HELD Schema Extension
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>
Winterbottom, et al. Expires October 7, 2015 [Page 8]
Internet-Draft HELD Routing April 2015
</xs:schema>
6. Examples
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.
Winterbottom, et al. Expires October 7, 2015 [Page 9]
Internet-Draft HELD Routing April 2015
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
7. Privacy Considerations
This document makes no changes that require privacy considerations
beyond those already described in [RFC5985] and [RFC6155].
8. Security Considerations
This document imposes no additional security considerations beyond
those already described in [RFC5985] and [RFC6155].
9. IANA Considerations
9.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:geopriv:held:ri'
This document calls for IANA to register a new XML namespace, as per
the guidelines in [RFC3688].
Winterbottom, et al. Expires October 7, 2015 [Page 10]
Internet-Draft HELD Routing April 2015
URI: urn:ietf:params:xml:ns:geopriv:held:ri
Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).
XML:
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
9.2. XML Schema Registration
This section registers an XML schema as per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:ri
Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),
James Winterbottom (a.james.winterbottom@gmail.com).
The XML for this schema can be found as the entirety of Section 5
of this document.
10. Acknowledgements
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 Bernd Henschel for his support. Thanks to Roger
Marshall and Randy Gellens for their helpful suggestions.
Winterbottom, et al. Expires October 7, 2015 [Page 11]
Internet-Draft HELD Routing April 2015
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, March 2013.
11.2. Informative References
[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,
September 2010.
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011.
[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled
Location Delivery (HELD)", RFC 6915, April 2013.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server
Winterbottom, et al. Expires October 7, 2015 [Page 12]
Internet-Draft HELD Routing April 2015
(LIS) Discovery Using IP Addresses and Reverse DNS",
RFC 7216, April 2014.
Authors' Addresses
James Winterbottom
Winterb Consulting Services
Gwynneville, NSW 2500
AU
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com
Hannes Tschofenig
Halls in Tirol 6060
Austria
Phone:
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Laura Liess
Deutsche Telekom Networks
Deutsche Telekom Allee 7
Darmstadt, Hessen 64295
Germany
Phone:
Email: L.Liess@telekom.de
URI: http://www.telekom.de
Winterbottom, et al. Expires October 7, 2015 [Page 13]