draft-ietf-ecrit-held-routing-04.txt   draft-ietf-ecrit-held-routing-05.txt 
ECRIT J. Winterbottom ECRIT J. Winterbottom
Internet-Draft Winterb Consulting Services Internet-Draft Winterb Consulting Services
Updates: RFC6881, RFC5985 (if approved) H. Tschofenig Updates: 6881, 5985 (if approved) H. Tschofenig
Intended status: Standards Track Intended status: Standards Track
Expires: June 11, 2016 L. Liess Expires: August 12, 2016 L. Liess
Deutsche Telekom Deutsche Telekom
December 9, 2015 February 9, 2016
A Routing Request Extension for the HELD Protocol A Routing Request Extension for the HELD Protocol
draft-ietf-ecrit-held-routing-04.txt draft-ietf-ecrit-held-routing-05.txt
Abstract Abstract
For cases where location servers have access to emergency routing For cases where location servers have access to emergency routing
information they are able to return routing information with the information they are able to return routing information with the
location information if the location request includes a request for location information if the location request includes a request for
the desired routing information. This document specifies an the desired routing information. This document specifies an
extension to the HELD protocol, updating [RFC5985], to support this extension to the HELD protocol that updates RFC5985, to support this
funciton. funciton. Allowing location and routing information to be acquired
in a single request response exchange updates RFC6881, as current
location acquisition and route determination procedures are separate
operations.
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 11, 2016. This Internet-Draft will expire on August 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 18 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7 5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7
6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. URN sub-namespace registration for 10.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13
10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13 10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 38 skipping to change at page 3, line 38
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The terms Location Information Server (LIS), Emergency Services The terms Location Information Server (LIS), Emergency Services
Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety
Answering Point (PSAP) are used as defined in [RFC6443]. Answering Point (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]
and incompasses both the Internet Access Provider (IAP) and Internet and incompasses both the Internet Access Provider (IAP) and Internet
Service Provider (ISP). Service Provider (ISP).
The term "Forest Guide" is used as defined in [RFC5582].
3. Motivation 3. Motivation
The Internet emergency calling architecture specified in [RFC6881] The Internet emergency calling architecture specified in [RFC6881]
describes two main models for emergency call processing. The first describes two main models for emergency call processing. The first
is a device-centric model, where a device obtains location is a device-centric model, where a device obtains location
information using a location configuration protocol, such as HELD information using a location configuration protocol, such as HELD
[RFC5985], and then proceeds to determine the address of the next hop [RFC5985], and then proceeds to determine the address of the next hop
closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this
model in a simplified form. model in a simplified form.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
specified service URN, MUST follow the URN traversal rules defined in specified service URN, MUST follow the URN traversal rules defined in
[RFC5031]. [RFC5031].
A LIS that receives a request for emergency routing information that A LIS that receives a request for emergency routing information that
it understands MUST return the correct emergency routing information it understands MUST return the correct emergency routing information
if it has or is able to acquire the routing information for the if it has or is able to acquire the routing information for the
location of the target device. 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.
5. Modification to Phone BCP 5. Modification to Phone BCP
This section describes the normative updates to Phone BCP [RFC6881]. This section describes the normative updates to Phone BCP [RFC6881].
It is important for devices and intermediaries to take all steps It is important for devices and intermediaries to take all steps
possible to ensure that emergency calls are routed to the correct possible to ensure that emergency calls are routed to the correct
PSAPS. In absence of global forest guides or local LoST servers and PSAP. An alternative to providing routing information via global
the possibility that the local network may be configured with PSAP forest guides or local LoST servers is for local networks to
address information, this specification updates Phone BCP [RFC6881]. configure the PSAP address information in the network location
The update requires devices and intermediaries using the HELD server. This specification updates Phone BCP [RFC6881] to provide
protocol to always include the HELD routing extension. If the LIS is this option. The update requires devices and intermediaries using
configured with the routing information it can provide it, if it is the HELD protocol to always include the HELD routing extension. If
not then the device or intermediary tries LoST to acquire the PSAP the LIS is configured with the routing information it can provide it,
URI. if it is not then the device or intermediary tries LoST to acquire
the PSAP URI.
Section 6.5 of [RFC6881] defines "End System Location Configuration". Section 6.5 of [RFC6881] defines "End System Location Configuration".
Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
LCP such that "the request MUST include the requestRoutingInformation LCP such that "the request MUST include the requestRoutingInformation
element". The remainder of the requirement remains unchanged. element". The remainder of the requirement remains unchanged.
This document adds a new requirement to section 7 of [RFC6881]. This document adds a new requirement to Section 7 of [RFC6881].
"ED-51a : Endpoints MUST support the HELD requestRoutingInformation "ED-51a : Endpoints MUST support the HELD requestRoutingInformation
element and be able and be able to interpret and use any routing element and be able and be able to interpret and use any routing
information returned in the locationResponse." information returned in the locationResponse."
This document adds two new requirements to section 8 of [RFC6881]. This document adds two new requirements to Section 8 of [RFC6881].
"ED-52a : Endpoints that acquire routing information in a HELD "ED-52a : Endpoints that acquire routing information in a HELD
locationResponse SHOULD use this routing information but MAY perform locationResponse SHOULD use this routing information but MAY perform
a LoST findService request if they have a location value." a LoST findService request if they have a location value."
"ED-52b : Endpoints that acquire routing information in a HELD "ED-52b : Endpoints that acquire routing information in a HELD
locationResponse with a defaultRoute attribute of true MUST perform a locationResponse with a defaultRoute attribute of true MUST perform a
LoST findService request if they have a location value. If a route LoST findService request if they have a location value. If a route
is provided by the LoST server then this route MUST be used, is provided by the LoST server then this route MUST be used,
otherwise the routing information provided in the HELD response otherwise the routing information provided in the HELD response
skipping to change at page 9, line 39 skipping to change at page 9, line 16
<xs:attribute name="defaultRoute" type="xs:boolean" <xs:attribute name="defaultRoute" type="xs:boolean"
use="optional" default="false"/> use="optional" default="false"/>
<xs:attribute name="serviceUri" type="xs:anyURI" <xs:attribute name="serviceUri" type="xs:anyURI"
use="required"/> use="required"/>
<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:element name="routingInformation" type="ri:riType"/> <xs:element name="routingInformation" type="ri:riType"/>
<xs:complexType name="riType">
<xs:complexContent> <xs:complexType name="riType">
<xs:restriction base="xs:anyType"> <xs:complexContent>
<xs:sequence> <xs:restriction base="xs:anyType">
<xs:element name="service" type="ri:service"/> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:element name="service" type="ri:service"/>
minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> </xs:sequence>
</xs:restriction> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexContent> </xs:restriction>
</xs:complexType> </xs:complexContent>
</xs:complexType>
</xs:schema> </xs:schema>
7. Examples 7. Examples
Figure 3 illustrates a <locationRequest> example that contains IP Figure 3 illustrates a <locationRequest> example that contains IP
flow information in the request. flow information in the request.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="emergencyRouting"> responseTime="emergencyRouting">
<requestRoutingInformation <requestRoutingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/> xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow" <flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4"> layer4="tcp" layer3="ipv4">
<src> <src>
<address>192.168.1.1</address> <address>192.0.2.12</address>
<port>1024</port> <port>1024</port>
</src> </src>
<dst> <dst>
<address>10.0.0.1</address> <address>192.0.2.195</address>
<port>80</port> <port>80</port>
</dst> </dst>
</flow> </flow>
</locationRequest> </locationRequest>
Figure 3: Example Location Request. Figure 3: Example Location Request.
Figure 4 illustrates the <locationResponse> message containing two Figure 4 illustrates the <locationResponse> message containing two
location URIs: a HTTPS and a SIP URI. Additionally, the response location URIs: a HTTPS and a SIP URI. Additionally, the response
contains routing information. contains routing information.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<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"> <service serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest> <dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest> <dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest> <dest>xmpp:112@example.com</dest>
</service> </service>
</routingInformation> </routingInformation>
</locationResponse> </locationResponse>
Figure 4: Example Location Response Figure 4: Example Location Response
Figure 5 illustrates the <locationResponse> message containing Figure 5 illustrates the <locationResponse> message containing
default routing information and an HTTPS location URI. default routing information and an HTTPS location URI.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2016-01-01T13:00:00.0Z"> <locationUriSet expires="2016-01-01T13:00:00.0Z">
<locationURI> <locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
skipping to change at page 12, line 31 skipping to change at page 12, line 31
</service> </service>
</routingInformation> </routingInformation>
</locationResponse> </locationResponse>
Figure 5: Example Location Response with default routing information Figure 5: Example Location Response with default routing information
8. Privacy Considerations 8. 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 [RFC5687]. It does however extend beyond those already described in [RFC5985]. It does however extend
those described in [RFC6155]. those described in [RFC6155].
[RFC5687] describes the issues surrounding Layer 7 location [RFC5985] describes the privacy considerations surrounding the HELD
configuration protocols, which this document makes no specific location configuration protocol, and this document makes no specific
changes to. changes to these considerations.
[RFC6155] extends HELD beyond a simple location configuration [RFC6155] extends HELD beyond a simple location configuration
protocol (LCP) by enabling authorized third-parties to acquire protocol (LCP) by enabling authorized third-parties to acquire
location information and describes the issues in Section 4. The HELD location information and describes the issues in Section 4. The HELD
Routing extension supports returning URIs that represent specific Routing extension supports returning URIs that represent specific
services operating in the Target's vicinity. This represents services operating in the Target's vicinity. This represents
additional information about the Target, as a consequence it is additional information about the Target, as a consequence it is
recommended that this option only be used when the LIS returns a recommended that this option only be used when the LIS returns a
location URI, not a location value. location URI, not a location value.
9. Security Considerations 9. Security Considerations
This document imposes no additional security considerations beyond This document imposes no additional security considerations beyond
those already described in [RFC5687] and [RFC6155]. those already described in [RFC5985] and [RFC6155].
10. IANA Considerations 10. IANA Considerations
10.1. URN sub-namespace registration for 10.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 15, line 5 skipping to change at page 15, line 5
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
DOI 10.17487/RFC5031, January 2008, DOI 10.17487/RFC5031, January 2008,
<http://www.rfc-editor.org/info/rfc5031>. <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, DOI 10.17487/RFC5222, August 2008, Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<http://www.rfc-editor.org/info/rfc5222>. <http://www.rfc-editor.org/info/rfc5222>.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, DOI 10.17487/RFC5582, September
2009, <http://www.rfc-editor.org/info/rfc5582>.
[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, DOI 10.17487/RFC5687, March 2010, Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,
<http://www.rfc-editor.org/info/rfc5687>. <http://www.rfc-editor.org/info/rfc5687>.
[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,
DOI 10.17487/RFC5986, September 2010, DOI 10.17487/RFC5986, September 2010,
<http://www.rfc-editor.org/info/rfc5986>. <http://www.rfc-editor.org/info/rfc5986>.
 End of changes. 25 change blocks. 
65 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/