[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 7840

ECRIT                                                    J. Winterbottom
Internet-Draft                               Winterb Consulting Services
Updates: RFC6881, RFC5985                                  H. Tschofenig
(if approved)
Intended status: Standards Track                                L. Liess
Expires: June 25, 2015                                  Deutsche Telekom
                                                       December 22, 2014


           A Routing Request Extension for the HELD Protocol
                  draft-ietf-ecrit-held-routing-00.txt

Abstract

   In many circumstances public LoST servers or a distributed network of
   forest guides linking public LoST servers is not available.  In such
   environments the general ECRIT calling models breakdown.  However,
   location servers operating in these areas are often privy to the
   necessary information to reach emergency and other services.  This
   document describes a solution where by the routing information may be
   obtained from a location server using a simple extension to the HELD
   protocol.

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 June 25, 2015.

Copyright Notice

   Copyright (c) 2014 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 June 25, 2015                 [Page 1]


Internet-Draft                HELD Routing                 December 2014


   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  . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  URN sub-namespace registration for
           'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 11
     9.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 11
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
























Winterbottom, et al.      Expires June 25, 2015                 [Page 2]


Internet-Draft                HELD Routing                 December 2014


1.  Introduction

   In many circumstances public LoST [RFC5222] servers or a distributed
   network of forest guides linking public LoST servers is not
   available.  In such environments the general ECRIT calling models
   breakdown.  Location servers operating in these areas are often privy
   to the necessary information to reach emergency and other services.
   This document describes how adding an extension to the HELD protocol
   [RFC5985] can used to extract this information for a location
   information server 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 June 25, 2015                 [Page 3]


Internet-Draft                HELD Routing                 December 2014


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 June 25, 2015                 [Page 4]


Internet-Draft                HELD Routing                 December 2014


                               +---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 their
   reluctance to deploy public LoST servers.  In countries amenable to
   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 June 25, 2015                 [Page 5]


Internet-Draft                HELD Routing                 December 2014


   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 address for any
   given location.  In [RFC6881] for example, the LIS validates all
   civic locations using a location validation procedure.  This
   procedure is the same as a routing request and so the LIS has the
   resulting the PSAP routing information.  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 address for
   a location, the LIS will, in a great many cases, 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 for the location where the device is.  If the LIS
   understands the routing request and has routing information
   accessible it provides the information in a routingInformation
   element included 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 understand the routing request element but can't
   obtain routing information returns location as normal.

   The routing information in the location response consists of one or
   more service elements which is identified by a service name.  The
   service name is a URI and might contain a general emergency 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



Winterbottom, et al.      Expires June 25, 2015                 [Page 6]


Internet-Draft                HELD Routing                 December 2014


   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
   to provide the routing information 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 June 25, 2015                 [Page 7]


Internet-Draft                HELD Routing                 December 2014


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:element>

     <xs:complexType name="service">
        <xs:complextContent>
          <xs:restriction base="xs:anyType">
             <xs:sequence>
                <xs:element name="dest" type="xs:anyURI"
                     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"
                           maxOccurs="unbounded"/>
               <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
           </xs:restriction>
         </xs:complexContent>
        </xs:complexType>

   </xs:schema>





Winterbottom, et al.      Expires June 25, 2015                 [Page 8]


Internet-Draft                HELD Routing                 December 2014


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 June 25, 2015                 [Page 9]


Internet-Draft                HELD Routing                 December 2014


   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:police">
                 <dest>sip:nypd@example.com</dest>
                     <dest>sips:nypd@example.com</dest>
             <dest>xmpp:nypd@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>
         </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].






Winterbottom, et al.      Expires June 25, 2015                [Page 10]


Internet-Draft                HELD Routing                 December 2014


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].

   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.






Winterbottom, et al.      Expires June 25, 2015                [Page 11]


Internet-Draft                HELD Routing                 December 2014


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.


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

   [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.



Winterbottom, et al.      Expires June 25, 2015                [Page 12]


Internet-Draft                HELD Routing                 December 2014


   [RFC7216]  Thomson, M. and R. Bellis, "Location Information Server
              (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 June 25, 2015                [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/