< draft-winterbottom-ecrit-priv-loc-00.txt		draft-winterbottom-ecrit-priv-loc-01.txt >
	ECRIT J. Winterbottom		ECRIT J. Winterbottom
	Internet-Draft CommScope		Internet-Draft CommScope
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: January 8, 2013 Nokia Siemens Networks		Expires: January 17, 2013 Nokia Siemens Networks
	July 7, 2012		L. Liess
			Deutsche Telekom
			July 16, 2012
	Out of Jurisdiction Emergency Routing		Out of Jurisdiction Emergency Routing
	draft-winterbottom-ecrit-priv-loc-00		draft-winterbottom-ecrit-priv-loc-01.txt
	Abstract		Abstract
	Some countries and regions require location information be		Some countries and regions require location information be
	constrained to emergency service applications and do not permit		constrained to emergency service applications and do not permit
	location information to traverse the end-point at all. This document		location information to traverse the end-point at all. This document
	describes the requirements of these countries and provides a solution		describes the requirements of these countries and provides a solution
	based on an extension to the HELD location protocol.		based on an extension to the HELD location protocol.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 37 ¶
	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 January 8, 2013.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	The Internet emergency calling architecture specified in		The Internet emergency calling architecture specified in
	[I-D.ietf-ecrit-phonebcp] describes two main models for emergency		[I-D.ietf-ecrit-phonebcp] describes two main models for emergency
	call processing. The first is a device-centric model, where a device		call processing. The first is a device-centric model, where a device
	obtains location information using a location configuration protocol,		obtains location information using a location configuration protocol,
	such a HELD [RFC5985], and then proceeds to determine the address of		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		the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1
	shows this model in a simplified form.		shows this model in a simplified form.
	+---Location Request---+		+---Location Request---+
	| (1) |		| (1) |
	+---+----+ +---V---+		+---+----+ +---V---+
	| |<--Location--| LIS |		| |<--Location--| LIS |
	| Caller | (2) +-------+ +--------+		| Caller | (2) +-------+ +--------+
	| | | ESRP/ |		| | | ESRP/ |
	| |----Find Service-------+ | PSAP |		| |----Find Service-------+ | PSAP |
	+------^-+ (3) | +--------+		+------^-+ (3) | +--------+
	| | +--------V----+ ^		| | +--------V----+ ^
	| +-----Service----| LoST Server | |		| +-----Service----| LoST Server | |
	| (4) +-------------+ +---+---+		| (4) +-------------+ +---+---+
	+-------------Call Initiation------------>| VSP |		+-------------Call Initiation------------>| VSP |
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 16 ¶
	responds with a location URI and the destination URI of the correct		responds with a location URI and the destination URI of the correct
	emergency service authority. The Location URI will only yield		emergency service authority. The Location URI will only yield
	location information to the authorized emergency authority. This		location information to the authorized emergency authority. This
	solution addresses problem 1 problem 3, problem 4, problem 5.		solution addresses problem 1 problem 3, problem 4, problem 5.
	Problem 2 is solved using a combination of		Problem 2 is solved using a combination of
	[I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity		[I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity
	extensions.		extensions.
	6.1. Call Flow		6.1. Call Flow
	1. Device initiates an emergency call to home VSP		1. Device initiates an emergency call to the user's VSP
	2. Home VSP detects emergency call and uses IP address to determine		2. The VSP's proxy detects emergency call and uses IP address to
	the correct LIS to query using		determine the correct LIS to query using
	[I-D.ietf-geopriv-res-gw-lis-discovery].		[I-D.ietf-geopriv-res-gw-lis-discovery].
	3. Home VSP queries the LIS using HELD and the IP address of the		3. The VSP queries the LIS using HELD and the IP address of the
	calling device as an identity extension.		calling device as an identity extension.
	4. The LIS determines the location and uses it request routing		4. The LIS determines the location and uses it request routing
	information for the local LoST server.		information for the local LoST server.
	5. The LIS return a location URI and the local Emergency Service		5. The LIS return a location URI and the local Emergency Service
	Routing Proxy (ESRP) URI to the home VSP.		Routing Proxy (ESRP) URI to the VSP.
	6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and		6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and
	routes the call to the ESRP.		routes the call to the ESRP.
	7. The ESRP authenticates itself with the LIS when it dereferences		7. The ESRP authenticates itself with the LIS when it dereferences
	the location URI.		the location URI.
	8. The returns location information to the ESRP allowing it route		8. The returns location information to the ESRP allowing it route
	the call to the correct PSAP.		the call to the correct PSAP.
	+------(2)Find LIS-----+		+------(2)Find LIS-----+
	| |		| |
	+---V---+ |		+---V---+ |
	| DNS | |		| DNS | |
	+----+--+ +----+---------+		+----+--+ +----+---------+
	| | |		| | |
	+----LIS URI---->| Home |		+----LIS URI---->| |
	+--------+ | VSP |		+--------+ | VSP |
	| Caller |------(1)-Call Initiation--------> | |		| Caller |------(1)-Call Initiation--------> | |
	+--------+ +-+--^-------+-+		+--------+ +-+--^-------+-+
	| | |		| | |
	+-------------+ | | |		+-------------+ | | |
	| |<------(3)-locationReq(IP)-------+ | |		| |<------(3)-locationReq(IP)-------+ | |
	| LIS | | |		| LIS | | |
	| |--(5)-locationResp(locURI,EcrfURI)--+ |		| |--(5)-locationResp(locURI,EcrfURI)--+ |
	+-+--^---+--^-+ |		+-+--^---+--^-+ |
	| | | | +-------------+ |		| | | | +-------------+ |
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 11 ¶
	separates the entities into two clear groups, those that are inside		separates the entities into two clear groups, those that are inside
	the regulatory emergency jurisdiction and those that are in the		the regulatory emergency jurisdiction and those that are in the
	Internet. This is evident in Figure 5.		Internet. This is evident in Figure 5.
	+------(2)Find LIS-----+		+------(2)Find LIS-----+
	| |		| |
	+---V---+ |		+---V---+ |
	| DNS | |		| DNS | |
	+----+--+ +----+---------------+		+----+--+ +----+---------------+
	| | |		| | |
	+----LIS URI---->| Home |		+----LIS URI---->| |
	| VSP |		| VSP |
	| |		| |
	+-^---+----^-------+-+		+-^---+----^-------+-+
	I N T E R N E T | | | |		I N T E R N E T | | | |
	=========================================|===|====|=======|===		=========================================|===|====|=======|===
	LOCAL JURISDICTION | | | |		LOCAL JURISDICTION | | | |
	+--------+ | | | |		+--------+ | | | |
	| Caller |------(1)-Call Initiation------+ | | |		| Caller |------(1)-Call Initiation------+ | | |
	+--------+ | | |		+--------+ | | |
	| | |		| | |
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	[[TBD.]]		[[TBD.]]
	9. IANA Considerations		9. IANA Considerations
	[[TBD.]]		[[TBD.]]
	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 review comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-ecrit-phonebcp]		[I-D.ietf-ecrit-phonebcp]
	Rosen, B. and J. Polk, "Best Current Practice for		Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-20 (work in progress),		draft-ietf-ecrit-phonebcp-20 (work in progress),
	September 2011.		September 2011.
	[I-D.ietf-geopriv-deref-protocol]		[I-D.ietf-geopriv-deref-protocol]
	Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.		Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
	Thomson, "A Location Dereferencing Protocol Using HELD",		Thomson, "A Location Dereferencing Protocol Using HELD",
	draft-ietf-geopriv-deref-protocol-05 (work in progress),		draft-ietf-geopriv-deref-protocol-07 (work in progress),
	May 2012.		July 2012.
	[I-D.ietf-geopriv-res-gw-lis-discovery]		[I-D.ietf-geopriv-res-gw-lis-discovery]
	Thomson, M. and R. Bellis, "Location Information Server		Thomson, M. and R. Bellis, "Location Information Server
	(LIS) Discovery using IP address and Reverse DNS",		(LIS) Discovery using IP address and Reverse DNS",
	draft-ietf-geopriv-res-gw-lis-discovery-03 (work in		draft-ietf-geopriv-res-gw-lis-discovery-03 (work in
	progress), March 2012.		progress), March 2012.
	[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.
	skipping to change at line 575 ¶		skipping to change at page 14, line 27 ¶
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		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
End of changes. 13 change blocks.
	14 lines changed or deleted		17 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/