


Network Working Group                                         M R. Tyson
Internet-Draft                                                   C. Kopp
Intended status: Experimental                          Monash University
Expires: June 21, 2008                                 December 19, 2007


   The Lightweight Global Navigation Satellite System (GNSS) Support
                            Protocol (LGSP)
                        draft-tyson-lgsp-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on June 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Tyson & Kopp              Expires June 21, 2008                 [Page 1]

Internet-Draft                    LGSP                     December 2007


Abstract

   This document presents the Lightweight GNSS (Global Navigation
   Satellite System) Support Protocol (LGSP).  The Lightweight GNSS
   Support Protocol (LGSP) is being developed in order to provide a
   comprehensive solution which solves the problems inherent in
   traditional radio-based Differential GPS (DGPS) protocols.  LGSP will
   also provide additional support for GNSS user equipment, such as a
   GPS almanac retrieval method, allowing compatible units to perform
   faster almanac acquisition, thus resulting in less time until an
   initial position measurement can be established.  Other supporting
   features include alternative distribution of GPS navigation messages
   and differential correction messages, a hierarchical mirroring
   architecture, redundant backup operation and load balancing
   functions.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  System Overview  . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . 12
     2.3.  GNSS Message Overview  . . . . . . . . . . . . . . . . . . 14
       2.3.1.  GPS Family Messaging . . . . . . . . . . . . . . . . . 15
       2.3.2.  Galileo Family Messaging . . . . . . . . . . . . . . . 16
       2.3.3.  GLONASS Family Messaging . . . . . . . . . . . . . . . 17
   3.  Protocol Definition  . . . . . . . . . . . . . . . . . . . . . 19
     3.1.  Messaging Modes  . . . . . . . . . . . . . . . . . . . . . 19
       3.1.1.  Request/Response . . . . . . . . . . . . . . . . . . . 19
       3.1.2.  Streaming  . . . . . . . . . . . . . . . . . . . . . . 21
     3.2.  Basic Message Formats  . . . . . . . . . . . . . . . . . . 24
       3.2.1.  Request Message  . . . . . . . . . . . . . . . . . . . 25
       3.2.2.  Response Message . . . . . . . . . . . . . . . . . . . 26
       3.2.3.  Join Stream Request Message  . . . . . . . . . . . . . 27
       3.2.4.  Join Stream Response Message . . . . . . . . . . . . . 28
       3.2.5.  GNSS Request Message . . . . . . . . . . . . . . . . . 29
       3.2.6.  GNSS Response Message  . . . . . . . . . . . . . . . . 30
     3.3.  Robustness and Cryptographic Security  . . . . . . . . . . 30
       3.3.1.  Protection For Request/Response Sessions . . . . . . . 31
       3.3.2.  Protection for Stream Sessions . . . . . . . . . . . . 32
     3.4.  Authentication for Access Control  . . . . . . . . . . . . 33
     3.5.  Extension Provisions . . . . . . . . . . . . . . . . . . . 33
       3.5.1.  Extended Request Message . . . . . . . . . . . . . . . 35
       3.5.2.  Extended Response Message  . . . . . . . . . . . . . . 35
     3.6.  Mirroring  . . . . . . . . . . . . . . . . . . . . . . . . 37
       3.6.1.  Full Sync Request Message  . . . . . . . . . . . . . . 38
       3.6.2.  Full Sync Response Message . . . . . . . . . . . . . . 39



Tyson & Kopp              Expires June 21, 2008                 [Page 2]

Internet-Draft                    LGSP                     December 2007


       3.6.3.  Differential Sync Request Message  . . . . . . . . . . 41
       3.6.4.  Differential Sync Response Message . . . . . . . . . . 42
     3.7.  Backup Servers . . . . . . . . . . . . . . . . . . . . . . 42
     3.8.  Status Information . . . . . . . . . . . . . . . . . . . . 45
       3.8.1.  Status Request Message . . . . . . . . . . . . . . . . 45
       3.8.2.  Status Response Message  . . . . . . . . . . . . . . . 46
     3.9.  Load Balancing . . . . . . . . . . . . . . . . . . . . . . 47
   4.  System Protocol Identifiers  . . . . . . . . . . . . . . . . . 49
     4.1.  System Identifiers . . . . . . . . . . . . . . . . . . . . 49
     4.2.  Request Types  . . . . . . . . . . . . . . . . . . . . . . 49
   5.  Reserved Response Codes  . . . . . . . . . . . . . . . . . . . 53
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 54
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 56
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 56
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
   Intellectual Property and Copyright Statements . . . . . . . . . . 60

































Tyson & Kopp              Expires June 21, 2008                 [Page 3]

Internet-Draft                    LGSP                     December 2007


1.  Introduction

   Global Navigation Satellite Systems comprise constellations of
   orbiting satellites that transmit specific signals to Earth, which
   are utilised by a receiver to calculate an estimated location of the
   user (Figure 1).  Such systems, which include the U.S. Global
   Positioning System (GPS), the Russian Global Navigation Satellite
   System (GLONASS), and the fledgling European Galileo, are utilised
   for a variety of applications, including land, air and sea
   navigation, surveying and geology and accurate positioning for
   military applications.  [GLONASS-ICD][GPS-IS][Galilei][GGW]


                            GPS SV       GPS SV
                 GPS SV      =||=         =||=    GPS SV
                  =||=         \           /       =||=
                    `-.         \         /        .-'
                       `-.       \       /      .-'
                          `-._    \     /    .-'
                              `-.  \   /  .-'
                                 `-.\ /.-'
                                     ,
                                   <==/=  Airborne platform
                                 with GPS receiver hardware
                               _,..-------..._
                          ,.-''               `'-..
                       ,-'                         `-.
                     -'            EARTH              `-

                       Figure 1: GPS CONOPS Example

   Due to a variety of factors including atmospheric effects such as
   tropospheric and ionospheric delays, clock drift, out-of-date orbital
   data and geometrical dilution of precision, the calculated positions
   typically involve some time variant error.  In order to improve
   precision, various differential schemes have been developed.  These
   mostly employ precisely surveyed ground-based stations which generate
   and distribute periodic correction messages for use by compatible
   receivers.  Such Differential GPS (DGPS) systems can operate in a
   local geography, essentially generating differential co-ordinates
   that offer accurate corrections within a small area - these are known
   as Local Area DGPS systems (LADGPS).  Alternatively, Wide Area DGPS
   systems (WADGPS) offer corrections that are valid over a much larger
   area, generally continental, and typically generate models to
   represent different sources of error, instead of simple offset co-
   ordinates (Figure 2).  [LAAS][WAAS][EDGE][WAGE]





Tyson & Kopp              Expires June 21, 2008                 [Page 4]

Internet-Draft                    LGSP                     December 2007


                                  \\    Communications SV
                                   ===    (INMARSAT I-3)
                                     \\
                                     |
                            GPS SV   |   GPS SV
                  GPS SV     =||=    |    =||=    GPS SV
                   =||=        \     |     /       =||=
                     `-.        \    |    /        .-'
                        `-.      \   |   /      .-'
                           `._    \  |  /    .-'
                              `-.  \ | /  .-'
                                 `-.\|/.-'
                                     '
                               __ <==/=  Airborne platform
                  VHF    __.-''
                  WAAS ('    _,..-------..._
                  GS   \\,.-'               `'-..
                      ,-'                        `-.
                    -'             EARTH            `-

                       Figure 2: WAAS CONOPS Example

   Differential GPS corrections are typically broadcast over a
   specialised radio channel.  The widely used WADGPS system known as
   the Wide Area Augmentation System (WAAS) [WAAS], developed by the
   Federal Aviation Administration (FAA), uses a number of satellites to
   broadcast differential information.  Most LADGPS systems, such as the
   FAA's Local Area Augmentation System (LAAS) [LAAS], use a local radio
   transmitter to distribute corrections.

   There are a number of drawbacks inherent in traditional DGPS systems.
   The use of a radio link for DGPS means that a dedicated, discrete
   channel is required for each system.  Firstly, hardware for
   maintaining a radio link represents a significant cost to a DGPS
   system, both monetarily and in terms of power consumption, hardware
   reliability and heat dissipation.  A dedicated channel also results
   in relatively sub-optimal use of the available radio spectrum, a
   finite resource.  As wireless technologies become increasingly
   popular, and radio spectrum usage increases, it will be increasingly
   important to utilise spectrum efficiently.  In addition, the
   widespread use of wireless devices, as well as digital electronics in
   general, results in interference issues.  Combined with intentional
   jamming, this presents a developing vulnerability for radio-based
   DGPS, requiring more robust and complex components, in turn raising
   the cost of DGPS hardware.  Traditional DGPS channels also typically
   have a low data rate, resulting in slow update rates.  Multipath and
   other radio propagation issues represent another impairment, further
   constraining traditional DGPS system implementations.



Tyson & Kopp              Expires June 21, 2008                 [Page 5]

Internet-Draft                    LGSP                     December 2007


   Many DGPS-equipped platforms also contain some other form of wireless
   connectivity, such as IP (Internet Protocol) [RFC0791] wireless via
   satellite or another high capacity channel like the U.S. Military's
   Joint Tactical Information Distribution System (JTIDS)
   [JTIDS-MIDS][JTIDS-IP] or civilian channels such as WiFi
   [IEEE802.11], WiMAX [WiMax] or GPRS [GPRS].

   Such channels are typically more robust, faster and more affordable
   than specialised dedicated links, and are typically also
   bidirectional, providing for more flexible operation.  By using an
   existing channel for DGPS correction update distribution, instead of
   establishing new dedicated channels, costs can lowered, while
   increasing robustness and availability of communications.  If a DGPS
   system makes use of an established link technology, dedicated radio
   hardware is not required.  In addition, existing channels typically
   provide high availability, jam or interference resistance and
   reliability, which a DGPS system would benefit from.


































Tyson & Kopp              Expires June 21, 2008                 [Page 6]

Internet-Draft                    LGSP                     December 2007


2.  Overview

   LGSP is a client/server protocol.  It allows clients to retrieve
   GNSS-related data, such as almanac data, or DGPS corrections.  LGSP
   operates over UDP, and does not keep per-session state except where
   necessary for channel protection purposes.

   LGSP defines a modular architecture, providing for future expansion
   and new message types.  LGSP has a redundant hierarchical structure
   of LGSP Master Nodes and LGSP Mirror Nodes, providing a high degree
   of robustness.

   A number of message types are defined in this document for the three
   main GNSS systems, the United States' Global Positioning System (GPS)
   [GPS-IS], the European Galileo [Galilei] and the Russian GLONASS
   [GLONASS-ICD], and a few augmentation systems such as the Wide Area
   Augmentation System (WAAS) [WAAS].

   LGSP offers both protected and unprotected modes, for operation on a
   variety of channel types.  LGSP's protected mode offers channel
   protection in the form of encryption, wrapped in a FEC (Forward Error
   Control) code, and is designed for operation over rudimentary
   channels lacking adequate protection.  Alternatively, LGSP's
   unprotected mode is designed for more robust and secure channels,
   which already have protection and thus do not require the overhead of
   addition protection layers.

   Additional LGSP features include mirroring, load balancing and
   provisions for multiply-redundant backup server operation.

2.1.  System Overview

   The system architecture of a single LGSP server comprises three
   elements: One or more source feeds, a server unit, and client units
   (Figure 3) [LGSP].
















Tyson & Kopp              Expires June 21, 2008                 [Page 7]

Internet-Draft                    LGSP                     December 2007


                 Sources                           Clients
                   ,-.                               ,-.
                  (   )---.                     ,-->(   )
                   `-'    |                     |    `-'
                          |   +-------------+   |
                   ,-.    '-->|    LGSP     |---'    ,-.
                  (   )------>|             |------>(   )
                   `-'    .-->|   STATION   |---.    `-'
                          |   +-------------+   |
                   ,-.    |                     |    ,-.
                  (   )---'                     '-->(   )
                   `-'                               `-'

                  Figure 3: System architecture overview

   Source feeds are incoming sources of data.  This can be a radio
   receiving transmitted DGPS signals such as WAAS [WAAS], for example.
   Alternatively, a direct communications link to a DGPS station could
   replace the radio receiver, offering a more reliable and high-
   bandwidth link.  Such a software module would store received messages
   in a buffer, for subsequent retrieval by clients.

   A local geographically-surveyed GPS receiver with accompanying
   software to generate a Local Area DGPS signal could be used as
   another source feed.  Additionally, a GPS receiver can be used to
   record GPS messages for subsequent distribution.

   A direct communications link to a GNSS control centre offers a
   reliable and flexible high-bandwidth link for direct distribution of
   GNSS navigation messages.  This allows LGSP to offer a high
   performance distribution channel for navigation data, as well as for
   supporting GNSS data that may not be feasibly broadcast over the
   traditional space-based channel, due to bandwidth, latency or
   security limitations.

   Wide area differential systems, such as the US Air Force EDGE RRN
   demonstrator [EDGE] and WAGE [WAGE] system represent other possible
   sources of data, either via a radio link or a direct connection to a
   master station.

   Source feeds are paired with an accompanying software module within
   the LGSP server software, which provides functionality for storing
   and later accessing the source data.  Each software module implements
   a source-specific network protocol that is encapsulated within LGSP,
   and understood by a corresponding software module located in the LGSP
   client software.

   The LGSP server is a unit which assimilates the data incoming from



Tyson & Kopp              Expires June 21, 2008                 [Page 8]

Internet-Draft                    LGSP                     December 2007


   the sources, and provides an interface (LGSP) for dissemination of
   this data.  The LGSP server provides a relatively simple and robust
   mechanism for serving clients.  The server is largely stateless,
   except for provisions for streaming functionality and channel
   protection, and thus does not attempt to provide guaranteed service
   in any way.  This enhances the protocol's robustness, so that clients
   operating over unstable channels do not needlessly tie up server
   resources.  No retransmissions are attempted in the case of packet
   loss when sending to a client.  Connectionless UDP datagram
   communications are used, which ensures that server resources will not
   be tied up if a client drops out.  These features are tailored for
   maximum performance in the presence of a poor network operating
   environment, with frequent disconnections and packet loss; such
   conditions are common in a mobile wireless scenario.

   We envisage a hierarchy of LGSP servers with redundancy, similar in
   concept to that of DNS (Domain Name System) [RFC1034][RFC1035].  LGSP
   Master Station Nodes form the top level of the hierarchy, while LGSP
   Mirror Nodes form the remainder of the tree.

   Clients access LGSP Mirror Nodes only.  LGSP Master Station Nodes
   will only accept connections from other LGSP Master Station Nodes, or
   LGSP Mirror Nodes.  This avoids the danger of overloading an LGSP
   Master Station Node with too many incoming connections, as there will
   only ever be a relatively small number of LGSP Mirror Nodes
   connecting to an LGSP Master Station Node at any time.

   As in DNS's redundant name server architecture, LGSP clients maintain
   knowledge of multiple LGSP Mirror Nodes, for redundancy and load
   balancing purposes (Section 3.9).  Similarly, LGSP Mirror Nodes
   themselves can maintain knowledge of multiple LGSP Mirror Nodes and
   multiple LGSP Master Nodes.

   The two LGSP server types are defined below:

















Tyson & Kopp              Expires June 21, 2008                 [Page 9]

Internet-Draft                    LGSP                     December 2007


             ,-.
            (   )--.
             `-'   |
                   |   +----------------+      ,-. ,-.,-.         +--+
             ,-.   '-->| MASTER STATION |     (          )      +--+ |
            (   )----->|                |----> ; NETWORK'. ---> |  | |
             `-'   .-->|      NODE      |     (           )     |  |-+
                   |   +----------------+      `-'(   )`-'      +--+
             ,-.   |                               ` '
            (   )--'                                             LGSP
             `-'                                                Mirror
     GNSS master stations                                        Nodes
     Local Area DGPS feed
          GNSS SVs
          Network

                   Figure 4: LGSP Master Station example

   An LGSP Master Station Node (Figure 4) provides service to LGSP
   Mirror Nodes, forming the top level of the hierarchy.  Master Station
   Nodes can typically have a connection to a GNSS master station, such
   as the GPS control segment.

   The primary function of LGSP Master Station Nodes is to present a
   standard interface to access GNSS data from one or more GNSS master
   stations.  This also offers firewall-type functionality to isolate
   the GNSS master stations.  LGSP Master Station Nodes can also source
   data from elsewhere, such as a Local Area DGPS feed.

   LGSP Master Station Nodes will only accept connections from LGSP
   Mirror Nodes, and reject connections from LGSP clients.  LGSP clients
   connect to an LGSP Mirror Node to gain access.  This avoids possible
   overloading of the LGSP Master Node, ensuring maximum availability.


















Tyson & Kopp              Expires June 21, 2008                [Page 10]

Internet-Draft                    LGSP                     December 2007


     +---+    ,-. ,-.,-.
     |   |   (          )
     |   |--> ; NETWORK'.
     |   |   (           )                                        ,-.
     +---+    `-'(   )`-'                                     +->(   )
     LGSP         ` ' |                                       |   `-'
    MASTER            |   +----------------+    ,-. ,-.,-.    |
     NODE       ,-.   '-->|                |   (          ) --'   ,-.
               (   )----->|   MIRROR NODE  |--> ; NETWORK'. ---->(   )
                `-'   .-->|                |   (           )--.   `-'
                      |   +----------------+    `-'(   )`-'   |
                ,-.   |                             ` '       |   ,-.
               (   )--+                                       +->(   )
                `-'                                               `-'
        Local Area DGPS feed                               LGSP Clients
             GNSS SVs

                    Figure 5: LGSP Mirror Node example

   LGSP Mirror Nodes (Figure 5) connect to one or more LGSP Master
   Station Nodes and mirror data to a local cache, which is updated
   periodically (Section 3.6).  LGSP Mirror Nodes provide both
   redundancy and load balancing (Section 3.9).  A Mirror Node that is
   geographically proximate to a client accessing it offers reduced
   latency as communications have less distance to travel, and greater
   security due to the shorter communication path, resulting in less
   exposure to malicious parties.

   LGSP Mirror Nodes can also obtain data from other sources, such as a
   Local Area DGPS feed, as described above.  Additionally, an LGSP
   Mirror Node that loses all connections to other LGSP Mirror Nodes or
   LGSP Master Nodes can source GNSS data from a GNSS satellite.  Such
   functionality can be considered a 'casualty mode' that provides some
   level of service even in the event of multiple connection failures to
   LGSP Master Nodes or LGSP Mirror Nodes.

   An LGSP client, when accessing an LGSP Mirror Node, will request the
   current status of the Mirror Node.  The client will evaluate the
   response, and determine the level of load the Mirror Node is under.
   If load is high, the client will attempt a connection with the next
   LGSP Mirror Node it is aware of.  By adding load sharing facilities
   to the communication protocol, clients actively avoid placing too
   much strain on the resources of any particular LGSP Mirror Node
   (Section 3.9).

   Similarly, if a connection to an LGSP Mirror Node fails, an LGSP
   client will simply move on to the next LGSP Mirror Node it is aware
   of.  In the same fashion, LGSP Mirror Nodes will attempt to contact



Tyson & Kopp              Expires June 21, 2008                [Page 11]

Internet-Draft                    LGSP                     December 2007


   other LGSP Master Station Nodes or Mirror Nodes if a connection
   cannot be made.  This redundant architecture offers considerably more
   robustness than an architecture with a single point-of-failure.

   LGSP clients are units connected to the LGSP server via a network
   connection, typically the Internet or another network with the
   capability to tunnel IP traffic: a military network such as JTRS
   [JTRS], Joint Tactical Information Distribution System/
   Multifunctional Information Distribution System (JTIDS/MIDS)
   [JTIDS-MIDS], a Satcom link, IP over Improved Data Modem (IDM) links,
   or IP over Family of Advanced Beyond-Line-of-Sight Terminals (FAB-T)
   links [FAB-T], or a civilian system like WiMAX [WiMax], GPRS [GPRS],
   WiFi [IEEE802.11] or GSM [GSM].

   LGSP clients could be human portable devices with integrated GPS
   navigation systems such as a mobile phone, PDA (Portable Data
   Assistant) or a laptop, or GPS-equipped platform devices, such as an
   airborne platform, automobile or ship.

   LGSP clients will be equipped with GPS receiver hardware and other
   supporting infrastructure.  In the case of a platform-based client,
   the LGSP client software can be integrated into the navigation
   computer, with few other modifications required.

2.2.  Protocol Overview

   LGSP makes data available to clients via two messaging mechanisms: A
   request/response mechanism, and a multicast streaming mechanism
   (Section 3.1).  The former involves a single request message
   originating from a client, invoking a single response message from
   the server.  This is a self-contained transaction, and no state is
   maintained between such transactions.  The latter, multicast
   streaming mechanism, allows data to be continually broadcast to
   listening clients, and is initiated upon an initial request by a
   client.

   LGSP's request/response mode is simple, and by not maintaining state
   between consecutive transactions is able to remain robust and
   efficient in the face of unreliable connections.  As no persistent
   state is maintained between connections, few resources are expended
   on maintaining sessions.  This is an important property for a
   protocol that may frequently operate over unreliable channels.

   LGSP's multicast streaming mode offers a mechanism to distribute data
   to a large number of clients, with lower bandwidth and processor
   resource requirements than would otherwise exist with only a per-
   client request/response mode.




Tyson & Kopp              Expires June 21, 2008                [Page 12]

Internet-Draft                    LGSP                     December 2007


   Request/response mode is suitable for messaging formats which offer
   discrete blocks of data with a relatively slow update rate, or which
   require bidirectional communication.  Streaming mode suits system
   protocols which distribute continuous streams of information, such as
   frequent local Differential GPS (DGPS) updates.  In particular, the
   use of streaming modes is appropriate when the distributed data has a
   short life-span.

   LGSP is designed to be operated over a wide variety of channel types.
   These could include secure and robust channels such as the U.S.
   Military's Joint Tactical Radio System (JTRS) or the Joint Tactical
   Information Distribution System (JTIDS), or the civilian WiMAX.
   Alternately, channels may also possess poor security features and/or
   poor reliability and robustness; such channels include GPRS, WiFi, or
   rudimentary satellite communications links.

   To cater for this large variation in channel characteristics, LGSP
   defines a protected mode and an unprotected mode (Section 3.3).
   LGSP's protected mode, designed to be used in situations where a
   rudimentary channel with poor or absent security or reliability is
   used, adds an encryption and Forward Error Correction (FEC) layer to
   LGSP communications.  This mode is also used to support
   authentication, via a standard certificate system.

   LGSP's unprotected mode, on the other hand, is designed to operate
   over channels that already possess sufficiently high-grade security
   and robustness.  In unprotected mode, LGSP messages are passed in
   cleartext.  Unprotected mode avoids the extra overhead of protected
   mode when such protection is not necessary.

   To aid development of new system protocols for LGSP, an extension
   mode is offered, which allows developing system protocols to be
   rapidly integrated into LGSP during development Section 3.5.  Upon
   completion of development on such new system protocols, it is
   intended that a final top-level system protocol identifier is to be
   allocated, administered by the Internet Assigned Numbers Authority
   (IANA).

   LGSP defines a hierarchical architecture of LGSP Master Station Nodes
   and LGSP Mirror Nodes.  This provides a high degree of robustness to
   the network architecture.  To support this capability, a series of
   messages are defined to provide mirroring functionality between
   Mirror Nodes and Master Station Nodes (Section 3.6).

   This mirroring functionality also supports a redundant backup server
   architecture (Section 3.7).  This allows one or more backup servers
   to monitor a primary server, and maintain synchronisation.  After
   detecting the failure of the primary server, a predefined order



Tyson & Kopp              Expires June 21, 2008                [Page 13]

Internet-Draft                    LGSP                     December 2007


   dictates which backup server takes over from the offline primary
   server.

   LGSP defines a status reporting facility, for administrative and load
   balancing purposes (Section 3.8).  This reports the level of load on
   the LGSP server, along with other per-system protocol metrics, such
   as reliability and age of data.

   Load balancing functionality is also provided: All connecting LGSP
   clients maintain a list of LGSP servers (Section 3.9).  Upon
   connection, the LGSP client selects a server at random, then queries
   the server for its status.  If the returned status information
   reports that server load is too high, the LGSP client moves on to the
   next server in its internal list.

2.3.  GNSS Message Overview

   LGSP provides support for most common GNSS message formats, including
   GPS, GLONASS and Galileo, and several Differential GPS systems.  It
   also contains provisions for future additions.

   When supporting an existing GNSS message format, the GNSS message
   data structure is preserved, encapsulating GNSS messages unchanged
   within LGSP messages.  This allows the received messages at the LGSP
   client to be de-encapsulated and passed to a compatible device or
   software module without requiring significant changes to the device.

   There are two modes of operation for interfaces; unicast request/
   response, and streaming (Section 3.1).  Unicast request/response
   interfaces involve a single response from the LGSP server following a
   request from a client.  Streaming interfaces involve a client request
   to begin receiving continually streamed data, until no more clients
   are connected to the stream.

   LGSP message formats (Section 3.2) provide for a large number of
   modes (up to 255, plus one reserved utility mode), each of which can
   contain up to 256 message types.  This allows LGSP to support any
   existing GNSS system, with provisions for later expansion.

   The system protocols for the systems described in this section all
   use the generic GNSS request/response message format defined in
   Section 3.2.5, Section 3.2.6, or for streaming mode messages, the
   join stream request defined in Section 3.2.3, Section 3.2.4.

   Currently supported GNSS systems are defined below.

   In the tables below, the 'ID' column describes the 'Request Type'
   identifier of the message, while the 'Mode' column defines whether



Tyson & Kopp              Expires June 21, 2008                [Page 14]

Internet-Draft                    LGSP                     December 2007


   the given message is request/response (R/R) or a stream (S).

2.3.1.  GPS Family Messaging

   GPS messages are represented by the System ID constant SID_GPS.

                               GPS Messages

   +----------------------------+----+---------------+----------+------+
   | Message                    | ID | Payload Size  | Update   | Mode |
   |                            |    | (bits)        | Rate     |      |
   +----------------------------+----+---------------+----------+------+
   | NAV message subframe       | 1  | 300           | Minutes  | R/R  |
   |                            |    |               |          |      |
   | NAV message frame          | 2  | 1500          | Minutes  | R/R  |
   |                            |    |               |          |      |
   | NAV message stream         | 3  | 300           | Minutes  | S    |
   |                            |    |               |          |      |
   | CNAV message subframe      | 4  | 300           | Minutes  | R/R  |
   |                            |    |               |          |      |
   | CNAV message frame         | 5  | 1500          | Minutes  | R/R  |
   |                            |    |               |          |      |
   | CNAV message stream        | 6  | 300           | Minutes  | S    |
   |                            |    |               |          |      |
   | CNAV-2 message subframe    | 7  | 300           | Minutes  | R/R  |
   |                            |    |               |          |      |
   | CNAV-2 message frame       | 8  | 900           | Minutes  | R/R  |
   |                            |    |               |          |      |
   | CNAV-2 message stream      | 9  | 300           | Minutes  | S    |
   |                            |    |               |          |      |
   | Enhanced differential      | 10 | Variable      | Minutes  | R/R  |
   | correction message         |    |               |          |      |
   |                            |    |               |          |      |
   | Enhanced differential      | 11 | Variable      | Minutes  | S    |
   | correction stream          |    |               |          |      |
   |                            |    |               |          |      |
   | Almanac page               | 12 | 300           | < 6 days | R/R  |
   |                            |    |               |          |      |
   | Expansion mode             | 13 | Variable      | Variable | R/R  |
   +----------------------------+----+---------------+----------+------+

   Wide Area Augmentation System (WAAS) messages are represented by the
   System ID constant SID_WAAS.








Tyson & Kopp              Expires June 21, 2008                [Page 15]

Internet-Draft                    LGSP                     December 2007


               Wide Area Augmentation System (WAAS) Messages

   +--------------------+----+--------------------+-------------+------+
   | Message            | ID | Payload Size       | Update Rate | Mode |
   |                    |    | (bits)             |             |      |
   +--------------------+----+--------------------+-------------+------+
   | MOPS Message       | 1  | 250                | Seconds     | S    |
   | stream             |    |                    |             |      |
   |                    |    |                    |             |      |
   | MOPS Message block | 2  | 250 x N            | Seconds     | R/R  |
   +--------------------+----+--------------------+-------------+------+

   Local Area Augmentation System (LAAS) messages are represented by the
   System ID constant SID_LAAS.

        Local Area Augmentation System (LAAS)/RTCM SC-104 Messages

   +--------------------+----+--------------------+-------------+------+
   | Message            | ID | Payload Size       | Update Rate | Mode |
   |                    |    | (bits)             |             |      |
   +--------------------+----+--------------------+-------------+------+
   | RTCM Message       | 1  | 990                | Seconds     | S    |
   | stream             |    |                    |             |      |
   |                    |    |                    |             |      |
   | RTCM Message block | 2  | 990 x N            | Seconds     | R/R  |
   +--------------------+----+--------------------+-------------+------+

   GPS Special Applications messages are represented by the System ID
   constant SID_GPS_SA

                     GPS Special Applications Messages

   +--------------------+----+--------------------+-------------+------+
   | Message            | ID | Payload Size       | Update Rate | Mode |
   |                    |    | (bits)             |             |      |
   +--------------------+----+--------------------+-------------+------+
   | Pending definition |    |                    |             |      |
   +--------------------+----+--------------------+-------------+------+

2.3.2.  Galileo Family Messaging

   Galileo messages are represented by the System ID constant
   SID_GALILEO.








Tyson & Kopp              Expires June 21, 2008                [Page 16]

Internet-Draft                    LGSP                     December 2007


                             Galileo Messages

   +---------------------+----+--------------------+------------+------+
   | Message             | ID | Payload Size       | Update     | Mode |
   |                     |    | (bits)             | Rate       |      |
   +---------------------+----+--------------------+------------+------+
   | F/NAV message       | 1  | 2500               | Minutes    | R/R  |
   | subframe            |    |                    |            |      |
   |                     |    |                    |            |      |
   | F/NAV message frame | 2  | 30000              | Minutes    | R/R  |
   |                     |    |                    |            |      |
   | F/NAV message       | 3  | 2500               | Minutes    | S    |
   | stream              |    |                    |            |      |
   |                     |    |                    |            |      |
   | I/NAV message       | 4  | 7440               | Minutes    | R/R  |
   | subframe            |    |                    |            |      |
   |                     |    |                    |            |      |
   | I/NAV message frame | 5  | 178560             | Minutes    | R/R  |
   |                     |    |                    |            |      |
   | I/NAV message       | 6  | 7440               | Minutes    | S    |
   | stream              |    |                    |            |      |
   |                     |    |                    |            |      |
   | Almanac page        | 7  | 250                | Minutes    | R/R  |
   +---------------------+----+--------------------+------------+------+

   EGNOS messages are represented by the System ID constant SID_EGNOS.

                              EGNOS Messages

   +--------------------+----+--------------------+-------------+------+
   | Message            | ID | Payload Size       | Update Rate | Mode |
   |                    |    | (bits)             |             |      |
   +--------------------+----+--------------------+-------------+------+
   | MOPS Message       | 1  | 250                | Seconds     | S    |
   | stream             |    |                    |             |      |
   |                    |    |                    |             |      |
   | MOPS Message block | 2  | 250 x N            | Seconds     | R/R  |
   +--------------------+----+--------------------+-------------+------+

2.3.3.  GLONASS Family Messaging

   GLONASS messages are represented by the System ID constant
   SID_GLONASS.








Tyson & Kopp              Expires June 21, 2008                [Page 17]

Internet-Draft                    LGSP                     December 2007


                             GLONASS Messages

   +------------------------+----+------------------+-----------+------+
   | Message                | ID | Payload Size     | Update    | Mode |
   |                        |    | (bits)           | Rate      |      |
   +------------------------+----+------------------+-----------+------+
   | Navigation message     | 1  | 1275             | Minutes   | R/R  |
   | frame                  |    |                  |           |      |
   |                        |    |                  |           |      |
   | Navigation message     | 2  | 6375             | Minutes   | R/R  |
   | superframe             |    |                  |           |      |
   |                        |    |                  |           |      |
   | Navigation message     | 3  | 1275             | Minutes   | S    |
   | stream                 |    |                  |           |      |
   |                        |    |                  |           |      |
   | Almanac                | 4  | 170              | Days      | R/R  |
   +------------------------+----+------------------+-----------+------+


































Tyson & Kopp              Expires June 21, 2008                [Page 18]

Internet-Draft                    LGSP                     December 2007


3.  Protocol Definition

   This section describes LGSP's operation; in particular, basic message
   types, management messaging formats, channel protection, mirroring
   and backup functions, extension provisions and the expected system
   protocol development path.

   LGSP defines a modular architecture, which is reflected in the
   messaging format.  A series of identifiers in the LGSP message header
   (System ID and Request Type) indicate the contents of the message.

   A number of management messaging formats are defined.  These support
   LGSP features like mirroring and backups, which require regular state
   synchronisation, and load balancing, which requires a query for load
   on the target LGSP server.  These messages are all identified by the
   LGSP System ID constant SID_LGSP.

   When LGSP is used over channels that provide weak or absent
   encryption, a 'protected mode' is provided, that uses encryption and
   Forward Error Correction (FEC).  The FEC layer gives LGSP some
   resilience to channel errors, and thus allows LGSP to utilise more of
   the available bandwidth when running over rudimentary channels.

3.1.  Messaging Modes

   LGSP supports both a unicast request/response mode, as well as a
   multicast streaming mode.  These two separate mechanisms are tailored
   to two distinct styles of GNSS-support messages.  The first mode
   supports on-demand messaging, where data is supplied only when it is
   requested.  This is used, for example, with the GPS almanac page
   message format listed in Section 2.3.1.  The second, streaming mode
   supports real-time streaming messages such as WAAS [WAAS].  These
   services continually transmit update information to clients, and thus
   would not suit a unicast request/response delivery method.

3.1.1.  Request/Response

   The unicast request/response mode is a very simple, stateless
   protocol.  Clients send a UDP request message to the server, which
   processes the data and returns a UDP response (Figure 11, Figure 13).
   There is no more persistent state than is necessary for channel
   encryption purposes; this maximises the robustness of the protocol in
   the face of disconnections.

   Refer Section 3.3 for security details.

   The interface to the request/response mode can be defined in the C
   language as:



Tyson & Kopp              Expires June 21, 2008                [Page 19]

Internet-Draft                    LGSP                     December 2007


   struct lgsp_request_t {
       address host;       /* Host to query (optional - will use
                              predefined hosts if not supplied) */
       u8 system_id;       /* ID of system */
       u8 request_type;    /* Type of request */
       char* parameter;    /* Parameter data (dependent on request
                           /*   type and system ID) */
   };

   struct lgsp_response_t {
       u8 system_id;       /* ID of system */
       u8 request_type;    /* Type of request that initiated response */
       u8 response_code;   /* Identifier for response */
       char* data;         /* Data (dependent on system id) */
   };

   /**
    * Perform LGSP request
    *
    *    Performs query on host, and returns response.
    *
    * @param request Appropriately filled request structure
    * @param response Pointer to placeholder for response data - will
    *         be allocated by procedure
    * @return LGSP response code if error, or copy of response_code
    *         from response structure
    */
   int lgsp_request(struct lgsp_request_t* request,
                           struct lgsp_response_t** response);

                     Request/response mode C interface

   An LGSP server's request/response mode operation, for both
   unprotected and protected mode, is illustrated below.  In LGSP's
   unprotected mode (Section 3.3), which provides no additional channel
   protection, all communications are in plaintext.  Thus, the LGSP
   server maintains no state between transactions.  Conversely, in
   LGSP's protected mode, where an encryption layer is used, as well as
   Forward Error Correction (FEC), a handshake procedure must take place
   for each transaction, to establish and maintain a secure
   communications channel.










Tyson & Kopp              Expires June 21, 2008                [Page 20]

Internet-Draft                    LGSP                     December 2007


                                           +----------------+
                                           |   Listening    |<--.
                                           +----------------+   |
           +----------------+                      |            |
           |   Listening    |<--.               Incoming        |
           +----------------+   |               handshake       |
                   |            |                  |            |
                 Client         |        +-------------------+  |
                Request         |        |Handshake procedure|  |
                   |            |        +-------------------+  |
           +----------------+   |                  |            |
           |  Send Response |---'            Client request     |
           +----------------+                      |            |
                                          +----------------+    |
                                          |  Send Response |----'
                                          +----------------+


             Unprotected mode                Protected mode

        Request/Response flowchart (Unprotected and protected mode)

3.1.2.  Streaming

   The streaming mode is more complex than the request/response mode, as
   some state is required.  Through command messages from clients, LGSP
   supports join and part operations on streams (Section 3.2.3,
   Section 3.2.4).

   When a stream is joined by a client for the first time (that is,
   there are no other clients subscribed to the stream), the LGSP server
   begins broadcasting the new stream.  Subsequent joins by other
   clients simply subscribe the new clients to the created stream.
   After no more clients are subscribed to the stream, the broadcast is
   stopped, conserving resources.

   Streaming can be implemented as multicast, in order to efficiently
   distribute data to multiple recipients simultaneously.
   Alternatively, this can be implemented as parallel unicast sessions,
   or using a hybrid technique, which may be more achievable, given the
   underdeveloped state of multicast support [IP-Multicast].

   Refer Section 3.3.2 for security details.

   The interface to the streaming mode can be defined in C as:

struct lgsp_request_t {
    address host;       /* Host to query (optional - will use predefined



Tyson & Kopp              Expires June 21, 2008                [Page 21]

Internet-Draft                    LGSP                     December 2007


                              hosts if not supplied) */
    u8 system_id;       /* ID of system */
    u8 request_type;    /* Type of request */
    char* parameter;    /* Parameter data (dependent on request type and
                              system ID) */
};

struct lgsp_response_t {
    u8 system_id;       /* ID of system */
    u8 request_type;    /* Type of request that initiated response */
    u8 response_code;   /* Identifier for response */
    char* data;         /* Data (dependent on system id) */
};

struct lgsp_stream_t;

/**
 * Perform LGSP stream join
 *
 *    Performs query on host, and returns response.
 *
 * @param request Appropriately filled request structure
 * @param stream Pointer to placeholder for stream identifier
 * @return LGSP response code
 */
int lgsp_join_stream(struct lgsp_request_t* request,
                        struct lgsp_stream_t* stream);

/**
 * Read latest data from stream
 *
 *    Reads latest data from given stream into given response structure.
 *    Reads a single unit of data, and removes from front of queue.
 *
 * @param stream Stream identifier
 * @param response Pointer to placeholder for response data - will be
 *          allocated by procedure
 * @return LGSP response code
 */
int lgsp_read_stream(struct lgsp_stream_t* stream,
                        struct lgsp_response_t** response);

/**
 * Part stream
 *
 *    Leaves stream, and closes associated internal structures
 *
 * @param stream Stream identifier



Tyson & Kopp              Expires June 21, 2008                [Page 22]

Internet-Draft                    LGSP                     December 2007


 * @return LGSP response code
 */
int lgsp_part_stream(struct lgsp_stream_t* stream);

                        Streaming mode C interface

   LGSP begins broadcasting a stream on request from a client, until no
   more clients are receiving the stream.  That is, the LGSP server
   continues streaming until no encryption key requests are received
   before a 'client request timeout' occurs.  This must be longer than
   the encryption key refresh timeout (refer Section 3.3.2 for details
   related to encryption of streams).

   This is outlined below:





































Tyson & Kopp              Expires June 21, 2008                [Page 23]

Internet-Draft                    LGSP                     December 2007


                           +-----------+
                           | Listening |<------------------------+
                           +-----------+                         |
                                 |                               |
                               Client  (+ DTLS handshake         |
                              Request   in protected mode)       |
                                 |                               |
                          +--------------+                       |
                          |   Generate   |                       |
                          |encryption key|                       |
                          +--------------+                       |
                                 |                               |
                         +-----------------+                     |
                         | Obtain multicast|                     |
                         |     address     |                     |
                         +-----------------+                     |
                                 |                               |
                     .------------------------------.            |
                     |                              |            |
             +-----------------+            +-----------------+  |
          .->| Begin streaming |----.       | Send encryption |  |
          |  +-----------------+    |       |key and multicast|--'
          |          |              |       |    address      |
          |    Crypto timeout       |       +-----------------+
          |          |              |
          |   +--------------+  Client request
          |___| Re-generate  |    Timeout
              |encryption key|      |        +---------------+
              +--------------+      '------->| End streaming |
                                             +---------------+

                       Figure 9: Streaming flowchart

3.2.  Basic Message Formats

   A number of basic message formats are defined, which form the basis
   of all LGSP communication.  These provide standard headers, which
   both provide unique identification of a communication session, and
   identify the message payload.

   In addition, a number of other message formats are defined, which
   provided more specific functionality.  A basic join stream request/
   response pair is defined which can be used by system protocols as-is.
   Similarly, a basic GNSS request/response pair is provided for use by
   system protocols that do not need any other special parameters for a
   transaction.

   These messaging formats can be represented in an inheritance



Tyson & Kopp              Expires June 21, 2008                [Page 24]

Internet-Draft                    LGSP                     December 2007


   hierarchy thus:

                             +------------------+
                             |      Basic       |
                             | Request/Response |
                             +------------------+
                                      |
               +----------------------+----------------------+
               |                      |                      |
               v                      v                      v
     +------------------+   +------------------+
     |       GNSS       |   |   Join Stream    |      System protocol-
     | Request/Response |   | Request/Response |          specific
     +------------------+   +------------------+          messages
               |                      |
               v                      v
       System protocol-        System protocol-
        specific GNSS           specific join
           formats                 messages

           Figure 10: Basic message format inheritance heirachy

   As represented in the above figure, the defined basic formats provide
   a basis for the definition of other messages.

   These basic messages are defined in the following sections.

3.2.1.  Request Message

   The basic LGSP request message, forming the basis for all LGSP
   communication, is illustrated below, excluding any TLS, FEC or UDP
   encapsulation:

        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |  System ID  | Request Type  |              .
        +------------+-------------+---------------+              .
        .                   Parameter data                        .
        +---------------------------------------------------------+

                        Figure 11: Request message

   The structure can be represented in C as:








Tyson & Kopp              Expires June 21, 2008                [Page 25]

Internet-Draft                    LGSP                     December 2007


                   struct lgsp_request_hdr {
                       u8             request_id;
                       u8             system_id;
                       u8             request_type;
                   };  /* System-specific data follows */

                Figure 12: C structure for request message

   The fields within this structure are defined as follows:

   request_id  Request messages are uniquely defined by this 8-bit
      monotonically increasing integer; combined with the source address
      from the UDP header field, this tuple provides a global identifier
      for any request message, valid for a limited time.

   system_id  All encapsulated system protocols are defined by an 8-bit
      unsigned integer, giving a maximum of 255 system protocols,
      excluding one value for 'extended' mode (refer below and
      Section 3.5).  This identifier, combined with the following one,
      specifies how the following data is to be interpreted.

   request_type  This 8-bit unsigned integer identifies the system
      protocol-specific request being made.  As mentioned above, the
      <system_id,request_type> tuple defines the structure of the
      following message data.

3.2.2.  Response Message

   The structure of the basic LGSP response message is illustrated
   below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   System ID   | Response Code|
        +------------+-------------+---------------+--------------+
        .                                                         .
        .                        Data                             .
        +---------------------------------------------------------+

                        Figure 13: Response message

   The response message format can be represented in C as:









Tyson & Kopp              Expires June 21, 2008                [Page 26]

Internet-Draft                    LGSP                     December 2007


                   struct lgsp_response_hdr {
                       u8             response_id;
                       u8             request_id;
                       u8             system_id;
                       u8             response_code;
                   };  /* System-specific data follows */

                Figure 14: C structure for response message

   The fields within are defined as follows:

   response_id  This is a monotonically increasing 8-bit unsigned
      integer, used to identify LGSP response messages within the
      context of each session.  When coupled with the destination
      address from the UDP header, this tuple forms a global unique
      identifier, valid for a limited time.

   request_id  An 8-bit unsigned integer which identifies the
      corresponding original request from the client.  This field is
      primarily for the use of the client system, so responses can be
      associated with requests.

   system_id  Like the similarly-named field in the request message
      structure, this 8-bit unsigned integer identifies the GNSS support
      system protocol encapsulated within the message.

   response_code  An 8-bit unsigned integer that gives an indication of
      the result of a request.  This is a largely system protocol-
      specific value, except for the values 0-10, which are reserved by
      LGSP for more basic result identifies, such as failed
      authentication or server offline notification.  Refer Section 5
      for a definitive list of these reserved codes.

3.2.3.  Join Stream Request Message

   LGSP clients can request to join a stream originating from the
   requested server (Section 3.1.2).  This technique minimises network
   and processor resources by using multicast technologies to distribute
   data to all listening nodes, thereby bypassing the need for both
   repeated 'polling' and separate network connections for each
   listening node.

   This message is standardised for all messaging formats that use
   streaming, unless extended parameters are required.

   The join stream request is defined below.





Tyson & Kopp              Expires June 21, 2008                [Page 27]

Internet-Draft                    LGSP                     December 2007


        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |  System ID  | Request Type  |Param (option)|
        +------------+-------------+---------------+--------------+

                        Join stream request message

   This includes an 8-bit optional parameter field.

   Note that this basic message type has no global identifier - it is up
   to system protocols to define which request types correspond to a
   stream format.

3.2.4.  Join Stream Response Message

   After receiving a join stream request, the following message will be
   returned to the requesting node:

        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   System ID   |      1       |
        +------------+-------------+---------------+--------------+
        |                 Multicast Address                       |
        +---------------------------------------------------------+
        |Crypto type |   DK len    |                              :
        +------------+-------------+       Decode Key data        :
        |                                                         :
        +---------------------------------------------------------+

                       Join stream response message

   This response provides the requester with a multicast address to
   listen to, and a key to decode the data from the multicast stream.
   The response can be represented in C as:

             /* Standard lgsp_response_hdr precedes */
             struct lgsp_join_stream_response {
                 ip_addr_t      multicast_address;
                 u8             crypto_type;
                 u8             decode_key_length;
             };
             /* decode_key_length bytes of decode key follow */

          Figure 17: C structure for join stream response message

   The fields within are defined as follows:





Tyson & Kopp              Expires June 21, 2008                [Page 28]

Internet-Draft                    LGSP                     December 2007


   multicast_address  A multicast address which the stream is broadcast
      to.

   crypto_type  Type of encryption used

   decode_key_length  The length of the decode key

   (decode key)  The key used to decode the data from the stream

   Periodically, the broadcasting server must generate a new decode key.
   When listening nodes are no longer able to use the existing key to
   decode the stream, they must initiate a new join stream request,
   which will allow listening nodes to obtain the new key.

3.2.5.  GNSS Request Message

   A generic message format for GNSS requests is defined below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |  System ID  | Request Type  |  Timestamp...|
        +------------+-------------+---------------+--------------+
        |              ...Timestamp                |  SV Number   |
        +------------+--------------------------------------------+

                           GNSS request message

   The GNSS request message format can be represented in C as:

                 /* Standard lgsp_response_hdr precedes */
                 struct lgsp_gnss_request {
                     uint_32    timestamp;
                     u8         sv_number;
                 };

                   C structure for GNSS request message

   The fields within are defined as follows:

   timestamp  A 32 bit UNIX-style timestamp, representing the number of
      seconds since the epoch (January 1, 1970).  This is optional, and
      should be ignored when it does not apply to the request.

   sv_number  An 8-bit unsigned integer which identifies the satellite
      vehicle involved in the request.  This is optional, and should be
      ignored when it does not apply to the request.

   Note that this basic message type has no global identifier - it is up



Tyson & Kopp              Expires June 21, 2008                [Page 29]

Internet-Draft                    LGSP                     December 2007


   to system protocols to define which request types correspond to a
   GNSS format.

3.2.6.  GNSS Response Message

   A generic response message format for carrying GNSS data is defined
   below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   System ID   | Response Code|
        +------------+-------------+---------------+--------------+
        |                      Timestamp                          |
        +------------+--------------------------------------------+
        | SV Number  |                                            :
        +------------+                                            :
        :                        Data                             :
        +---------------------------------------------------------+

                           GNSS response message

   The response message format can be represented in C as:

                 /* Standard lgsp_response_hdr precedes */
                 struct lgsp_gnss_response {
                     uint32         timestamp;
                     u8             sv_number;
                 };  /* Data follows */

                     C structure for response message

   The fields within are defined as follows:

   timestamp  A 32 bit UNIX-style timestamp, representing the number of
      seconds since the epoch (January 1, 1970).

   sv_number  An 8-bit unsigned integer which identifies the satellite
      vehicle involved in the request.  This is optional, and should be
      ignored when it does not apply to the request.

3.3.  Robustness and Cryptographic Security

   LGSP can be used with a large variety of channel types.  Some
   channels, such as JTRS and JTIDS offer strong encryption, and
   corresponding guarantees of packet integrity.  Conversely, channels
   such as GSM/GPRS, or simpler 'bent pipe' channels using an RF modem
   offer no such integrity guarantees and weak or absent channel
   encryption.



Tyson & Kopp              Expires June 21, 2008                [Page 30]

Internet-Draft                    LGSP                     December 2007


   For the sake of data integrity and confidentiality, it is thus
   essential that measures for channel protection exist within LGSP.

   When LGSP is used over channels that provide weak or absent
   encryption and/or poor reliability, a 'protected mode' is provided,
   that uses encryption and Forward Error Correction (FEC).  The FEC
   layer gives LGSP some resilience to channel errors, and thus allows
   LGSP to utilise more of the available bandwidth when running over
   rudimentary channels.

   Where suitable channel encryption is already in place, as when LGSP
   is used over a protected military channel, for example, LGSP can be
   run in 'unprotected mode', where no encryption or FEC is used within
   LGSP.  As the channel is already encrypted, there is no need for an
   extra layer of encryption.  Similarly, as the nature of an encrypted
   channel provides the assurance of data integrity, FEC is also not
   required.  This conserves processing and bandwidth resources.

   LGSP's protected mode operates on a different port number to LGSP's
   unprotected mode.  This scheme allows a simple and low-overhead
   selection mechanism, akin to the differentiation between clear-text
   HTTP and secured HTTPS port numbers [RFC2818].

3.3.1.  Protection For Request/Response Sessions

   For request/response messages (Section 3.1.1), encryption and
   authentication for LGSP's protected mode is to be provided by
   Datagram Transport Layer Security (D-TLS) [RFC4347].  This is an
   extension to TLS 1.1 [RFC4346] that permits operation over the
   connectionless User Datagram Protocol (UDP) [RFC0768].

   The D-TLS handshake occurs when a new connection is initiated by a
   client, and the D-TLS session is maintained until either a D-TLS
   'close_notify' message exchange occurs, or a session timeout is
   reached.

   TLS-supported certificates are used to authenticate clients.  Initial
   exchange and registration of certificates is outside the scope of
   this document.

   The D-TLS layer is encapsulated by a Forward Error Correction code.
   The diversity of channel types over which LGSP can operate results in
   wide variations in the available channel bandwidth, channel error
   rates and other factors.  Thus, it is not practical to specify a
   single FEC scheme to suit all purposes.

   Ideally, all channels over which LGSP is operated would have a
   suitable FEC layer built-in at the data link level, but this is



Tyson & Kopp              Expires June 21, 2008                [Page 31]

Internet-Draft                    LGSP                     December 2007


   regrettably not yet the case.  Thus, LGSP must offer FEC in place of
   a code provided by the channel.

   As the performance of FEC codes is often strongly dependent on the
   error properties of the channel and block sizes employed, there is no
   good 'universal' or 'one size fits all' choice available for an FEC
   codec.  LGSP therefore mandates only the use of an RFC3452-compatible
   code.  This defines a standardised and generalised scheme for FEC
   coding [RFC3452].

              +--------------------+
              |        LGSP        |
              +--------------------+
              |       D-TLS        |
              +--------------------+   +--------------------+
              |        FEC         |   |        LGSP        |
              +--------------------+   +--------------------+
              |        UDP         |   |        UDP         |
              +--------------------+   +--------------------+
              |         IP         |   |         IP         |
              +--------------------+   +--------------------+
              |  Insecure/Fragile  |   |   Secure/Robust    |
              |      channel       |   |      channel       |
              +--------------------+   +--------------------+

        Figure 22: LGSP Protocol Stacks - Protected and Unprotected

   Note that the D-TLS protection operates only for request/response
   mode messages, which take place between a single client and an LGSP
   server.  As the nature of the encryption system used does not provide
   multi-party encryption, it is not compatible with the multicast
   streaming mode.  An exception to this is when the streaming mode is
   implemented as a series of unicast sessions.

3.3.2.  Protection for Stream Sessions

   This section only applies to LGSP's streaming mode if it is
   implemented as a multicast stream.  If streaming is implemented as
   parallel unicast sessions, then these are protected by the standard
   request/response protection mechanisms (Section 3.3.1).

   All multicast streaming sessions that are initialised (Section 3.1.2)
   in protected mode are protected by encryption and Forward Error
   Correction.  Due to the nature of D-TLS (refer Section 3.3.1), it is
   not possible to support multicast sessions with this mechanism.

   Instead, the multicast stream is secured by a secure multicast
   architecture described in [RFC3740].  Each protected multicast stream



Tyson & Kopp              Expires June 21, 2008                [Page 32]

Internet-Draft                    LGSP                     December 2007


   is encrypted with a key that is distributed to all listening clients
   on request (Figure 9).  This key is re-generated at pseudo-random
   intervals, requiring clients to re-request the shared key.

   In the terms defined by [RFC3740], the LGSP server plays the part of
   the Policy Server, the Group Controller/Key Server and the Sender.
   That is, the LGSP server is responsible for dictating access
   restrictions to streams, managing authentication and joining/parting
   of clients and generation of cryptographic keys.

   This architecture gives the LGSP server a high degree of control over
   the multicast stream, allowing the server to grant and revoke
   multicast stream access to any individual client at any time during
   transmission.

   Forward Error Correction (FEC) for multicast streams is as defined
   for request/response messages - refer Section 3.3.1 for more
   information.

3.4.  Authentication for Access Control

   Authentication in LGSP is provided by the D-TLS layer of LGSP's
   protected mode (refer Section 3.3.1), which offers digital
   certificate functionality.

   Certificates are exchanged out-of-band; certificate generation and
   exchange is beyond the scope of this document.

   Certificate-based authentication is performed as part of the D-TLS
   session initialisation routine.  An LGSP server uses the
   identification from the certificate to grant access to protected
   resources.

   Refer Section 3.3 for more information on LGSP's protected mode.

3.5.  Extension Provisions

   As the use of GNSS systems becomes more widespread, the demand for
   more accurate, more robust and more consistent service increases.
   Consequently, LGSP contains provisions for future expansion.
   Examples of such growth could be additional differential correction
   messaging schemes.

   In order to support rapid deployment of new technologies, an
   extension mode is offered, which allows new system protocols to be
   quickly built into LGSP, before a formal definition has matured.
   This also provides for prototyping and demonstrator platform
   development.



Tyson & Kopp              Expires June 21, 2008                [Page 33]

Internet-Draft                    LGSP                     December 2007


   The LGSP extension mode consists of two pre-defined variable size
   message formats.  The extension message header contains fields to
   identify the system and message type, and fields to support both
   variable size messages, and message fragmentation.

   Request/response and stream variants of the extension message are
   supported:

                            Extension Messages

         +-------------------+--------------+-------------+------+
         | Message           | Payload Size | Update Rate | Mode |
         +-------------------+--------------+-------------+------+
         | Extension Message | Variable     | Variable    | R/R  |
         |                   |              |             |      |
         | Extension Message | Variable     | Variable    | S    |
         +-------------------+--------------+-------------+------+

   Extension messages are identified by a System ID identifier of
   SID_EXTEND, as well as a Temporary System ID (TSID) identifier, used
   in place of the standard Request Type field.  Allocation of TSID
   values are to be performed by a central authority.  It is expected
   this will be performed in a similar fashion to IP port number
   allocation, which is regulated by the Internet Assigned Numbers
   Authority (IANA) [RFC2780].

   When developing a new LGSP system protocol, it is expected that the
   developer will contact the central LGSP authority to request the
   reservation of a Temporary System ID (TSID).  Such a request would be
   accompanied by a statement of the time span for which the reserved
   TSID is required.  If granted, the reserved TSID is available for use
   by the system protocol developer until it expires, after the stated
   time.

   By the time the reserved TSID has expired, it is expected that the
   system protocol would have matured sufficiently to be formally
   incorporated into LGSP, through a standard submission process which
   would be managed by an LGSP standards authority.  If the system
   protocol is not accepted as a new standard, discretion is given to
   the LGSP central authority to grant an extension on the TSID, or
   allow the reservation to expire.

   After being accepted, the new system protocol would be allocated a
   top-level System ID value.







Tyson & Kopp              Expires June 21, 2008                [Page 34]

Internet-Draft                    LGSP                     December 2007


3.5.1.  Extended Request Message

   The extended request message format is identified by the system
   identifier SID_EXTEND, and is illustrated below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |  SID_EXTEND |  Temp Sys. ID | Param. len...|
        +------------+-------------+---------------+--------------+
        | Param. len |                                            :
        +------------+              Parameter data                :
        :                                                         :
        +---------------------------------------------------------+

                    Figure 23: Extended request message

   This special case of the standard request message is provided for
   evolvability (refer Section 3.5 for more details).  The extended
   request message format contains a constant system_id value,
   SID_EXTEND, which is reserved for systems that are not yet officially
   supported by LGSP, and are thus an unofficial extension.

   The extended request message format can be represented in C as:

      struct lgsp_extended_request_hdr {
          u8             request_id;
          u8             system_id;        /* (= SID_EXTEND) */
          u8             temporary_system_id;
          unsigned int   parameter_length:24;
      };  /* parameter_length bytes of system-specific data follows */

            Figure 24: C structure for extended request message

   The extended request message format uses the temporary_system_id
   field to identify the extended system protocol being used.  In
   addition, a 16-bit parameter_length field is used to specify the
   length of the following data block.

   A 16-bit unsigned value gives a maximum request data length of 64
   kilobytes.  Note that the theoretical maximum size of a UDP packet is
   64 KB, so the maximum length for parameter data, which is
   encapsulated within a UDP packet with several layers of headers and
   control information, will be somewhat less than 64 KB in practice.

3.5.2.  Extended Response Message

   The LGSP extended response message format is illustrated below:




Tyson & Kopp              Expires June 21, 2008                [Page 35]

Internet-Draft                    LGSP                     December 2007


        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   SID_EXTEND  | Response Code|
        +------------+------+------+---------------+--------------+
        |Temp Prot ID|  SC  | SID  |         Data Length          |
        +------------+------+------+------------------------------+
        .                                                         .
        .                        Data                             .
        +---------------------------------------------------------+

                   Figure 25: Extended response message

   As with the extended request message, this is a special case provided
   for evolvability.  As above, this format is designated by the special
   system_id value, SID_EXTEND.

   This message format can be represented in C as:

          struct lgsp_extended_response {
              u8             response_id;
              u8             request_id;
              u8             system_id;        /* = SID_EXTEND */
              u8             response_code;
              u8             temporary_system_id;
              unsigned int   segment_count:4;
              unsigned int   segment_id:4;
              unsigned int   data_length:16;
          };  /* System-specific data follows */

           Figure 26: C structure for extended response message

   These additional fields are described below.

   segment_count  Identifies the total number of extra segments
      (packets) this response comprises.  This value does not include
      the first segment; thus, responses of only one segment have a
      segment_count value of 0.  This unsigned 4-bit value allows
      extended system protocols to issue long responses with up to 16
      segments.

   segment_id  Identifies the current segment.  This unsigned 4-bit
      integer is used with the above segment_count value to allow
      extended system protocols to send large messages.  The first
      segment of a long response has an ID of 0.







Tyson & Kopp              Expires June 21, 2008                [Page 36]

Internet-Draft                    LGSP                     December 2007


   data_length  An unsigned 16-bit integer that gives the size of the
      system-specific data in the message.  As with the extended request
      format, this value allows for up to 64 kilobytes of data, although
      this is limited in practice by the UDP packet format.  When
      combined with the segment provisions above, responses of almost 1
      MB can be sent.

3.6.  Mirroring

   LGSP provides functionality to synchronise data from one LGSP server
   to another.  This supports both LGSP Mirror Node operation, as well
   as redundant backup server operation.

   Three complementary messaging formats exist for maintaining
   synchronisation.  The first is a unicast request/response mechanism
   for obtaining an entire dump of current state information for
   selected system protocols.  The second is another unicast request/
   response format which provides for the transfer of all changes in
   state for selected system protocols since a given time.  The third
   involves a streaming multicast-style transmission that the
   destination node subscribes to, to receive changes to data at the
   source node as they occur.

                            Mirroring Messages

     +--------------------------+--------------+-------------+------+
     | Message                  | Payload Size | Update Rate | Mode |
     +--------------------------+--------------+-------------+------+
     | Full synchronise         | Variable     | Variable    | R/R  |
     |                          |              |             |      |
     | Differential synchronise | Variable     | Variable    | R/R  |
     |                          |              |             |      |
     | Synchronisation stream   | Variable     | Variable    | S    |
     +--------------------------+--------------+-------------+------+

   The first, full synchronisation operation begins with the
   transmission of a synchronisation request by the initiating LGSP
   node.  The request indicates the systems for which data is to be
   synchronised; this is a list of system IDs (as presented in
   Section 2.3 and Section 3.5), or a special flag that identifies all
   available systems.

   Upon receiving the request, the remote LGSP server packages the
   entire state of the requested system protocols into a special message
   (or multiple messages if the data does not fit in a single message)
   and transmits the reply back to the initiating LGSP node.

   The second, differential synchronisation operation begins with a



Tyson & Kopp              Expires June 21, 2008                [Page 37]

Internet-Draft                    LGSP                     December 2007


   request that contains a list of system IDs, or a flag to identify all
   available system protocols, as above, as well as a timestamp field.
   The timestamp field indicates that all changes after the specified
   time are to be returned.  All synchronisation responses from the
   remote LGSP server are accompanied by a timestamp; this field is
   typically used in subsequent differential synchronisation requests,
   in order to obtain all changes since the last synchronisation
   operation.

   The full synchronisation operation is useful when performing an
   initial synchronisation, or when some time has passed since the last
   synchronisation.  The differential synchronisation operation
   conserves bandwidth, avoiding the need to send all state for each
   update.  This allows more rapid updates with less demand upon
   resources.

   The third synchronisation method involves the initiating LGSP node
   joining a stream initiating from the remote node.  This request from
   the initiating node includes a list of system IDs, as with the
   previous two operations.  A handshake procedure follows, during which
   the local LGSP node is subscribed to the multicast update stream.

   The remote LGSP node selects for transmission the union of the
   previous set of system protocols and the set of system protocols
   identified by the requesting LGSP node.  This ensures that the update
   stream contains all the requested system protocol update data for all
   subscribers.  Subscribers receiving updates for system protocols that
   were not requested are expected to simply discard the irrelevant
   updates.

   Note that in the case of connection failure during streaming, missed
   synchronisation data can be retrieved by recipients by a unicast
   differential synchronisation request to the originating LGSP server.

   A multicast synchronisation stream mechanism allows immediate
   distribution of updates in a bandwidth-efficient fashion.

3.6.1.  Full Sync Request Message

   To support both mirroring and redundant backup servers, a number of
   synchronisation messages are defined.  The full sync exchange results
   in an entire dump of the requested server's state being transferred
   to the requesting node.  The full sync request is identified by the
   System ID SID_LGSP, and the Request Type RT_LGSP_FULL_SYNC, and is
   defined below.






Tyson & Kopp              Expires June 21, 2008                [Page 38]

Internet-Draft                    LGSP                     December 2007


        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |   SID_LGSP  |..GSP_FULL_SYNC|Num of sources|
        +------------+-------------+---------------+--------------+
        |   SID 1    |    SID 2    |       ...SID 3 .. n ...      |
        +------------+-------------+------------------------------+

                   Figure 27: Full sync request message

   This can be represented in C as:

                 /* Standard lgsp_response_hdr precedes */
                 struct lgsp_full_sync {
                     u8             number_of_sources;
                 };
                 /* number_of_sources u8 SIDs follow */

                 Figure 28: C structure for status message

   The fields within are defined as follows

   number_of_sources  The number of sources for which synchronisation
      should take place.  If 0, then all sources are selected for
      synchronisation.

   pid  The id of the represented source

3.6.2.  Full Sync Response Message

   The full sync response message is illustrated below:





















Tyson & Kopp              Expires June 21, 2008                [Page 39]

Internet-Draft                    LGSP                     December 2007


        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   SID_LGSP    |      1       |
        +------------+-------------+---------------+--------------+
        |Num segments|Segment ID=0 |  Num sources  |   S0 SID     |
        +------------+-------------+---------------+--------------+
        | S0 data len|                                            :
        +------------+                                            :
        :                       S0 data                           :
        +---------------------------------------------------------+
        |   S1 SID   |         S1 data len         |              :
        +------------+-----------------------------+              :
        :                       S1 data                           :
        +---------------------------------------------------------+
        :                   ... S2 ... Sn ...                     :
        +---------------------------------------------------------+

                             Full sync message

   Due to limitations in the UDP packet size, the full sync message may
   have to be broken into multiple segments.  In this case, subsequent
   segments will contain a continuation of the data in the prior
   packets, as below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   SID_LGSP    |      1       |
        +------------+-------------+---------------+--------------+
        |Num segments|Segment ID=1+|                              :
        +------------+-------------+                              :
        |                 ... Continued data ...                  :
        +---------------------------------------------------------+

                  Full sync message (subsequent packets)

   If when parsing a full sync message the end of the packet is reached
   before reaching the end of a data block, then the data block
   continues at the beginning of the next packet.

   That is, if data_length for the current source is n, and only m bytes
   are read before reaching the end of the packet, then the remaining
   n-m bytes of the source's data can be found in the following packet
   or packets.

   The full sync message format can be represented in C as:






Tyson & Kopp              Expires June 21, 2008                [Page 40]

Internet-Draft                    LGSP                     December 2007


         /* Standard lgsp_response_hdr precedes */
         struct lgsp_full_sync_hdr {
             u8             num_segments;
             u8             segment_id;
         };
         struct lgsp_full_sync_first { /* In first packet only */
             u8             number_of_sources;
         };
         /* lgsp_full_sync structs follow */
         struct lgsp_full_sync {
             u8             system_id;
             u16            data_length;
         };
         /* Up to data_length bytes system-specific data
            follows, followed by the next lgsp_full_sync struct */


                      C structure for status message

   The fields within are defined as follows:

   num_segments  Number of segments (packets) the message is broken up
      into.

   segment_id  Number of the current segment [0 .. num_segments-1].

   number_of_sources  A count of all LGSP sources for which data is
      being transferred.  This is only included in the first packet of a
      full sync message (subsequent packets are simply a continuation of
      the first packet)

   system_id  System ID for source N

   data_length  Length of data being transferred for the current source

3.6.3.  Differential Sync Request Message

   LGSP's differential sync exchange results in the transfer of an
   incremental update of the requested server's state since a given
   time, representing the time of last sync.  The differential sync
   request is identified by the System ID SID_LGSP, and the Request Type
   RT_LGSP_DIFF_SYNC, and is defined below.









Tyson & Kopp              Expires June 21, 2008                [Page 41]

Internet-Draft                    LGSP                     December 2007


        0                                                        31
        +------------+-------------+---------------+--------------+
        | Request ID |   SID_LGSP  |..GSP_DIFF_SYNC|Date of last..|
        +------------+-------------+---------------+--------------+
        |... sync                                  | Num sources  |
        +------------+-------------+---------------+--------------|
        |   SID 1    |    SID 2    |       ...SID 3 .. n ...      |
        +------------+-------------+------------------------------+

                     Differential sync request message

   This can be represented in C as:

       /* Standard lgsp_response_hdr precedes */
       struct lgsp_diff_sync {
           uint32_t       last_sync_timestamp; /* Secs since epoch */
           u8             number_of_sources;
       };
       /* number_of_sources u8 SIDs follow */

                      C structure for status message

   The fields within are defined as follows

   last_sync_timestamp  A UNIX timestamp representing the last sync time
      - only changes since this time will be returned.

   number_of_sources  The number of sources for which synchronisation
      should take place.  If 0, then all sources are selected for
      synchronisation.

   pid  The id of the represented source

3.6.4.  Differential Sync Response Message

   Refer Section 3.6.2 - message formats are identical.

3.7.  Backup Servers

   LGSP contains provisions for multiple standby backup servers.  These
   are entirely separate physical servers that maintain synchronisation
   and a `heartbeat' link with the primary LGSP server.  This involves
   periodically querying the LGSP server, to confirm that the server
   remains online.  When no reply is detected from the primary server,
   it is assumed that the primary server is offline, and the backup
   server switches to primary mode, replacing the offline server.  In
   the case of multiple backup servers, a pre-defined order dictates
   which server switches to primary mode.



Tyson & Kopp              Expires June 21, 2008                [Page 42]

Internet-Draft                    LGSP                     December 2007


   A backup server when activated initially performs a full
   synchronisation with the primary LGSP server (Section 3.6.2).  The
   backup server then waits for a small interval of time, typically a
   small number of seconds, then performs a differential synchronisation
   with the primary server (Section 3.6.3).  The backup server repeats
   this wait-synchronise process indefinitely.

   The synchronisation communication doubles as a heartbeat
   notification.  If no response is received from the primary server,
   the backup server switches into primary mode and takes it's place.
   The server then performs the functions of the primary server, until
   it is manually returned to backup mode by direct intervention by an
   administrator.

   In a multiply-redundant environment, with several backup servers, all
   backup servers perform the wait-synchronise process.  Each backup
   server is assigned an ID number, which defines an order.  All backup
   servers possess a list of the address of each backup server with its
   assigned ID number.  When the primary server does not respond, the
   backup servers reconfigure to select the highest-ordered backup
   server as the new primary server.  All other backup servers self-
   configure to begin synchronising with the new primary server.

   This process takes place implicitly and doesn't require an election
   process to take place, as all backup servers already possess the
   ordered list of backup servers.

   Similarly, if the new primary server fails, and does not respond to
   subsequent synchronisation requests, this process is repeated; the
   next backup server in line takes the place of the failed primary
   server, and operation continues.

   This process is illustrated below.


















Tyson & Kopp              Expires June 21, 2008                [Page 43]

Internet-Draft                    LGSP                     December 2007


                           +----------------+
                           |  Backup server |
                           | brought online |
                           +----------------+
                                   |
                           +-----------------+
                           |  Perform full   |
                           | synchronisation | <-----------.
                           +-----------------+             |
                                   |                       |
                              +---------+                  |
                              |  Sleep  | <---------.      |
                              +---------+           |      |
                                   |                |      |
                             Time interval          |      |
                                elapsed             |      |
                                   |                |      |
                        +----------------------+    |      |
                        | Perform differential |____|      |
                        |   synchronisation    | Success   |
                        +----------------------+           |
                                   |                       |
                                Failure                    |
                                   |                       |
                          +----------------+               |
                       .--| Check local ID |--.            |
               Next in |  +----------------+  | Not next   |
                  line |                      | in line    |
                       |                      v            |
               +--------------+       +---------------+    |
               |   Switch to  |       | Set address of|    |
               | primary mode |       |primary to next|----'
               +--------------+       | backup in line|
                                      +---------------+

                          Backup server flowchart

   This redundancy offers a large degree of robustness; even if a
   physical server is destroyed, the backups will begin to function in
   its place almost immediately.  Separating the servers by some
   distance offers further security, from physical destruction, power
   outages, adverse local radio propagation or network link failures,
   depending on the physical configuration of the servers.  As the
   primary and backup servers are connected via an IP communications
   link, some degree of flexibility is offered in terms of location.
   Primary and backup servers could easily be located in separate
   buildings, across a campus, or even in separate campuses.  This
   flexibility is limited only by network administration factors.



Tyson & Kopp              Expires June 21, 2008                [Page 44]

Internet-Draft                    LGSP                     December 2007


3.8.  Status Information

   Certain information is made available by an LGSP server to clients
   and other LGSP nodes through a status query.  The returned status
   block contains:

   o  System load information, including network and CPU load.

   o  Status information of each source:

      *  Reliability measure, also indicating offline/online status at
         either extreme of the scale

      *  Age of data (time since last update)

      *  Optional system-specific status messages

   The status message allows LGSP nodes and clients to determine both
   the load of the LGSP node in question, and the validity of the data
   at the node.  As discussed in Section 2, LGSP nodes and clients will
   query the status of an LGSP node as part of the connection process;
   if the status returned indicates that the remote node is overloaded
   or contains unreliable data, then the connecting node will move on to
   the next known LGSP node.

   In addition, each LGSP message containing system data that an LGSP
   node returns contains header fields that give an indication of the
   validity and age of the accompanying data.  The receiving client then
   decide whether to accept the received data, or attempt to connect to
   another mirror to obtain more recent or reliable data.

3.8.1.  Status Request Message

   For load-distribution and administrative purposes, the status request
   message is used to prompt an LGSP server to return current status
   information.  The status message is identified by the System ID
   SID_LGSP, and the Request Type RT_LGSP_STATUS, and is defined below.

                0                                         24
                +------------+-------------+---------------+
                | Request ID |   SID_LGSP  | RT_LGSP_STATUS|
                +------------+-------------+---------------+

                     Figure 35: Status request message







Tyson & Kopp              Expires June 21, 2008                [Page 45]

Internet-Draft                    LGSP                     December 2007


3.8.2.  Status Response Message

   The LGSP status response message is illustrated below:

        0                                                        31
        +------------+-------------+---------------+--------------+
        |Response ID |  Request ID |   SID_LGSP    |      1       |
        +------------+-------------+---------------+--------------+
        |  CPU load  |Avg. Net load| Num of sources|    S0 SID    |
        +------------+-------------+---------------+--------------+
        |S0 rel'blity|   S0 age    |  Opt. S0 stat |    S1 SID    |
        +------------+-------------+---------------+--------------+
        |S1 rel'blity|   S1 age    |  Opt. S1 stat | ...S1..Sn ...|
        +------------+--------------------------------------------+

                         Figure 36: Status message

   The status message format can be represented in C as:

          /* Standard lgsp_response_hdr precedes */
          struct lgsp_status {
              u8             cpu_load;
              u8             avg_net_load;
              u8             number_of_sources;
          };
          /* number_of_sources lgsp_source_stat structs follow */
          struct lgsp_source_stat {
              u8             system_id;
              u8             reliability;
              u8             age;
              u8             optional_system_stats;
          };


                 Figure 37: C structure for status message

   The fields within are defined as follows:

   cpu_load  Used to give an indication of the amount of load the
      server's processor is under.

   avg_net_load  An average of network load in [0...255] over all
      network interfaces.

   number_of_sources  A count of all LGSP sources.






Tyson & Kopp              Expires June 21, 2008                [Page 46]

Internet-Draft                    LGSP                     December 2007


   system_id  System ID for source N

   reliability  Measure of reliability for source N; a value of 0
      indicates N is offline, a value of 255 indicates N is online and
      fully operational.

   age  Age of data for source N; units are system-specific

   optional_system_stats  Additional 8-bit statistics field for optional
      use by system protocols

3.9.  Load Balancing

   LGSP defines functionality to support load balancing within the
   protocol.  This avoids the situation where a single LGSP server is
   overwhelmed while other LGSP servers remain idle.  By constraining
   LGSP clients' behaviour, load can be evenly spread over a number of
   LGSP mirrors.

   LGSP clients contain a list of LGSP Mirror Nodes to connect to.  When
   initiating a connection, the LGSP client initially chooses a random
   LGSP server from the list.  The LGSP client will request the current
   status of the Mirror Node, using the status information query defined
   in Section 3.8.  The client will evaluate the response, and determine
   the level of load the Mirror Node is under.  If load is high, the
   client will attempt a connection with the next LGSP Mirror Node in
   the client's internal list.

   Similarly, if a connection to an LGSP Mirror Node fails, an LGSP
   client will simply move on to the next LGSP Mirror Node in the
   client's list.

   This same functionality is required of LGSP Mirror Nodes when
   connecting to LGSP Master Station Nodes.  This redundant architecture
   offers considerably more robustness than an architecture with a
   single point-of-failure.

   This process is illustrated below:













Tyson & Kopp              Expires June 21, 2008                [Page 47]

Internet-Draft                    LGSP                     December 2007


                 +------------------+
                 |  Client selects  |
                 |random LGSP server|   +------------------+
                 +------------------+   |  Client selects  |
                          |             | next LGSP server |
                          |             +------------------+
                          |---------------|      ^
                          v                      |
                   +--------------+              |
                   | Client sends |__ No server _|
                   | status query |   response   |
                   +--------------+              |
                          |                      |
                    Server responds              |
                          |                      |
                          v                      |
                    +-----------+                |
                    |  Client   |                |
                    | evaluates |-- Load too ----'
                    | response  |    high
                    +-----------+
                          |
                    Load adequate
                          |
                          v
                 +-----------------+
                 | Client proceeds |
                 |   with request  |
                 +-----------------+

                    Figure 38: Load Balancing Flowchart




















Tyson & Kopp              Expires June 21, 2008                [Page 48]

Internet-Draft                    LGSP                     December 2007


4.  System Protocol Identifiers

   LGSP defines a number of system identifiers for currently supported
   GNSS systems (Section 2.3), and for management and extension use
   (Section 3).  For each system, LGSP also defines a number of request
   identifiers.  Both are listed in this section.

4.1.  System Identifiers

   System identifiers for the supported GNSS systems (Section 2.3) and
   for management and extension use (Section 3) are defined below.

           +-------------+----+--------------------------------+
           | Name        | ID | Description                    |
           +-------------+----+--------------------------------+
           | SID_LGSP    | 0  | LGSP Internal Messages         |
           |             |    |                                |
           | SID_EXTEND  | 1  | Extension Message              |
           |             |    |                                |
           | SID_GPS     | 2  | Global Position System         |
           |             |    |                                |
           | SID_GPS_SA  | 3  | GPS Special Applications       |
           |             |    |                                |
           | SID_WAAS    | 4  | Wide Area Augmentation System  |
           |             |    |                                |
           | SID_LAAS    | 5  | Local Area Augmentation System |
           |             |    |                                |
           | SID_GALILEO | 6  | Galileo                        |
           |             |    |                                |
           | SID_EGNOS   | 7  | EGNOS                          |
           |             |    |                                |
           | SID_GLONASS | 8  | GLONASS                        |
           +-------------+----+--------------------------------+

4.2.  Request Types

   Request types for the existing LGSP systems are defined below.

   The 'Mode' column defines whether the given type is request/response
   or streaming.  Excepting all requests for System ID SID_LGSP, all
   request/response ('R/R') messages use the GNSS request/response
   message format (Section 3.2.5, Section 3.2.6).

   All streaming messages below (S) use the join stream message format,
   with no parameters (Section 3.2.3, Section 3.2.4).






Tyson & Kopp              Expires June 21, 2008                [Page 49]

Internet-Draft                    LGSP                     December 2007


   +------------+------------------------+----+------+-----------------+
   | System     | Name                   | ID | Mode | Description     |
   +------------+------------------------+----+------+-----------------+
   | SID_LGSP   | RT_LGSP_STATUS         | 1  | R/R  | Request status  |
   |            |                        |    |      | from node       |
   |            |                        |    |      |                 |
   | SID_LGSP   | RT_LGSP_FULL_SYNC      | 2  | R/R  | Request all     |
   |            |                        |    |      | stored data and |
   |            |                        |    |      | state           |
   |            |                        |    |      | (mirrors/backup |
   |            |                        |    |      | sonly)          |
   |            |                        |    |      |                 |
   | SID_LGSP   | RT_LGSP_DIFF_SYNC      | 3  | R/R  | Request changes |
   |            |                        |    |      | since last sync |
   |            |                        |    |      | (m/b only)      |
   |            |                        |    |      |                 |
   | SID_LGSP   | RT_LGSP_SYNC_STREAM    | 4  | S    | Request to      |
   |            |                        |    |      | join/part sync  |
   |            |                        |    |      | stream (m/b     |
   |            |                        |    |      | only)           |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_NAV_SUBFRAME    | 1  | R/R  | NAV message     |
   |            |                        |    |      | subframe        |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_NAV_FRAME       | 2  | R/R  | NAV message     |
   |            |                        |    |      | frame           |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_NAV_STREAM      | 3  | S    | NAV message     |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV_SUBFRAME   | 4  | R/R  | CNAV message    |
   |            |                        |    |      | subframe        |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV_FRAME      | 5  | R/R  | CNAV message    |
   |            |                        |    |      | frame           |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV_STREAM     | 6  | S    | CNAV message    |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV2_SUBFRAME  | 7  | R/R  | CNAV-2 message  |
   |            |                        |    |      | subframe        |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV2_FRAME     | 8  | R/R  | CNAV-2 message  |
   |            |                        |    |      | frame           |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_CNAV2_STREAM    | 9  | S    | CNAV-2 message  |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |



Tyson & Kopp              Expires June 21, 2008                [Page 50]

Internet-Draft                    LGSP                     December 2007


   | SID_GPS    | RT_GPS_EDCM            | 10 | R/R  | Enhanced        |
   |            |                        |    |      | differential    |
   |            |                        |    |      | correction      |
   |            |                        |    |      | message         |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_ECDS            | 11 | S    | Enhanced        |
   |            |                        |    |      | differential    |
   |            |                        |    |      | correction      |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_ALMANAC         | 12 | R/R  | Almanac page    |
   |            |                        |    |      |                 |
   | SID_GPS    | RT_GPS_EXPANSION       | 13 | R/R  | GPS expansion   |
   |            |                        |    |      | mode            |
   |            |                        |    |      |                 |
   | SID_WAAS   | RT_WAAS_MOPS_STREAM    | 1  | S    | MOPS message    |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_WAAS   | RT_WAAS_MOPS_BLOCK     | 2  | R/R  | MOPS message    |
   |            |                        |    |      | block           |
   |            |                        |    |      |                 |
   | SID_LAAS   | RT_LAAS_RTCM_STREAM    | 1  | S    | RTCM message    |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_LAAS   | RT_LASS_RTCM_BLOCK     | 2  | R/R  | RTCM message    |
   |            |                        |    |      | block           |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_FNAV_SUBFRA | 1  | R/R  | F/NAV message   |
   | O          | ME                     |    |      | subframe        |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_FNAV_FRAME  | 2  | R/R  | F/NAV message   |
   | O          |                        |    |      | frame           |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_FNAV_STREAM | 3  | S    | F/NAV message   |
   | O          |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_INAV_SUBFRA | 4  | R/R  | I/NAV message   |
   | O          | ME                     |    |      | subframe        |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_INAV_FRAME  | 5  | R/R  | I/NAV message   |
   | O          |                        |    |      | frame           |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_INAV_STREAM | 6  | S    | I/NAV message   |
   | O          |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_GALILE | RT_GALILEO_ALMANAC     | 7  | R/R  | Almanac page    |
   | O          |                        |    |      |                 |
   |            |                        |    |      |                 |



Tyson & Kopp              Expires June 21, 2008                [Page 51]

Internet-Draft                    LGSP                     December 2007


   | SID_EGNOS  | RT_EGNOS_MOPS_STREAM   | 1  | S    | MOPS message    |
   |            |                        |    |      | stream          |
   |            |                        |    |      |                 |
   | SID_EGNOS  | RT_EGNOS_MOPS_BLOCK    | 2  | R/R  | MOPS message    |
   |            |                        |    |      | block           |
   |            |                        |    |      |                 |
   | SID_GLONAS | RT_GLONASS_NAV_FRAME   | 1  | R/R  | Navigation      |
   | S          |                        |    |      | message frame   |
   |            |                        |    |      |                 |
   | SID_GLONAS | RT_GLONASS_NAV_SUPERFR | 2  | R/R  | Navigation      |
   | S          | AME                    |    |      | message         |
   |            |                        |    |      | superframe      |
   |            |                        |    |      |                 |
   | SID_GLONAS | RT_GLONASS_NAV_STREAM  | 3  | S    | Navigation      |
   | S          |                        |    |      | message stream  |
   |            |                        |    |      |                 |
   | SID_GLONAS | RT_GLONASS_ALMANAC     | 4  | R/R  | Almanac         |
   | S          |                        |    |      |                 |
   +------------+------------------------+----+------+-----------------+
































Tyson & Kopp              Expires June 21, 2008                [Page 52]

Internet-Draft                    LGSP                     December 2007


5.  Reserved Response Codes

   Several system-wide response codes have been defined, for use within
   LGSP response messages (Figure 13).  The response codes from 0x0 to
   0xA inclusive are reserved.  These codes identify LGSP-specific
   result conditions and are defined below.

   SUCCESS = 0x0  A general success indicator, used when a request was
      successfully processed.

   FAILURE = 0x1  This is a general error condition that reflects that
      an unknown error occurred when processing the client's request.
      This value should only be used when no other error condition can
      represent the problem.

   ILLEGAL_RESOURCE = 0x2  A general error condition triggered when
      trying to access a resource illegally.

   RESOURCE_OFFLINE = 0x3  A condition caused when the requested
      resource is currently unavailable.  This should be returned when a
      resource is temporarily offline.  If the resource has been
      permanently decommissioned, or has never been available, the
      following code should be returned instead.

   NO_SUCH_RESOURCE = 0x4  This code should be returned when the
      requested resource does not exist.  Note the distinction between
      this condition, which reflects a permanent state, and the previous
      condition, which reflects a temporary unavailability of the
      resource.

   The remainder of the codes, up to and including 0xA, are reserved for
   future expansion and should not be used by any system under LGSP.



















Tyson & Kopp              Expires June 21, 2008                [Page 53]

Internet-Draft                    LGSP                     December 2007


6.  IANA Considerations

   LGSP requires two port allocations, for the protected and unprotected
   modes (refer Section 3.3).

   As defined in Section 3.2, LGSP defines an 8-bit System Identifier
   field, which identifies the LGSP system protocol the message
   concerns.  It is proposed that the IANA will oversee allocation of
   new System Identifiers when new LGSP system protocols are developed.

   In addition, LGSP provides an expansion message format, used for
   developing LGSP system protocols and defined in Section 3.5.  It is
   proposed that the IANA will perform the administrative tasks related
   to allocation of Temporary System IDs for this purpose.

   Following the policies outlined in [RFC2434], System Identifier
   values in the range 9-255 are allocated through IETF Approval;
   numbers between 0-8 are already allocated (Section 4).

   All Temporary System Identifier values are allocated through IETF
   Approval, for the time period stated in the request, but no longer
   than three years.  Renewal of Temporary System Identifier values is
   to be assessed by the IETF, and granted only if reasonable progress
   has been made in development of the new protocol towards a standard.



























Tyson & Kopp              Expires June 21, 2008                [Page 54]

Internet-Draft                    LGSP                     December 2007


7.  Security Considerations

   Channel encryption for LGSP is provided by Datagram Transport Layer
   Security (D-TLS) [RFC4347] and the multicast group security
   architecture [RFC3740], when operating in protected mode (refer
   Section 3.3).  This is an optional mode, but is strongly recommended
   for use over channels that do not already possess some adequate form
   of channel encryption.

   For channels that are already cryptographically protected, LGSP's
   unprotected mode is sufficient, and will minimise processing and
   network overhead.







































Tyson & Kopp              Expires June 21, 2008                [Page 55]

Internet-Draft                    LGSP                     December 2007


8.  References

8.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3452]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
              M., and J. Crowcroft, "xForward Error Correction (FEC)
              Building Block", RFC 3452, December 2002.

   [RFC3740]  Hardjono, T. and B. Weis, "The Multicast Group Security
              Architecture", RFC 3740, March 2004.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

8.2.  Informative References

   [EDGE]     Blackwell, Moeglein, M., and D. Nakayama, "A global DoD-
              optimized DGPS for precision-strike", 1995.

   [FAB-T]    Schiavone, LJ., "Airborne networking - approaches and
              challenges", 2004.

   [GGW]      Kopp, C., "GPS Guided Weapons", 1996,
              <http://www.ausairpower.net/TE-GPS-Guided-Weps.html>.

   [GLONASS-ICD]
              Russian Space Agency, "GLONASS Interface Control
              Document", 2002.

   [GPRS]     European Telecommunications Standards Institute, "Digital
              Cellular Telecommunications System (Phase 2+), General
              Packet Radio Service, Service Description, Stage 1",
              August 1999.

   [GPS-IS]   U.S. Air Force, "NAVSTAR GPS Space Segment/Navigation User
              Interfaces", 2006.

   [GSM]      Rahnema, M., "Overview of the GSM system and protocol



Tyson & Kopp              Expires June 21, 2008                [Page 56]

Internet-Draft                    LGSP                     December 2007


              architecture", 1993.

   [Galilei]  European Commission, "The Galilei Project: GALILEO Design
              Consolidation", 2003.

   [IEEE802.11]
              ANSI/IEEE, "802.11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications", 2000.

   [IP-Multicast]
              Sylvia, Andrey , and Scott, "Revisiting IP Multicast",
              2006.

   [JTIDS-IP]
              Stinson, W., "Internet Protocol (IP) over Link-16",
              March 2003.

   [JTIDS-MIDS]
              Hura, M., McLeod, G., Larson, EV., Schneider, J.,
              Gonzales, D., Norton, DM., Jacobs, J., O'Connell, KM.,
              Little, W., Mesic, R., and L. Jamison, "Interoperability:
              A Continuing Challenge in Coalition Air Operations", 2000.

   [JTRS]     Place, J., Kerr, D., and D. Schaefer, "Joint Tactical
              Radio System", 2000.

   [JTRSb]    Davis, K., "JTRS - An Open, Distributed-Object Computing
              Software Radio Architecture", 1999.

   [LAAS]     U.S. Federal Aviation Administration, "Performance Type
              One Local Area Augmentation System Ground Facility", 2002.

   [LGSP]     Tyson, M R. and C. Kopp, "Lightweight GNSS Support
              Protocol (LGSP) Definition (Unpublished internal
              document)", January 2007.

   [LGSP2]    Tyson, M R. and C. Kopp, "LGSP: A Lightweight GNSS Support
              Protocol for Military and Civil Applications",
              November 2007.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers",



Tyson & Kopp              Expires June 21, 2008                [Page 57]

Internet-Draft                    LGSP                     December 2007


              BCP 37, RFC 2780, March 2000.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [WAAS]     Loh, R., Wullschleger, V., Elrod, B., Lage, M., and F.
              Haas, "The U.S. Wide-Area Augmentation System (WAAS)",
              1995.

   [WAGE]     Vittorini, LD., "GPS URE/UE evolutionary improvements and
              end-user accuracy results", 1998.

   [WiMax]    Vaughan-Nichols, S., "Achieving wireless broadband with
              WiMax", 2004.



































Tyson & Kopp              Expires June 21, 2008                [Page 58]

Internet-Draft                    LGSP                     December 2007


Authors' Addresses

   Mike Tyson
   Monash University

   Email: mtyson@csse.monash.edu.au
   URI:   http://www.csse.monash.edu.au/~mtyson


   Carlo Kopp
   Monash University

   Email: carlo@csse.monash.edu.au
   URI:   http://www.csse.monash.edu.au/~carlo





































Tyson & Kopp              Expires June 21, 2008                [Page 59]

Internet-Draft                    LGSP                     December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Tyson & Kopp              Expires June 21, 2008                [Page 60]

