Internet DRAFT - draft-polk-dhc-ecrit-uri-psap-esrp

draft-polk-dhc-ecrit-uri-psap-esrp






Network Working Group                                        James Polk
Internet Draft                                            Cisco Systems
Expiration: Dec 19th, 2006                              June 19th, 2006
File: draft-polk-dhc-ecrit-uri-psap-esrp-00.txt


            A Dynamic Host Configuration Protocol Option for
         Requesting and Receiving a Uniform Resource Identifier
        of a Public Safety Answering Point or Emergency Services
                             Routing Proxy


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 19th, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines a new Dynamic Host Configuration Protocol 
   (DHC) Option for client requesting and/or receiving a Public Safety 
   Answering Point (PSAP) or Emergency Services Routing Proxy (ESRP) 
   URI to be used by higher layer protocols during emergency calling.  
   In some network models, an ESRP URI and a PSAP URI will be 
   equivalent from the client's point of view, therefore this document 
   purposely vague differentiating between the two, as the difference 
   does not matter to DHCP.


Polk                       Expires Dec, 2006                   [Page 1]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1  Conventions used in this document  . . . . . . . . . . . .  4
     1.2  Terms, Acronyms and Definitions  . . . . . . . . . . . . .  4
   2.  Solution Message Flow Example . . . . . . . . . . . . . . . .  4
   3.  PSAP vs. ESRP URI - Why They Can Be the Same  . . . . . . . .  5
   4.  DHC Relay Option Format . . . . . . . . . . . . . . . . . . .  6
     4.1  Rules of Usage . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1   Normative References  . . . . . . . . . . . . . . . . . .  7
     8.2   Informative References  . . . . . . . . . . . . . . . . .  8
       Author's Address  . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements  . . . . . . .  8


1.  Introduction

   In IP communications, destination addressing can be to an IP address
   directly, or to a Uniform Resource Identifier (URI), where the 
   service at the URI is resolved to a destination IP address by the 
   source system or along the path.  In Voice over IP communications, 
   the destination IP address is infrequently used by the calling 
   device; rather, a URI is used.  The burden is on call servers along 
   the path to resolve this URI to IP address to determine where to 
   ultimately route the packet(s) to.  

   Understanding the decomposed nature of voice communications, quite 
   pronounced with peer-to-peer protocols potentially having servers 
   100s and 1000s of miles away from the calling device, call 
   signaling at a higher layer may lack the local knowledge to 
   appropriately provide the client with what is necessary to make a 
   local emergency call.  In emergency communications, the act of 
   calling for help is a highly localized event, requiring knowledge of
   where the caller is.  The destination of that emergency call will 
   also be local in nature.  

   This document defines a new Dynamic Host Configuration Protocol 
   (DHC) Option [RFC2131] to allow an emergency services URI be 
   requested by a client of a server, and transmitted unrequested from 
   a server to a client.  The URI is a SIP(S)-URI of a Public 
   Safety Answering Point (PSAP) for that access network, at that user 
   agent's location, which may be unknown or undiscoverable to a SIP 
   server for this client.  Most access networks are not served by a 
   single PSAP.  Increased granularity within the same access network 
   may provide a different PSAP URI to different clients depending on 
   where each is in the local access network if there is more than one
   PSAPs necessary within the underlying infrastructure.


Polk                       Expires Dec, 2006                   [Page 2]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006


   In a Voice over IP system, an emergency URI is an essential part of 
   configuration information necessary for usage by an client for the 
   particular purpose of contacting what is at that local URI.  

   Using SIP [RFC3261] as the application layer call message flow 
   example protocol, emergency calling wants the following message flow
   to occur when Alice is in trouble:

       Alice                              PSAP

            [M1] INVITE (sos & location)
          -------------------------------->

            [M2] 200 OK
          <-------------------------------

            [M3] ACK
          -------------------------------->

              Media Session Established
          <===============================>

       Figure 1. Basic Emergency Message Flow

   SIP uses an INVITE message as its initial call set-up message.  All 
   relevant addressing and other information can be in this one 
   message, including the destination URI (address) for Alice's 
   appropriate PSAP, given where she is.  Where Alice's voice device, 
   called a user agent (UA) by SIP, learned the destination URI is what
   this document solves for some network topologies.

   In Figure 1., Message-1 contains Alice's location, defined in 
   [ID-SIP-LOC], perhaps learned from the UA requesting DHC Option 123 
   [RFC3825] at boot time (shown in Figure 2).  This location 
   information, which is vital to an emergency call because it informs 
   the PSAP where to send first responders, is encoded inside the 
   INVITE's message body in the form of an XML document PIDF-LO  
   [RFC4119].  The destination URI can be learned via the UA performing
   a LoST [ID-LoST] mapping request itself, or in certain 
   circumstances, the UA could request a DHCP server do the mapping 
   query.  This is similar to how a DHCP server relays the necessary 
   information of a circuit-ID to a backend server to provide the 
   client its location.

   This mechanism is an alternative to each client having the LoST 
   protocol code within it, doing a LoST query during boot-time.

   This document does not limit the means of a client from gaining 
   knowledge of a SIP-URI to DHCP, but provides DHCP as a means for a 
   client to gain knowledge of a SIP-URI through local configuration, 
   considered essential for use by applications within that client.  


Polk                       Expires Dec, 2006                   [Page 3]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006


   Awareness of how stale a URI may become is something local 
   administrators should consider when implementing this Option.  For 
   this particular Option, DHCP servers are assumed to periodically 
   query an authoritative source providing non-stale or an updated URI.
   How this is accomplished is out of scope for this document.

   Section 2 provides an example message flow of what this document 
   achieves.  Section 3 states that a PSAP URI and an ESRP URI are to 
   be considered equivalent.  Section 4 shows the DHC Relay Option 
   Format.   Section 4.1 discusses the rules of usage of this Option. 
   Section 5 is the IANA Considerations section of this DHCP Option.  


1.1  Conventions used in this document

   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 [RFC 2119].

1.2  Terms, Acronyms and Definitions

   The following terms and acronyms are used within this document:

   Emergency Services Routing Proxy - a special instance of a SIP Proxy
      that understands emergency routing to a PSAP based on the 
      location of the caller

   ESRP - Emergency Services Routing Proxy

   Location-to-Service Translation Protocol - A mapping function 
      protocol that takes a given location and determines the PSAP URI 
      for a user who calls from that location.

   LoST - Location-to-Service Translation Protocol

   PSAP - Public Safety Answering Point

   Public Safety Answering Point - the emergency response call center 
      talking the local emergency calls from people in distress.  This 
      facility can be logical, and can transfer (reroute) any request 
      sent to it to another facility deemed more appropriate to receive
      the request.


2. Solution Message Flow Example

   Figure 2. dissects Figure 1. to provide where Alice's client learns 
   the essential configuration information to place an emergency call. 
   Omitted is SIP registration step, which may or may not be necessary,
   depending on location policy.



Polk                       Expires Dec, 2006                   [Page 4]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006

   In Message-3, Alice's client requests both Location and her PSAP 
   URI.  The server receives this request and generates Message-4, 
   this is a LoST query to a Mapping server.  Message-5 is the LoST 
   response.  Message-6 Provides Alice's client with her current PSAP 
   URI.

   Alice          DHCP Server        Mapping Server             PSAP

     [M1] DHCP DISCOVER (IP add, Subnet, Default GW, etc)
     ---------------->
     [M2] DHCP OFFER
     <----------------
     [M3] DHCP REQUEST or INFORM (Location, PSAP-URI)
     ---------------->

                       [M4] LoST Query (contains Location)
                       ------------------>
                       [M5] LoST Response (contains PSAP-URI)
                       <-----------------

     [M6] DHCP ACK (contains location & PSAP-URI)
     <----------------

           Emergency Call set-up initiated to DHCP supplied URI
     -----------..........------------........-------........------>

   Figure 2. Location-to-URI Mapping Requested by DHCP Server

   It is conceivable that this PSAP URI is not the primary URI used to 
   contact a PSAP should Alice call for help, but used as a back-up or 
   fallback SIP-URI used if an active mapping look-up fails.  This is 
   to be decided elsewhere.

   It is also possible that the server will not perform the LoST query 
   each time a client requests this information, depending on the 
   intervals since the last request for a PSAP-URI.


3. PSAP vs. ESRP URI - Why They Can Be the Same

   From Alice's point of view, reaching an ESRP can be the equivalent 
   of reaching a PSAP.  An ESRP is a SIP intermediary that understands 
   the concept of location and emergency calling.  This could well be 
   at the border of an Emergency Services Network, in which a group of 
   PSAPs are within.  The effort was to get the message to the ESRP, 
   knowing it will be able to "take it from here", meaning take it away
   from the burdens on the public network(s) that may or may not have 
   the functionality to perform all the necessary look-ups and such to 
   complete the call to the PSAP directly.  Further, there has been 
   talk of an Emergency Services Network acting as a buffer between the
   PSAPs and the public networks.  With this in mind, if local routing 
   decisions and local policy has an ESRP as Alice's destination, a URI


Polk                       Expires Dec, 2006                   [Page 5]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006

   called one is the same as a URI called the other.


4.  DHC Relay Option Format

   The format for this Option is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code XXX    |    Length     |      PSAP or ESRP URI         +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    PSAP or ESRP URI (cont'd)                  +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   PSAP or ESRP URI (cont'd to a maximum of 253 bytes)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1. The URI Option Format

   Code =        The IANA Assigned Option number

   Length =      one octet providing a variable length value of the 
                 number of bytes in the Option, including this length 
                 field

   URI         = This is a variable length field containing the URI 
                 being transmitted, to a maximum of 253 bytes in length


4.1  Rules of Usage

   The following are the rules of usage of this DHCP Option:

   - An ESRP URI is equivalent to a PSAP URI from the client's point of 
     view.  This terminology has not been worked out in some circles.

   - the schema used for a PSAP/ESRP URI is the SIP(S)-URI schema 
     [RFC3261]

   - a URI MUST NOT have a Length field of more than 253 (bytes), 
     complying with [RFC2131]

   - Clients making a request for one this URI, using a [REQUEST] 
     message, will send this message to the Server with URI length 
     field set to zero

   - Implementations of this Option SHOULD plan to have the contents of
     an initial PSAP-URI in an ACK refreshed periodically, either 
     through unsolicited server-to-client transmissions or client 
     requests.  Local policy SHOULD determine how and the rate.




Polk                       Expires Dec, 2006                   [Page 6]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006

5.  IANA Considerations

   IANA has assigned a DHCP option code of [XXX] for the PSAP-URI 
   option defined in this document.


6.  Security Considerations

   Where critical decisions might be based on the value of this URI
   option, DHCP authentication in [RFC3118] SHOULD be used to protect 
   the integrity of the DHCP options.

   Since there is no privacy protection for DHCP messages, an
   eavesdropper who can monitor the link between the client and
   destination DHCP server to capture any URIs in transit.

   When implementing a DHC server that will serve clients across an
   uncontrolled network, one should consider the potential security
   risks.

   There is a risk of the information in this ACK message becoming old,
   relative to the comfort of the PSAP community.  Although many wish 
   the Internet to be truly dynamic in its updates to topology changes 
   (for whatever reason), this does not always happen as planned.


7.  Acknowledgements

   To Andy Newton and Ralph Droms for guidance and assistance in the 
   shaping of this effort.  To Josh Littlefield, Ted Lemon, Andre 
   Kostur for their constructive comments.  Everyone can thank Stig 
   Venaas for his relentless pounding on me to break my original effort
   up into individual URIs per option (but that means you have more 
   docs to read too).


8.  References

8.1  Normative References

 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
           March 1997.

 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
           Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
           Session Initiation Protocol", RFC 3261, May 2002.

 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
           sip-location-conveyance-03.txt, "work in progress", June 
           2006

 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host


Polk                       Expires Dec, 2006                   [Page 7]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006

           Configuration Protocol Option for Coordinate-based Location
           Configuration Information", RFC 3825, July 2004

 [ID-LoST] T. Hardie, H. Schulzrinne, A. Newton, H. Tschofenig, "LoST: 
           A Location-to-Service Translation Protocol", 
           draft-hardie-ecrit-lost-00.txt, "work in progress", February 
           2006

 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 
           Messages", RFC 3118, June 2001.


8.2  Informative References

 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 
           Format", RFC 4119, December 2006


Author's Address

   James M. Polk
   3913 Treemont Circle
   Colleyville, Texas  76034
   USA

   Phone: +1-817-271-3552
   Fax:   none
   Email: jmpolk@cisco.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.   
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any


Polk                       Expires Dec, 2006                   [Page 8]
Internet-Draft        DHC Option for PSAP/ESRP URI            June 2006

   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).



























Polk                       Expires Dec, 2006                   [Page 9]