< draft-ietf-ecrit-held-routing-02.txt		draft-ietf-ecrit-held-routing-03.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 (if approved) H. Tschofenig
	(if approved)		Intended status: Standards Track
	Intended status: Standards Track L. Liess		Expires: January 21, 2016 L. Liess
	Expires: October 7, 2015 Deutsche Telekom		Deutsche Telekom
	April 5, 2015		July 20, 2015
	A Routing Request Extension for the HELD Protocol		A Routing Request Extension for the HELD Protocol
	draft-ietf-ecrit-held-routing-02.txt		draft-ietf-ecrit-held-routing-03.txt
	Abstract		Abstract
	In many circumstances public LoST servers or a distributed network of		For cases where location servers have access to emergency routing
	forest guides linking public LoST servers is not available. The		information they are able to return routing information with the
	general ECRIT calling models breakdown without publically accessible		location information if the location request includes a request for
	LoST servers. Sometimes location servers may have access to		the desired routing information. This document specifies an
	emergency routing information. This document defines an extension to		extension to the HELD protocol to support this funciton.
	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		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 October 7, 2015.		This Internet-Draft will expire on January 21, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6
	5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8		4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 7
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9.1. URN sub-namespace registration for		9.1. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 10		'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 11
	9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11		9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The general ECRIT calling models described in [RFC6443] and		The general ECRIT calling models described in [RFC6443] and
	[RFC6881]require a local LoST server or network of forest guides in		[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		order to determine the address of the PSAP in the best position to
	handle a call. Networks of forest guides have not eventuated and		handle a call. Networks of forest guides have not eventuated and
	while PSAPs are moving towards IP networks, LoST server deployment is		while PSAPs are moving towards IP networks, LoST server deployment is
	not ubiquitous. Some regions and countries have expressed reluctance		not ubiquitous. Some regions and countries have expressed reluctance
	to deploy LoST servers making aspects of the current ECRIT		to deploy LoST servers making aspects of the current ECRIT
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 22 ¶
	+------^-+ (3) | +--------+		+------^-+ (3) | +--------+
	| | +--------V----+ ^		| | +--------V----+ ^
	| +-----Service----| LoST Server | |		| +-----Service----| LoST Server | |
	| (4) +-------------+ +---+---+		| (4) +-------------+ +---+---+
	+-------------Call Initiation------------>| VSP |		+-------------Call Initiation------------>| VSP |
	(5) +-------+		(5) +-------+
	Figure 1: Device-Centric Emergency Services Model		Figure 1: Device-Centric Emergency Services Model
	The second approach is a softswitch-centric model, where a device		The second approach is a softswitch-centric model, where a device
	initiates and emergency call and the serving softswitch detects that		initiates an emergency call and the serving softswitch detects that
	the call is an emergency and initiates retrieving the caller's		the call is an emergency and initiates retrieving the caller's
	location from a Location Information Server (LIS) using HELD		location from a Location Information Server (LIS) using HELD
	[RFC5985] with identity extensions [RFC6155] [RFC6915] and then		[RFC5985] with identity extensions [RFC6155] [RFC6915] and then
	determining the route to the local PSAP using LoST [RFC5222].		determining the route to the local PSAP using LoST [RFC5222].
	Figure 2 shows the high-level protocol interactions.		Figure 2 shows the high-level protocol interactions.
	+---Location Request---+		+---Location Request---+
	| (2) |		| (2) |
	+---V---+ |		+---V---+ |
	| LIS | |		| LIS | |
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 5 ¶
	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.
			3.1. LoST Reuse Considerations
			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.
	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.		locationRequest and an element to the locationResponse.
	The request element indicates that the requestor wants the LIS to		The request element indicates that the requestor wants the LIS to
	provide routing information based on the location of the end-device.		provide routing information based on the location of the end-device.
	If the routing request is sent with no attribute then URIs for		If the routing request is sent with no attribute then URIs for
	urn:service:sos are returned. If the requestor wants routing		urn:service:sos are returned. If the requestor wants routing
	information for a specific service then they may include an optional		information for a specific service then they may include an optional
	skipping to change at page 6, line 51 ¶		skipping to change at page 6, line 45 ¶
	If the LIS understands the routing request and has routing		If the LIS understands the routing request and has routing
	information for the location then it includes the information in a		information for the location then it includes the information in a
	routingInformation element returned in the locationResponse. How the		routingInformation element returned in the locationResponse. How the
	LIS obtains this information is left to implementation, one possible		LIS obtains this information is left to implementation, one possible
	option is that the LIS acquires it from a LoST server, other		option is that the LIS acquires it from a LoST server, other
	possibilities are described in Section 3.		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		A LIS that does support the routing request element MUST support
	returning URIs for urn:service:sos		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		A LIS that does understand the routing request element but can't
	obtain any routing information for the end-device's location SHALL		obtain any routing information for the end-device's location MUST
	only return location information.		only return location information.
	A LIS that understands the routing request element but not the		A LIS that understands the routing request element but not the
	specified service URN, returns the routing URIs for the		specified service URN, MUST follow the URN traversal rules defined in
	urn:service:sos service.		[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		The routing information in the location response consists of a
	service element identified by a service name. The service name is 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 and might contain a general emergency service urn such as
	urn:service:sos or might contain a specific service urn depending on		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		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.		one or more service destinations is provided for the service name.
	Each destination is expressed as a URI and each URI scheme should		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		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		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		stale routing URIs the values MUST NOT be cached by the receiving
	entity.		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.
	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"
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	</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
	beyond those already described in [RFC5985] and [RFC6155].		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.
	8. Security Considerations		8. Security Considerations
	This document imposes no additional security considerations beyond		This document imposes no additional security considerations beyond
	those already described in [RFC5985] and [RFC6155].		those already described in [RFC5687] and [RFC6155].
	9. IANA Considerations		9. IANA Considerations
	9.1. URN sub-namespace registration for		9.1. URN sub-namespace registration for
	'urn:ietf:params:xml:ns:geopriv:held:ri'		'urn:ietf:params:xml:ns:geopriv:held:ri'
	This document calls for IANA to register a new XML namespace, as per		This document calls for IANA to register a new XML namespace, as per
	the guidelines in [RFC3688].		the guidelines in [RFC3688].
	URI: urn:ietf:params:xml:ns:geopriv:held:ri		URI: urn:ietf:params:xml:ns:geopriv:held:ri
	skipping to change at page 11, line 47 ¶		skipping to change at page 12, line 12 ¶
	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. Thanks to Roger		comments and Keith Drage ofr his more detailed review. Thanks to
	Marshall and Randy Gellens for their helpful suggestions.		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,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		DOI 10.17487/RFC3688, January 2004,
			<http://www.rfc-editor.org/info/rfc3688>.
			[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
			Emergency and Other Well-Known Services", RFC 5031,
			DOI 10.17487/RFC5031, January 2008,
			<http://www.rfc-editor.org/info/rfc5031>.
	[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.		[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
	Tschofenig, "LoST: A Location-to-Service Translation		Tschofenig, "LoST: A Location-to-Service Translation
	Protocol", RFC 5222, August 2008.		Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
			<http://www.rfc-editor.org/info/rfc5222>.
	[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol: Problem Statement and		Location Configuration Protocol: Problem Statement and
	Requirements", RFC 5687, March 2010.		Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,
			<http://www.rfc-editor.org/info/rfc5687>.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",		[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
	RFC 5985, September 2010.		RFC 5985, DOI 10.17487/RFC5985, September 2010,
			<http://www.rfc-editor.org/info/rfc5985>.
	[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, DOI 10.17487/RFC6443, December
			2011, <http://www.rfc-editor.org/info/rfc6443>.
	[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, DOI 10.17487/RFC6881, March 2013,
			<http://www.rfc-editor.org/info/rfc6881>.
	11.2. Informative References		11.2. Informative References
	[M493] European Telecommunications Standards Institute,		[M493] European Telecommunications Standards Institute,
	"Functional architecture to support European requirements		"Functional architecture to support European requirements
	on emergency caller location determination and transport",		on emergency caller location determination and transport",
	ES 203 178, V 1.0.5, December 2014.		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.		DOI 10.17487/RFC5986, September 2010,
			<http://www.rfc-editor.org/info/rfc5986>.
	[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, DOI 10.17487/RFC6155, March
			2011, <http://www.rfc-editor.org/info/rfc6155>.
	[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, DOI 10.17487/RFC6915,
			April 2013, <http://www.rfc-editor.org/info/rfc6915>.
	[RFC7216] Thomson, M. and R. Bellis, "Location Information Server		[RFC7216] Thomson, M. and R. Bellis, "Location Information Server
	(LIS) Discovery Using IP Addresses and Reverse DNS",		(LIS) Discovery Using IP Addresses and Reverse DNS",
	RFC 7216, April 2014.		RFC 7216, DOI 10.17487/RFC7216, April 2014,
			<http://www.rfc-editor.org/info/rfc7216>.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Winterb Consulting Services		Winterb Consulting Services
	Gwynneville, NSW 2500		Gwynneville, NSW 2500
	AU		AU
	Phone: +61 448 266004		Phone: +61 448 266004
	Email: a.james.winterbottom@gmail.com		Email: a.james.winterbottom@gmail.com
	Hannes Tschofenig		Hannes Tschofenig
	Halls in Tirol 6060		Halls in Tirol 6060
	Austria		Austria
	Phone:
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Laura Liess		Laura Liess
	Deutsche Telekom Networks		Deutsche Telekom Networks
	Deutsche Telekom Allee 7		Deutsche Telekom Allee 7
	Darmstadt, Hessen 64295		Darmstadt, Hessen 64295
	Germany		Germany
	Phone:
	Email: L.Liess@telekom.de		Email: L.Liess@telekom.de
	URI: http://www.telekom.de		URI: http://www.telekom.de
End of changes. 30 change blocks.
	71 lines changed or deleted		105 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/