[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Spatial                                                        B. Rosen
Internet Draft                                                  Marconi
Document: draft-rosen-spatial-requirements-00.txt    Jose Costa -Requena
Category: Informational                                           Nokia
                                                        Mari Korkea-Aho
                                                                  Nokia
                                                        Mika Ylianttila
                                                     University of Oulu
                                                             Rohan Mahy
                                                          Cisco Systems
                                                        Kenji Takahashi
                                                                    NTT
                                                        Stephen Farrell
                                                 Baltimore Technologies


                 Spatial Location Protocol Requirements


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.





1. Abstract

   This document describes requirements to be placed on the Spatial
   Location Protocol (SloP).


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


            Spatial Location Protocol (SloP) Requirements    July 2000




3. Definition of Terms

   Target:      The entity whose location is known by the server and
                desired by the client.  The protocol does not specify
                how the server learns the location of the target.
   Server:      Entity which supplies the location of the target to the
                client.  One end of the protocol.
   Client:      The entity which desired to learn the location of the
                target.  One end of the protocol.
   Precision:   Number of digits to which the measurement is accurate
   Accuracy:    The measurement is correct to within this maximum
                expected error
   Exactness:   The precision of the reported value.
   Velocity:    Speed and direction
   Orientation: Heading or bearing on or near the surface of the Earth,
                with respect to True North
   Obfuscate:   To intentionally make the measurement less accurate by
                adding randomness.
   Geocentric:  With respect to, or centered upon the center of gravity
                of the Earth.



4. Location Representation

   A location representation is an instantiation of the location of a
   target.  In SLoP, location representations shall be determined
   through two levels of abstraction: schema and format.

   "Schema" defines the logical scheme the location representations are
   based on, such as WGS84.  "Format" defines how a given schema is
   represented.  A schema can be formatted in several ways.  For
   example, a location determined by WGS84 can be represented in a set
   of longitude, latitude, and altitude or geo-centric Cartesian
   coordination (X, Y, Z).

   The protocol must:
   a. Define one default location representation that must be supported
      by all SLOP entities.
   b. Specify an absolute location on the earth and use WGS84 geodetic
      datum as reference system for the default scheme.
   c. Specify the format of the default scheme in longitude, latitude,
      altitude parameters. Altitude may be an optional parameter.
   d. Support other location representations than the default,
      including existing schemes and formats widely used in other
      contexts. These location representations may be absolute or
      descriptive.
   e. Specify an IANA registration process for additional
      representations.



            Spatial Location Protocol (SloP) Requirements    July 2000


   f. Permit at a minimum, the following values to be included in a
      report, providing that the specified scheme and format have such
      capability to specify:

        1. Used location type (e.g absolute/descriptive location),
           framework (e.g. WGS84, UTM, etc), and syntax/format (e.g.
           long, lat., alt. in degrees).
        2. Geocentric Position
        3. Accuracy
        4. Exactness
        5. Time stamp (date, time, time zone)
        6. Time-to-live
        7. Direction
        8. Velocity
        9. Update frequency (??? do we want to include this?)
        10.            Orientation

   g. Permit multiple scheme/format representations in a single report.
   h. Client MUST be able to request certain elements of a format.
   i. Server MUST be able to provide certain elements of a format based
      on authorization policy (ex: give my speed, but not my position).
   j. Server MUST be able to obfuscate a (numeric/coordinate) location
      based on authorization policy.
   k. Be extendable to support new location representations.




5. Message Coding
   The protocol:

   a. MUST support multiple formats.  Each format must be registered
      with IANA.
   b. MUST support a very simple format for latitude, longitude, and
      altitude.
   c. MUST support a format for timestamp.
   d. SHOULD have a provision to specify the accuracy of each
      coordinate/measurement.
   e. MUST support a mechanism to allow sending of multiple formats in
      a single payload.
   f. MUST gracefully handle receipt of formats clients do not
      understand.
   g. MUST be able to infer the IANA type and the beginning and end of
      each format without parsing the entire message (as in TLV).
   h. MUST support sending multiple instances of the same format within
      the same packet.
   i. MUST allow formats to contain raw binary, UTF-8, UTF-16, or UTF-
      32 content.
   j. Must support formats which contain human-readable text.  Such
      text SHOULD specify the appropriate language.
   k. MUST be extensible/flexible enough to support a future
      descriptive location format.


            Spatial Location Protocol (SloP) Requirements    July 2000


   l. Formats which tend to be large SHOULD support a simple
      compression mechanism.
   m. Both client and server MUST be able to send and receive formats
      larger than a single packet.

6. Representation Negotiation

   The protocol must:
   a. Provide a mechanism for the server to inform the client which
      representations it supports.  Such a mechanism must be able to be
      invoked prior to the first location report.
   b. Provide a mechanism for the client to select which of said
      representations it prefers.
   c. Provide the capability to provide reports in any representation
   d. Provide that following such selection, reports are provided by
      the server in the format chosen by the client.
   e. Provide a mechanisms for the client to specify the need for
      periodic position updates.
   f. Provide a mechanism for the client and server to agree upon
      periodic position updates.


7. Server Discovery

   a. There SHALL be a server discovery mechanism for a client to find
      the appropriate server for a given target.
   b. The discovery mechanism SHALL work across domains.  It SHOULD use
      widely deployed mechanisms such as DNS.  It SHALL permit server
      locations to be changed with TTLs ranging from minutes to months.
   c. Targets SHALL be identified with an identifier.  The target
      identifier SHALL be unique within the domain of the server.
   d. Servers SHALL be identified by an identifier.  Server names SHALL
      be globally unique.  A URI of the form slop:haitao-tangs-
      phone@airtouch.com would be an appropriate way to identify a
      target, using the DNS to find the server.
   e. Clients MUST be able to perform DNS A and SRV lookups, and may
      support manual configuration and/or other methods to resolve the
      IP address of a suitable slop server in an unqualified domain.
   f. Translator services should be distinguishable from other servers
      during discovery.
   g. It is desirable that translator capabilities (supported formats)
      can be determined during discovery.



8. Transport

  a.  The protocol SHALL support UDP transport with retry timers for
      reliability.
  b.  The protocol SHOULD support TCP as an optional transport.
  c.  The protocol MAY support RTP and/or SCTP as optional transports



            Spatial Location Protocol (SloP) Requirements    July 2000


  d.  The protocol SHALL provide a mechanism for the client to request
      that location reports be delivered by the server using a client
      specified QoS class or using the QoS class of the request.  Such
      a mechanism SHALL be optional to implement, and SHALL use IETF

      DiffServ QoS classes.



9. Security

   The protocol must:
   a. Provide a mandatory-to-implement, optional-to-use authentication
      mechanism from client to server and from server to client. The
      mechanism should allow a choice in the algorithm(s) used.
   b. Specify how such a mechanism shall be used in the presence of
      firewalls and Network Address Translation (NAT) between client
      and server.
   c. Include mechanisms to allow subsequent location policy decisions
      to be based on (possibly multiple) factors in addition to the
      identity (or anonymity) or the client, e.g. authentication
      mechanism, group membership(s), class-of-user, etc.
   d. Provide a mandatory-to-implement, optional-to-use data integrity
      and data origin authentication mechanism for all data. The
      mechanism should allow a choice in the algorithm(s) used.
   e. Provide a mandatory-to-implement, optional-to-use data
      confidentiality mechanism. The mechanism should allow a choice in
      the algorithm(s) used.
   f. Not unnecessarily degrade a client's expectations of privacy.
   g. Support anonymous use, as well as authenticated use.

      Anonymous use MAY require the server(s) to be able to associate
      location with the same (anonymous) client over time.
   h. Where possible make use of existing, proven security mechanisms
      (e.g. TLS, CMS, IPsec), in particular with respect to
      cryptographic transforms.
   i. Specify a mechanism for extending the security mechanism for
      additional capability.


10. Policy

   The protocol must:
   a. Provide a mandatory-to-implement, optional-to-use _Policy
      Enforcement Point_ mechanism.
   b. Provide an optional _Policy Decision Point_ mechanism.
   c. Specify how servers obtain policy from a policy storage facility
      if the Policy Decision Point mechanism is implemented.
   d. Specify a _Policy Information Base_.
   e. Provide a mechanism to restrict the information in reports by:
        1. Accuracy of location
        2. Frequency of report generation
        3. Representation format

            Spatial Location Protocol (SloP) Requirements    July 2000


        4. Identity/class of report-requestor
   f. Specify the way that the PIB and class-of-user is used to
      restrict location information reported by interpreting policy
      selected by class of user.


11. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997





13. Author's Addresses

   Brian Rosen
   Marconi
   1000 FORE Drive
   Phone: +1 724 742 6826
   Email: brian.rosen@marconi.com

   Jose Costa-Requena
   Nokia
   Email: Jose.Costa-Requena@nokia.com

   Mari Korkea-Aho
   Nokia
   Email: mari.korkea-aho@nokia.com

   Mika Ylianttila
   Centre for Wireless Communications
   PL 4500, Tutkijantie 2 E, FIN-90014
   University of Oulu, Finland
   Email: over@ees2.oulu.fi

   Rohan Mahy
   Cisco Systems
   170 W Tasman Dr, MS: SJCI/2/3
   San Jose, CA 95134
   +1 408 526 8570
   rohan@cisco.com

   Kenji Takahashi
   Information Sharing Platform Laboratories
   NTT
   3-9-11 Midoricho
   Musashino, Tokyo 180-8585 Japan

            Spatial Location Protocol (SloP) Requirements    July 2000


   Phone: +81 422 59 6668
   e-mail: kt@nttlabs.com

   Stephen Farrell
   Baltimore Technologies
   61 Fitzwilliam Lane
   Dublin 2. Ireland
   Phone: +353 1 647 7406
   email: stephen.farrell@baltimore.ie




 14. Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into