Download
relo retrieving end system location information n.
Skip this Video
Loading SlideShow in 5 Seconds..
March 2007 PowerPoint Presentation

March 2007

0 Views Download Presentation
Download Presentation

March 2007

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV 1

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

  3. Discovery • Currently, S-NAPTR – should probably be U-NAPTR – domain from host configuration (DHCP) or reverse DNS March 2007 IETF68 - GEOPRIV 3

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

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

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

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

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

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

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