Transcript PPT Version

HELD
Location Acquisition Solution
James Winterbottom
Andrew Corporation March 2007
HELD Background
• Based on real-world requirements stemming from work
in NENA and other standards bodies.
• Provides an application layer location acquisition
protocol not restricted to SIP
• Respects requirements laid out in RFC-3693
• Demonstrated applicability to residential broadband
deployments
• Recognizes that location requires a solution that
operates above layer 3.
• Defines a message exchange protocol for location
information. Different bindings can be used, HTTP is
described in the HELD draft.
• All functions originally included in HELD-00 have
subsequently been copied into at least one other georpiv
proposal
– HELD got it right from the start!
Basic HELD
• Very Simple!
–
–
–
–
–
HTTP GET to a URL.
Server-side certificate
Determination based on source IP address.
Security provided through TLS and return routability
Location provided as a PIDF-LO
• LIS discovery using draft-thomson-geopriv-lisdiscovery-00 which provides discovery through:
– Provisioning
– DHCP discovery
– DNS discovery through reverse DNS and U-NAPTR
Open Source LIS using HELD
• Supports most all of the HELD functionality.
– Initial implementation by second year undergraduate
engineering student in 2.5 weeks.
– EASY TO IMPLEMENT!
• Approximately 500 downloads since first
released
• Applications people are using for include:
– DRM based document viewing
– Location acquisition for VoIP location routing
demonstrations
– Office asset tracking
HELD Identity Extensions
• Supports Target identity extensions
(draft-winterbottom-geopriv-held-identity-extensions-01)
– necessary where target terminal correlators change
through a network (e.g. DSL).
• Assist a LIS in location determination
– Eg: providing LLDP switch and port parameters where
LLDP-MED is not deployed.
• Requests for additional parameters already being
received on the list suggesting that this is a necessary
specification
HELD Identity Extensions Example
locationRequest(E)
IP->E -> D -> C -> B -> A -> Location
E
ISP
Gateway
LIS
RBP
Primary
LIS
IP + E
C+D
ALE
ALE
E
D
C
B
A
DSLAM
End-Point
Location
ISP
Network Access Server
(NAS)
Broadband Remote
Access Server
(BRAS)
HELD Device Capabilities
• Often a device can assist in determining or is
capable of providing its own location
– Timing and signal strength measurements
– Satellite pseudo-range measurements
– Autonomous location determination
• Where a LIS is deployed in a network it may be
useful to share determination capabilities
between the Target Device and the LIS.
– improvements in yield
– More precise location information
– Reduced time to obtain location
HELD Device Capabilities
• Two basic
mechanisms
– Device specifies
capabilities to LIS, LIS
responds with
supported capabilities
– LIS indicates to device
what capabilities it can
provide
Target
Device
LIS
createContext (Capabilities A, B ,C)
contextResponse (Capabilities A)
Target
Device
LIS
createContext ()
contextResponse (Capabilities A)
Device to LIS capabilities
Exchange
Serving
station
Station-1
Signal
Strength
Request Power
Measurements
S1=2, S2=3, S3=5, S4=1
Signal
Strength
Signal
Strength
Signal
Strength
Station-2
Station-3
Station-4
LIS
LIS to Device Capabilities
Exchange
Target Field of View
SV-5
SV-3
SV-9
SV-7
SV-1
SV-2
Access
Point
LIS knows Device
LIS knows Access point
LIS Calculates assistance data
Request GNSS Assistance
Look for SV-2, SV-3, SV-7, SV-9
AP-A
AP-B
LIS
HELD BEEP Binding
• In IETF-64 Henning suggested that HELD-02 be
“unbundled” somewhat from HTTP, his
suggestion was SOAP.
• We went away and considered this and came
back with an XML schema that enforces the
semantics of HELD.
• This schema was then provided with a WSDL
binding for HTTP.
• This direction subsequently allowed us to
produce a HELD BEEP binding without change
the fundamental protocol.
Intent of BEEP binding
• The BEEP binding is intended to be used
in environments where there is an preexisting trust relationship between the
requesting node and the LIS.
– For example an OBO case.
• Allows HELD transactions to be streamed
to a LIS and for transactions be processed
in parallel.
L7 LCP Requirements
Compliance
L7-1: Identifier Choice
• "The LIS MUST be presented with a unique identifier of
its own addressing realm associated in some way with
the physical location of the end host.“
– COMPLY The identifier used may be the source address of the
request packet and/or additional client identifier values relevant
to the scope of the access network provided within the request.
Mapping an IP address into lower-level attachment data is
access network dependent and is the responsibility the LIS.
HELD can however be used to provide assistance to the LIS
through the inclusion of identity extensions such as those
defined in [I-D.winterbottom-geopriv-held-identity-extensions].
L7-2: Mobility Support
•
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a broad
range of mobility from devices that can only move between reboots, to devices that
can change attachment points with the impact that their IP address is changed, to
devices that do not change their IP address while roaming, to devices that
continuously move by being attached to the same network attachment point."
–
–
COMPLY Mobility support is inherently a characteristic of the access network technology and
HELD is designed to be access network agnostic. Consequently HELD complies with this
requirement. In addition HELD provides specific support for mobile environments by
providing an optional responseTime attribute in location request messages. Wireless
networks often have several different mechanisms at their disposal for position determination
(e.g. Assisted GPS versus location based on serving base station identity), each providing
different degrees of accuracy and taking different amounts of time to yield a result. The
responseTime parameter provides the LIS with a criterion which it can use to select a
location determination technique.
HELD also supports an extension mechanism that allows location measurement capabilities
to be exchanged between the end-point and the LIS. This mechanism allows for a greater
number of location determination techniques to be used by both the end-point and the LIS.
The specification describing this capability is provided in [I-D.thomson-geopriv-heldcapabilities].
L7-3: Layer 7 and Layer 2/3
Provider Relationship
• "The design of the GEOPRIV Layer 7 Location
Configuration Protocol MUST NOT assume a
business or trust relationship between the
provider of application layer (e.g., SIP, XMPP,
H.323) provider and the access network provider
operating the LIS."
– COMPLY HELD describes a location acquisition
protocol and has no dependencies on how location is
used once it has been acquired. Location acquisition
using HELD is subject to the restrictions described in
Section 8.
L7-4: Layer 2 and Layer 3 Provider
Relationship
•
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between the
L2 and the L3 provider. The L3 provider operates the LIS and needs to
obtain location information from the L2 provider since this one is closest to
the end host. If the L2 and L3 provider for the same host are different
entities, they cooperate for the purposes needed to determine end system
locations."
– COMPLY HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change in protocol
being required. Examples of how HELD can be used in this manner are provided
in detail in [NENA_TID]. HELD is a webservices protocol it can be bound to
transports other than HTTP, for example a BEEP binding for HELD, [ID.thomson-geopriv-held-beep]. Using a transport like BEEP for HELD offers the
option of high request throughput over a dedicated connection between an L3
provider and an L2 provider without incurring the serial restriction imposed by
HTTP. This is less easy to do with protocols that do not decouple themselves
from the transport.
L7-5: Legacy Device
Considerations
• "The design of the GEOPRIV Layer 7 Location
Configuration Protocol MUST consider legacy residential
NAT devices and NTEs in an DSL environment that
cannot be upgraded to support additional protocols, for
example to pass additional information through DHCP."
– COMPLY HELD is an application protocol and operates on top of
IP. A HELD request from a host behind a residential NAT will
traverse the NAT acquiring the external address of the home
router. The location provided to the host therefore will be the
address of the home router in this circumstance. No changes are
required to the home router in order to support this function,
HELD was designed specifically to address this deployment
scenario. Examples of how HELD can be used in this type of
network environment are provided in [NENA_TID].
L7-6: VPN Awareness
• "The design of the GEOPRIV Layer 7 Location
Configuration Protocol MUST assume that at least one
end of a VPN is aware of the VPN functionality. In an
enterprise scenario, the enterprise side will provide the
LIS used by the client and can thereby detect whether
the LIS request was initiated through a VPN tunnel."
– COMPLY HELD does not preclude a LIS on the far end of a VPN
tunnel being aware that the client request is occurring over that
tunnel. It also does not preclude a client device from accessing a
LIS serving the local physical network and subsequently using
the location information with an application that is accessed over
a VPN tunnel.
L7-7: Network Access
Authentication
• "The design of the GEOPRIV Layer 7 Location
Configuration Protocol MUST NOT assume prior
network access authentication."
– COMPLY HELD makes no assumptions about prior
network access authentication. HELD strongly
recommends the use of TLS with server-side
certificates for communication between the end-point
and the LIS. There is no requirement for the end-point
to authenticate with the LIS.
L7-8: Network Topology
Unawareness
• "The design of the GEOPRIV Layer 7 Location Configuration
Protocol MUST NOT assume end systems being aware of the
access network topology. End systems are, however, able to
determine their public IP address(es) via mechanisms such as
STUN or NSIS NATFW NSLP."
– COMPLY HELD makes no assumption about the network topology.
HELD doesn't require that the device know its external IP address,
except where that is required for discovery of the LIS. LIS discovery
techniques available to a HELD client are described in [I-D.thomsongeopriv-lis-discovery]. In certain network environments an end-point
maybe able to ascertain information about the topology of the access
network which may assist the LIS in location determination. HELD
provides support for extensions that allow this information to be
communicated to the LIS when it is available.
Location By Reference
Requirements Compliance
Rq1
• “Location Reference Identifier as a URI:
The dereferencing protocol MUST support
an LRI in URI form, and may support other
non-URI forms.”
– COMPLY. HELD provides all references in the
form of a URI.
Rq2
• “Dereference Protocol Confidentiality: The
dereferencing protocol MUST support
mechanisms for encrypting messages sent
between client (Location recipient) and
server (Location server). “
– COMPLY. HELD strongly recommends the
use of HTTPS.
Rq3
• Dereference Protocol Transparency: The dereferencing
protocol MUST support the exchange of messages
without encryption (i.e., in plaintext).
• Motivation: In the case where encrypted message
exchange is unsuccessful, there must be a way to try to
dereference a location reference identifier with less
restriction (e..g., in the emergency service case, where
every call always needs answered).
– Comply: HELD does not prohibit the LIS from being deployed in
this manner.
Rq4
• Location Reference Expiry: The dereference protocol
MUST support specification of a finite period of validity
for the LRI.
• Motivation: Location references are not intended to
represent a location forever, and the identifier eventually
may need to be recycled, or may be subject to a specific
window of validity, after which the location reference fails
to yield a location, or the location is determined to be
kept confidential. An expiry timer for a location reference
ensures that the location reference becomes invalid
based on configuration.
– COMPLY. All contexts created on the LIS are created for a finite
time under the direct control of the Target. Context lifetimes may
be extended or terminated by the Target at any time.
Rq5
• Dereference Protocol Transport: The dereference protocol MUST support TCP/IP
and MAY support UDP/IP.
• Motivation: Practical, near-term
deployment issues may make TCP/IP
implementations unachievable.
– Comply. The basic HELD binding is to HTTP
which is TCP based.
Rq6
• Dereference Protocol Authentication: The
dereferencing protocol MUST support both
client-side and server-side authentication.
• Motivation: It is reasonable to expect
implementations of authentication to vary. Some
implementations may choose to support both
client-side and server-side authentication, might
support one only, or may support neither.
– COMPLY: HELD provides server-side authentication
through TLS. HELD can implicitly use any client-side
authentication mechanism available in HTTP.
Rq7
• Location Privacy: The dereference protocol
MUST support the application of privacy rules to
the dissemination of a requested location object.
– COMPLY: HELD supports the Target providing values
to be included in the usage elements of any PIDF-LO
generated by the LIS for the Target.
– In addition HELD support the Target providing ruleset
to the LIS constraining to whom the LIS may provide
location information. These rules may be changed at
anytime by the Target.
Rq8
• Dereferenced PIDF-LO Result: The
dereferencing of an LRI MUST result in a wellformed PIDF-LO.
• Motivation: This is in order to ensure adequate
privacy rules can be adhered to, since the PIDFLO format comprises the necessary structures to
maintain location privacy.
– COMPLY. HELD provides location only in PIDF-LO
form. PIDF-LOs generated by a HELD compliant LIS
MUST comply with the guidelines set out in PIDF-LO
profile.