Internet DRAFT - draft-polk-dhc-ecrit-lost-server-uri
draft-polk-dhc-ecrit-lost-server-uri
DHC Working Group James Polk
Internet Draft Cisco Systems
Expiration: Dec 19th, 2006 June 19th, 2006
File: draft-polk-dhc-ecrit-lost-server-uri-00.txt
A Dynamic Host Configuration Protocol Option for
Requesting and Receiving a Uniform Resource Identifier
for a Location-to-Service Translation (LoST) Server
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 Dec 19th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a new Dynamic Host Configuration Protocol
(DHC) Option to deliver a Location-to-Service Translation (LoST)
Protocol URI to a client. This SIP(S)-URI will be become the
destination URI in any call set-up message to a Public Safety
Answering Point (PSAP) in times of an emergency.
Polk Expires Dec, 2006 [Page 1]
Internet-Draft DHC Option for LoST Server 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. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5
3.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Normative References . . . . . . . . . . . . . . . . . . 6
7.2 Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . 7
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
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 deliver a specific type of URI requested
by a client of a server, and transmitted unrequested from a server
to a client. The type of URI is that of a Location-to-Service
Translation (LoST) Protocol mapping server [ID-LOST].
A Public Safety Answering Point (PSAP) is an emergency call center;
most likely the first point of contact when a caller dials 911 or
112 (or another locally significant number) for emergency help.
These numbers are not routable, therefore the service within a given
jurisdiction cannot be accessed from outside a local area. Each
PSAP will have a unique URI. At issue is how an IP device conveys
Polk Expires Dec, 2006 [Page 2]
Internet-Draft DHC Option for LoST Server URI June 2006
where it is to get to its appropriate PSAP.
A local configuration network can provide a LoST server URI to a
client to request map of that client's location to a PSAP URI.
LoST mapping servers will likely have the necessary ability
(horsepower, memory, database, etc) to increase granularity within
the region's access networks to provide exactly which PSAP a caller
needs to contact, given their location.
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. Having
access to a mapping server that can provide this URI to a client is
critical.
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] or the Option that results from [ID-CIVIC] at boot time.
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 of this message
can be learned by the UA requesting a DHCP server do the mapping
query in certain circumstances or, the UA performing a LoST
Polk Expires Dec, 2006 [Page 3]
Internet-Draft DHC Option for LoST Server URI June 2006
[ID-LoST] mapping request itself. This document defines how the
client learns the URI of its LoST mapping server.
Section 2 provides an example message flow of what this document
achieves. Section 3 shows the DHC Relay Option Format. Section 3.1
discusses the rules of usage of this Option. Section 4 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 - A mapping function that takes a
given location and determines the PSAP URI for a user who calls
from that location.
LoST - Location-to-Service Translation
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. what can occur prior to the flow in Figure 1., showing
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.
In Message-3, Alice's client requests both Location and her LoST
server URI. The server acquires Alice's location (not explained
here) and looks up the appropriate LoST mapping server, and
generates Message-4. Message-5 is the LoST query to a Mapping
server for the appropriate PSAP SIP(S)-URI. Message-6 is the
Polk Expires Dec, 2006 [Page 4]
Internet-Draft DHC Option for LoST Server URI June 2006
mapping response providing 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, LoST-URI)
---------------->
[M4] DHCP ACK (contains location & LoST-URI)
<----------------
[M5] LoST Query (contains Location)
------------------------------------->
[M6] LoST Response (contains PSAP-URI)
<-------------------------------------
Emergency Call set-up initiated to LoST supplied URI
----------..........----------........-------........------>
Figure 2. Location-to-URI Mapping Requested by DHCP Server
Using this LoST URI, a client can contact the LoST server when a
user calls for emergency help, ensuring the PSAP URI retrieved is
the freshest it can be for the emergency call. The details of
emergency calling are out of scope for this Option, and are included
here to give applicability and justification to the Option.
3. 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 | URI of LoST Server +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI of LoST Server (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI of LoST Server (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
Polk Expires Dec, 2006 [Page 5]
Internet-Draft DHC Option for LoST Server URI June 2006
URI = This is a variable length field containing the URI
being transmitted, to a maximum of 253 bytes in length
3.1 Rules of Usage
The following are the rules of usage of this DHCP Option:
- a LoST mapping server 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
- The URI schema of the LoST URI has not been decided yet, as the
protocol transport is still up in the air. A future version of
this document will specify this schema.
4. IANA Considerations
IANA has assigned a DHCP option code of [XXX] for the LoST Mapping
Server URI option defined in this document.
5. 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.
6. Acknowledgements
Your name here... or you can contribute a fair amount of text and
become a co-author.
7. References
7.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Polk Expires Dec, 2006 [Page 6]
Internet-Draft DHC Option for LoST Server URI June 2006
March 1997.
[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.
7.2 Informative References
[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
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
progress", January 2006
[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
Polk Expires Dec, 2006 [Page 7]
Internet-Draft DHC Option for LoST Server URI June 2006
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
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 8]
