100 likes | 110 Views
RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne. March 2007. IETF68 - GEOPRIV. 1. Motivation. • Layer-7 mapping of identifier to location – typically network termination equipment • DSL modem, 802.11 AP
E N D
RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV 1
Motivation • Layer-7 mapping of identifier to location – typically network termination equipment • DSL modem, 802.11 AP • Believed to satisfy L7-LCP requirements • Narrowly-focused protocol -- one purpose – make it easier to specify interoperability • Since just mapping, could map SNR measurements to location… March 2007 IETF68 - GEOPRIV 2
Discovery • Currently, S-NAPTR – should probably be U-NAPTR – domain from host configuration (DHCP) or reverse DNS March 2007 IETF68 - GEOPRIV 3
Query Parameters: – by: value or reference – within: time willing to wait – type: civic or geo – retransmission-allowed: yes/no – retention-expiry: usage rule – external-ruleset: usage rule – note-well: usage rule – url: URL to renew – expires: LO/LR should expire – secret: secret for modification – assert: LO to store • Just send HTTP GET – TLS RECOMMENDED • Uses GET parameters, as in – http://example.com?by=value &type=civic • March 2007 IETF68 - GEOPRIV 4
Identifiers • Default: IP address of request • mac: MAC address • cdp: Cisco Discovery Protocol string • msap: MAC service access point (LLDP) March 2007 IETF68 - GEOPRIV 5
Operations OBO/... LIS-LIS just variants of LbyR • Retrieval – civic or geo, value or reference • Renewal of reference lifetime – provide URL and secret • Assertion – provide LO for storage and/or signature March 2007 IETF68 - GEOPRIV 6
Response • Returns location object or URI (reference) – text/uri-list – acceptable location types indicated by Accept header • Uses HTTP Expires header to indicate validity • If error, use HTTP response – sufficient for error detection, with HTTP response body • To subscribe to location, insert Subscribe HTTP header (and maybe Event) – see SIP configuration framework for HTTP Event header March 2007 IETF68 - GEOPRIV 7
Design decisions • No notion of context -- stateless – no need for state maintenance • PIDF-LO (or any other future LO) • First-party retrieval (mainly) – reduce privacy risks • Specify discovery mechanism -- see related draft – use S-NAPTR (or U-NAPTR) via host name • Allow other identifiers • Uses HTTP error codes and status line, rather than define own • Subscribe URL in response header – separate discussion (tactical and technical) March 2007 IETF68 - GEOPRIV 8
Requirements • L7-1: Identifier choice – several, extensible • L7-2: Mobility choice – subscription or polling • L7-3: Layer 7 and Layer 2/3 Provider Relationship – none assumed • L7-4: Layer 2 and Layer 3 Provider Relationship – satisfied • L7-5: Legacy devices – satisfied March 2007 IETF68 - GEOPRIV 9
Requirements • L7-6: VPN awareness – prior to VPN attachment • L7-7: Network access authentication – none assumed • L7-8: Network topology unawareness – doesn’t care March 2007 IETF68 - GEOPRIV 10