<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" updates="RFC6881" docName="draft-winterbottom-ecrit-priv-loc-04.txt">
  <front>
    <title abbrev="HELD Routing">A Routing Request Extension for the HELD Protocol</title>

    <author initials="J." surname="Winterbottom" fullname="James Winterbottom">
      <organization>Winterb Consulting Services</organization>
      <address>
        <postal>
          <street/>
          <city>Gwynneville</city>
          <region>NSW</region>
          <code>2500</code>
          <country>AU</country>
        </postal>
        <phone>+61 448 266004</phone>
        <email>a.james.winterbottom@gmail.com</email>
      </address>
    </author>
    
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization></organization>
      <address>
	    <postal>
	        <street></street>
	        <city>Halls in Tirol</city>
	        <code>6060</code>
	        <country>Austria</country>
	    </postal>
	    <phone></phone>
	    <email>Hannes.Tschofenig@gmx.net</email>
	    <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
 

    <author initials="L." surname="Liess" fullname="Laura Liess">

      <organization abbrev="Deutsche Telekom">Deutsche Telekom Networks</organization>

      <address>

        <postal>

          <street>Deutsche Telekom Allee 7</street>

          <city>Darmstadt</city>

          <region>Hessen</region>

          <code>64295</code>

          <country>Germany</country>

        </postal>

        <phone> </phone>

        <email>L.Liess@telekom.de</email>

        <uri>http://www.telekom.de</uri>

      </address>

    </author>
    <date year="2014"/>
    <area>RAI</area>
    <workgroup>ECRIT</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Emergency</keyword>
    <keyword>Call</keyword>
    <keyword>Routing</keyword>
    <keyword>Location</keyword>
    <keyword>HELD</keyword>

    <abstract>
      <t>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.
      </t>

    </abstract>
  </front>
  <middle>
<!-- ***************************************************************************************************** --> 
       
    <section anchor="intro" title="Introduction">
    <t>
         In many circumstances public LoST <xref target="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 <xref target="RFC5985"/>
         can used to extract this information for a location information server in the
         absence of a LoST server or network of forest guides.    
    </t>
    </section>
    <!-- ***************************************************************************************************** --> 
       
      <section anchor="terminology" title="Terminology">
        <t>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 <xref target="RFC2119"/>.
        </t>
        <t>The terms LIS, ESRP, VSP and PSAP are used as defined in <xref target="RFC6443"/>.</t>
        <t>The term "Access Network Provider" is used as defined in <xref target="RFC5687"/> and incompasses both the Internet Access Provider (IAP) and Internet Service Provider (ISP).</t>
      </section>

<!-- ***************************************************************************************************** --> 
    <?rfc needLines="30" ?>
    <section anchor="moti" title="Motivation">
    
      <t>The Internet emergency calling architecture specified in <xref target="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 <xref target="RFC5985"/>,
      and then proceeds to determine the address of the next hop closer to the local PSAP 
      using LoST <xref target="RFC5222"/>.
      <xref target="device"/> shows this model in a simplified form. 
            <figure anchor="device" title="Device-Centric Emergency Services Model"><artwork><![CDATA[
     +---Location Request---+
     |         (1)          |
 +---+----+             +---V---+ 
 |        |<--Location--|  LIS  |         
 | Caller |    (2)      +-------+             +--------+
 |        |                                   | ESRP/  |
 |        |----Find Service-------+           |  PSAP  |   
 +------^-+     (3)               |           +--------+
    |   |                +--------V----+          ^
    |   +-----Service----| LoST Server |          |
    |         (4)        +-------------+      +---+---+
    +-------------Call Initiation------------>|  VSP  |                   
                     (5)                      +-------+
 
]]></artwork></figure>
</t>



      <t>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 <xref target="RFC5985"/> with identity 
      extensions <xref target="RFC6155"/> <xref target="RFC6915"/> and then determining 
      the route to the  local PSAP using LoST <xref target="RFC5222"/>. 
      <xref target="sofswitch"/> shows the high-level protocol interactions.
      </t>
      <t>
      <figure anchor="sofswitch" title="Softswitch-Centric Calling Model"><artwork><![CDATA[
  
                            +---Location Request---+
                            |         (2)          |
                        +---V---+                  |
                        |  LIS  |                  |
                        +----+--+             +----+----+
                             |                |         |
                             +----Location--->|  Soft   |
 +--------+                          (3)      | Switch  |
 | Caller |------Call Initiation------------> |         |   
 +--------+          (1)                      +-+-^---+-+
                 +-------------+                | |   |
                 | LoST Server |<-Find Service--+ |   |        
                 +------+------+     (4)          |   |  
                        |                         |   |
                        +----------Service--------+   |
                                    (5)               |
                          +-----------+               |
                          | ESRP/PSAP |<------Call----+
                          +-----------+       (6)            
                                            
]]></artwork></figure>
</t>

<t>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 <xref target="RFC7216"/> to 
acquire the serving domain name and then using <xref target="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.</t>

<t>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.
</t>

<t>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.
</t>

<t>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 <xref target="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.
</t>

<t>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 <xref target="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.
</t>
      
    </section>
<!-- ***************************************************************************************************** --> 
       

<section anchor="mechanism" title="Mechanism">
<t>
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 <xref target="moti"/>.
</t>

<t>A LIS that does not understand the routing request element ignores it and returns location as normal.
</t>

<t>A LIS that does understand the routing request element but can’t obtain routing information returns 
location as normal.
</t>

<t>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 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. 
</t>

<t>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 &quot;source&quot; 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.   
</t>


</section>
    

<!-- ***************************************************************************************************** --> 

   

   <!-- ***************************************************************************************************** --> 
 <?rfc needLines="46" ?>  
		<section anchor="schema" title="HELD Schema Extension">
	<t>This section describes the schema extension to HELD.</t>
	<t>
 <figure>
          <artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
  targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:eri="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="seviceUri" 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>
]]></artwork>
        </figure>   
    </t>
	
	</section>
	<!-- ***************************************************************************************************** --> 
	<section anchor="heldExamples" title="Examples">
	<t><xref target="locationRequest"/> illustrates a &lt;locationRequest&gt; example that contains IP flow information in the request.</t>
	<t>
	<figure anchor="locationRequest" title="Example Location Request."><artwork><![CDATA[
<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>
]]></artwork></figure>
	</t>
	<?rfc needLines="46" ?>
	<t><xref target="locationResponse"/> illustrates the &lt;locationResponse&gt; message 
	containing two location URIs: a HTTPS and a SIP URI. Additionally, 
	the response contains routing information.</t>
	
	<t>
	<figure anchor="locationResponse" title="Example Location Response"><artwork><![CDATA[
<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>
]]></artwork></figure>
</t>
	</section>
<!-- ***************************************************************************************************** --> 	
  

  <!-- ***************************************************************************************************** --> 


    <section anchor="privacy" title="Privacy Considerations">
      <t>This document makes no changes that require privacy considerations beyond those 
      already described in <xref target="RFC5985"/> and <xref target="RFC6155"/>.</t>
    </section>

   <!-- ***************************************************************************************************** --> 

    <section anchor="security" title="Security Considerations">
      <t>This document imposes no additional security considerations beyond those 
      already described in <xref target="RFC5985"/> and <xref target="RFC6155"/>.</t>
    </section>

   <!-- ***************************************************************************************************** --> 

    <section anchor="iana" title="IANA Considerations">
      <section title="URN sub-namespace registration for 'urn:ietf:params:xml:ns:geopriv:held:ri'">
        <t>This document calls for IANA to register a new XML namespace, as per the guidelines in <xref target="RFC3688"/>.
        <list style="hanging">
          <t hangText="URI:">urn:ietf:params:xml:ns:geopriv:held:ri</t>
          <t hangText="Registrant Contact:">IETF, ECRIT working group (ecrit@ietf.org), 
          James Winterbottom (a.james.winterbottom@gmail.com).</t>

          <t hangText="XML:">
            <figure>
              <artwork><![CDATA[
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
]]></artwork>
            </figure>
          </t>
        </list>
        </t>
      </section>
      
      <section title="XML Schema Registration">
        <t>This section registers an XML schema as per the procedures in <xref target="RFC3688"/>.
        <list style="hanging">
          <t hangText="URI:">urn:ietf:params:xml:schema:geopriv:held:ri</t>
          <t hangText="Registrant Contact:">IETF, ECRIT working group, (ecrit@ietf.org), 
          James Winterbottom (a.james.winterbottom@gmail.com).</t>
          <t>The XML for this schema can be found as the entirety of <xref target="schema"/> of this document.
          </t>
        </list>
        </t>
</section>
      
    </section>

   <!-- ***************************************************************************************************** --> 

    <section title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5222"?>
      <?rfc include="reference.RFC.5985"?>
      <?rfc include="reference.RFC.6881"?>
      <?rfc include="reference.RFC.6443"?>
      <?rfc include="reference.RFC.5687"?>
      <?rfc include="reference.RFC.3688"?>
    </references>
	<references title="Informative References">
			<?rfc include="reference.RFC.5986"?>
			<?rfc include="reference.RFC.6155"?>
			<?rfc include="reference.RFC.6915"?>
	        <?rfc include="reference.RFC.7216"?>
    </references> 

  </back>
</rfc>
