< draft-ietf-ecrit-held-routing-00.txt		draft-ietf-ecrit-held-routing-01.txt >
	ECRIT J. Winterbottom		ECRIT J. Winterbottom
	Internet-Draft Winterb Consulting Services		Internet-Draft Winterb Consulting Services
	Updates: RFC6881, RFC5985 H. Tschofenig		Updates: RFC6881, RFC5985 H. Tschofenig
	(if approved)		(if approved)
	Intended status: Standards Track L. Liess		Intended status: Standards Track L. Liess
	Expires: June 25, 2015 Deutsche Telekom		Expires: September 8, 2015 Deutsche Telekom
	December 22, 2014		March 7, 2015
	A Routing Request Extension for the HELD Protocol		A Routing Request Extension for the HELD Protocol
	draft-ietf-ecrit-held-routing-00.txt		draft-ietf-ecrit-held-routing-01.txt
	Abstract		Abstract
	In many circumstances public LoST servers or a distributed network of		In many circumstances public LoST servers or a distributed network of
	forest guides linking public LoST servers is not available. In such		forest guides linking public LoST servers is not available. The
	environments the general ECRIT calling models breakdown. However,		general ECRIT calling models breakdown without publically accessible
	location servers operating in these areas are often privy to the		LoST servers. Sometimes location servers may have access to
	necessary information to reach emergency and other services. This		emergency routing information. This document defines an extension to
	document describes a solution where by the routing information may be		the HELD protocol so a location request can include a request for
	obtained from a location server using a simple extension to the HELD		routing information and allowing the subsequent location response to
	protocol.		include routing information.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 25, 2015.		This Internet-Draft will expire on September 8, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8		5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9.1. URN sub-namespace registration for		9.1. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 11		'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 10
	9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11		9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	In many circumstances public LoST [RFC5222] servers or a distributed		The general ECRIT calling models described in [RFC6443] and
	network of forest guides linking public LoST servers is not		[RFC6881]require a local LoST server or network of forest guides in
	available. In such environments the general ECRIT calling models		order to determine the address of the PSAP in the best position to
	breakdown. Location servers operating in these areas are often privy		handle a call. Networks of forest guides have not eventuated and
	to the necessary information to reach emergency and other services.		while PSAPs are moving towards IP networks, LoST server deployment is
	This document describes how adding an extension to the HELD protocol		not ubiquitous. Some regions and countries have expressed reluctance
	[RFC5985] can used to extract this information for a location		to deploy LoST servers making aspects of the current ECRIT
	information server in the absence of a LoST server or network of		architecture hard to realize.
	forest guides.
			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		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].		The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].
	The term "Access Network Provider" is used as defined in [RFC5687]		The term "Access Network Provider" is used as defined in [RFC5687]
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	LoST server discovery is a domain based activity, similar to the LIS		LoST server discovery is a domain based activity, similar to the LIS
	discovery technique. However, unlike the LIS that is a domain bound		discovery technique. However, unlike the LIS that is a domain bound
	service, a LoST server is a geographically bound service. This means		service, a LoST server is a geographically bound service. This means
	that for a domain that spans multiple geographic regions the LoST		that for a domain that spans multiple geographic regions the LoST
	server determined may not be able to provide a route to the necessary		server determined may not be able to provide a route to the necessary
	PSAP. When this occurs, the contacted LoST server invokes the help		PSAP. When this occurs, the contacted LoST server invokes the help
	of other LoST servers and this requires the deployment of forest		of other LoST servers and this requires the deployment of forest
	guides.		guides.
	At the time of writing, several countries have expressed their		At the time of writing, several countries have expressed a reluctance
	reluctance to deploy public LoST servers. In countries amenable to		to deploy public LoST servers. In countries amenable to the use of
	use of LoST and forest guides no public forest guides have been		LoST and forest guides no public forest guides have been deployed.
	deployed. There appears little interest from the public sector in		There appears little interest from the public sector in establishing
	establishing a global forest guide network. These issues pose		a global forest guide network. These issues pose threats to both the
	threats to both the device-centric and the softswitch-centric calling		device-centric and the softswitch-centric calling approaches in terms
	approaches in terms of them operating everywhere.		of them operating everywhere.
	The device-centric and softswitch-centric calling models both involve		The device-centric and softswitch-centric calling models both involve
	the notion of a LIS bound to the serving access network. In many		the notion of a LIS bound to the serving access network. In many
	cases the LIS already knows the destination PSAP address for any		cases the LIS already knows the destination PSAP URI for any given
	given location. In [RFC6881] for example, the LIS validates all		location. In [RFC6881] for example, the LIS validates civic
	civic locations using a location validation procedure. This		locations using a location validation procedure based on the LoST
	procedure is the same as a routing request and so the LIS has the		protocol [RFC5222]. The LoST validation request is similar to a LoST
	resulting the PSAP routing information. In other cases, the LIS		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		knows the correct PSAP for a given location at provisioning time, or
	the access network might always route to the same emergency provider.		the access network might always route to the same emergency provider.
	Irrespective of the way in which the LIS learns the PSAP address for		Irrespective of the way in which the LIS learns the PSAP URI for a
	a location, the LIS will, in a great many cases, have this		location, the LIS will, in a great many cases, already have this
	information.		information.
	This document specifies an extension to the HELD protocol so that		This document specifies an extension to the HELD protocol so that
	emergency routing information can be requested from the LIS at the		emergency routing information can be requested from the LIS at the
	same time that location information is requested. The document		same time that location information is requested. The document
	updates [RFC6881] by requiring devices and softswitches that		updates [RFC6881] by requiring devices and softswitches that
	understand this specification to always request routing information		understand this specification to always request routing information
	to avoid the risk of query failure where no LoST server or forest		to avoid the risk of query failure where no LoST server or forest
	guide network is deployed.		guide network is deployed.
	4. Mechanism		4. Mechanism
	The mechanism consists of adding an element to the HELD		The mechanism consists of adding an element to the HELD
	locationRequest and an element to the locationResponse. The request		locationRequest and an element to the locationResponse.
	element indicates that the requestor wants the LIS to provide routing
	information for the location where the device is. If the LIS		The request element indicates that the requestor wants the LIS to
	understands the routing request and has routing information		provide routing information based on the location of the end-device.
	accessible it provides the information in a routingInformation		If the routing request is sent with no attribute then URIs for
	element included in the locationResponse. How the LIS obtains this		urn:service:sos are returned. If the requestor wants routing
	information is left to implementation, one possible option is that		information for a specific service then they may include an optional
	the LIS acquires it from a LoST server, other possibilities are		service URN. If a service is specified, and the LIS does not
	described in Section 3.		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		A LIS that does not understand the routing request element ignores it
	and returns location as normal.		and returns location as normal.
			A LIS that does support the routing request element SHALL support
			returning URIs for urn:service:sos
	A LIS that does understand the routing request element but can't		A LIS that does understand the routing request element but can't
	obtain routing information returns location as normal.		obtain any routing information for the end-device's location SHALL
			only return location information.
	The routing information in the location response consists of one or		A LIS that understands the routing request element but not the
	more service elements which is identified by a service name. The		specified service URN, returns the routing URIs for the
	service name is a URI and might contain a general emergency service		urn:service:sos service.
	urn such as urn:service:sos or might contain a specific service urn.
	For each service name a list of one or more service destinations is
	provided. Each destination is expressed as a URI and each URI scheme
	should only appear once in this list. The routing information is
	intended to be used at the time it is received. To avoid any risks
	of using stale routing information the value should not be cached by
	the receiving entity.
	Reusing the mapping element from the LoST findServiceResponse message		The routing information in the location response consists of a
	to provide the routing information was considered. However, this		service element identified by a service name. The service name is a
	would have meant that several of the mandatory components in the		urn and might contain a general emergency service urn such as
	mapping element would have had to contain ambiguous or misleading		urn:service:sos or might contain a specific service urn depending on
	values. Specifically, the "source" attribute is required to contain		what was requested and what the LIS is able to provide. A list of
	a LoST application unique string for the authoritative server.		one or more service destinations is provided for the service name.
	However, in the situations described in this specification there may		Each destination is expressed as a URI and each URI scheme should
	not be an authoritative LoST server, so any value put into this		only appear once in this list. The routing URIs are intended to be
	attribute would be misleading. In addition to this, routing		used at the time they are received. To avoid any risks of using
	information received in the manner described in this specification		stale routing URIs the values MUST NOT be cached by the receiving
	should not be cached by the receiver, so detailing when the routing		entity.
	information expires or was last updated is irrelevant.
			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.
	5. HELD Schema Extension		5. HELD Schema Extension
	This section describes the schema extension to HELD.		This section describes the schema extension to HELD.
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"		targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"		xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:element name="requestRoutingInformation">		<xs:element name="requestRoutingInformation">
	<xs:complexType name="empty"/>		<xs:complexType name="empty">
			<xs:attribute name="service" type="xs:anyUri"
			use="optional" default="urn:service:sos"/>
			</xs:complexType>
	</xs:element>		</xs:element>
	<xs:complexType name="service">		<xs:complexType name="service">
	<xs:complextContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="dest" type="xs:anyURI"		<xs:element name="dest" type="xs:anyURI"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="serviceUri" type="xs:anyURI"		<xs:attribute name="serviceUri" type="xs:anyURI"
	use="required"/>		use="required"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:element name="routingInformation" type="ri:riType"/>		<xs:element name="routingInformation" type="ri:riType"/>
	<xs:complexType name="riType">		<xs:complexType name="riType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="service" type="ri:service"		<xs:element name="service" type="ri:service"/>
	maxOccurs="unbounded"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	<locationUriSet expires="2006-01-01T13:00:00.0Z">		<locationUriSet expires="2006-01-01T13:00:00.0Z">
	<locationURI>		<locationURI>
	https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o		https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
	</locationURI>		</locationURI>
	<locationURI>		<locationURI>
	sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com		sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
	</locationURI>		</locationURI>
	</locationUriSet>		</locationUriSet>
	<routingInformation		<routingInformation
	xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">		xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
	<service serviceUri="urn:service:sos:police">		<service serviceUri="urn:service:sos">
	<dest>sip:nypd@example.com</dest>		<dest>sip:112@example.com</dest>
	<dest>sips:nypd@example.com</dest>		<dest>sips:112@example.com</dest>
	<dest>xmpp:nypd@example.com</dest>		<dest>xmpp:112@example.com</dest>
	</service>
	<service serviceUri="urn:service:sos:fire">
	<dest>sip:fd@ny.example.com</dest>
	<dest>sips:fd@ny.example.com</dest>
	<dest>xmpp:fd@ny.example.com</dest>
	</service>		</service>
	</routingInformation>		</routingInformation>
	</locationResponse>		</locationResponse>
	Figure 4: Example Location Response		Figure 4: Example Location Response
	7. Privacy Considerations		7. Privacy Considerations
	This document makes no changes that require privacy considerations		This document makes no changes that require privacy considerations
	skipping to change at page 12, line 9 ¶		skipping to change at page 11, line 47 ¶
	Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),		Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org),
	James Winterbottom (a.james.winterbottom@gmail.com).		James Winterbottom (a.james.winterbottom@gmail.com).
	The XML for this schema can be found as the entirety of Section 5		The XML for this schema can be found as the entirety of Section 5
	of this document.		of this document.
	10. Acknowledgements		10. Acknowledgements
	We would like to thank Wilfried Lange for sharing his views with us.		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		We would also like to thank Bruno Chatras for his early review
	comments and Bernd Henschel for his support.		comments and Bernd Henschel for his support. Thanks to Roger
			Marshall and Randy Gellens for their helpful suggestions.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 36 ¶
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, December 2011.		Multimedia", RFC 6443, December 2011.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",		Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, March 2013.		BCP 181, RFC 6881, March 2013.
	11.2. Informative References		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		[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
	Location Information Server (LIS)", RFC 5986,		Location Information Server (LIS)", RFC 5986,
	September 2010.		September 2010.
	[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.		[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
	Barnes, "Use of Device Identity in HTTP-Enabled Location		Barnes, "Use of Device Identity in HTTP-Enabled Location
	Delivery (HELD)", RFC 6155, March 2011.		Delivery (HELD)", RFC 6155, March 2011.
	[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled		[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled
	Location Delivery (HELD)", RFC 6915, April 2013.		Location Delivery (HELD)", RFC 6915, April 2013.
End of changes. 23 change blocks.
	86 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/