Transcript PPT Version

RELO: Retrieving End System
Location Information
draft-schulzrinne-geopriv-relo-00
Henning Schulzrinne
July 2006
IETF66 - ECRIT
1
Motivation
• Layer-7 mapping of identifier to location
– typically network termination equipment
• DSL modem, 802.11 AP
• Work behind NAT
• Narrowly-focused protocol -- one purpose
– make it easier to specify interoperability
• Since just mapping, could map SNR
measurements to location…
July 2006
IETF66 - ECRIT
2
Discovery
• Currently, S-NAPTR
– should probably be U-NAPTR
– domain from host configuration (DHCP) or
reverse DNS
July 2006
IETF66 - ECRIT
3
Query
• Just send HTTP GET
– TLS RECOMMENDED
<?xml version="1.0" encoding="UTF-8"?>
<get-location by="value" type="civic” />
• Could also use GET
parameters, as in
– http://example.com?
by=value&
type=civic
July 2006
IETF66 - ECRIT
4
Response
• Returns location object or URI:
– <returnURI>
<URI>sip:[email protected]</URI>
</returnURI>
• Uses HTTP Expires header to indicate validity
• If error, use HTTP response
• To subscribe to location, insert Subscribe HTTP
header (and maybe Event)
– see SIP configuration framework for HTTP Event
header
July 2006
IETF66 - ECRIT
5
Design decisions
• No notion of context -- stateless
– no need for state maintenance
• Just location, no PIDF-LO
– avoid having to obscure privacy-sensitive information such as entity
URL
• First-party retrieval (mainly)
– reduce privacy risks
• Specify discovery mechanism
– use S-NAPTR (or U-NAPTR) via host name
• Allow other identifiers
– but only IP address specified until others are better understood
• Uses HTTP error codes, rather than define own
• Subscribe URL in response header
– separate discussion (tactical and technical)
July 2006
IETF66 - ECRIT
6
Open issues
• What other identifiers?
– must survive NAT and home routers
• e.g., MAC address unlikely to be useful
– examples:
• circuit ID
• signal strength and AP MACs
July 2006
IETF66 - ECRIT
7