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]