[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-schulzrinne-nsis-ntlp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 5971

Next Steps in Signaling                                   H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: November 18, 2005                                    R. Hancock
                                                             Siemens/RMR
                                                            May 17, 2005


       GIMPS:  General Internet Messaging Protocol for Signaling
                        draft-ietf-nsis-ntlp-06

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 November 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies protocol stacks for the routing and transport
   of per-flow signaling messages along the path taken by that flow
   through the network.  The design uses existing transport and security
   protocols under a common messaging layer, the General Internet
   Messaging Protocol for Signaling (GIMPS), which provides a universal
   service for diverse signaling applications.  GIMPS does not handle
   signaling application state itself, but manages its own internal



Schulzrinne & Hancock    Expires November 18, 2005              [Page 1]

Internet-Draft                    GIMPS                         May 2005


   state and the configuration of the underlying transport and security
   protocols to enable the transfer of messages in both directions along
   the flow path.  The combination of GIMPS and the lower layer
   transport and security protocols provides a solution for the base
   protocol component of the "Next Steps in Signaling" framework.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1  Restrictions on Scope  . . . . . . . . . . . . . . . . . .   5
   2.   Requirements Notation and Terminology  . . . . . . . . . . .   6
   3.   Design Overview  . . . . . . . . . . . . . . . . . . . . . .   8
     3.1  Overall Design Approach  . . . . . . . . . . . . . . . . .   8
     3.2  Modes and Messaging Associations . . . . . . . . . . . . .   9
     3.3  Message Routing Methods  . . . . . . . . . . . . . . . . .  11
     3.4  Signalling Sessions  . . . . . . . . . . . . . . . . . . .  12
     3.5  Example of Operation . . . . . . . . . . . . . . . . . . .  13
   4.   GIMPS Processing Overview  . . . . . . . . . . . . . . . . .  16
     4.1  GIMPS Service Interface  . . . . . . . . . . . . . . . . .  16
     4.2  GIMPS State  . . . . . . . . . . . . . . . . . . . . . . .  17
     4.3  Basic Message Processing . . . . . . . . . . . . . . . . .  19
     4.4  Routing State and Messaging Association Maintenance  . . .  24
   5.   Message Formats and Transport  . . . . . . . . . . . . . . .  30
     5.1  GIMPS Messages . . . . . . . . . . . . . . . . . . . . . .  30
     5.2  Information Elements . . . . . . . . . . . . . . . . . . .  32
     5.3  Datagram Mode Transport  . . . . . . . . . . . . . . . . .  35
     5.4  Connection Mode Transport  . . . . . . . . . . . . . . . .  39
     5.5  Message Type/Encapsulation Relationships . . . . . . . . .  41
     5.6  Messaging Association Negotiation  . . . . . . . . . . . .  42
     5.7  Specific Message Routing Methods . . . . . . . . . . . . .  44
   6.   Formal Protocol Specification  . . . . . . . . . . . . . . .  47
     6.1  Node Processing  . . . . . . . . . . . . . . . . . . . . .  48
     6.2  Query Node Processing  . . . . . . . . . . . . . . . . . .  49
     6.3  Responder Node Processing  . . . . . . . . . . . . . . . .  50
     6.4  Messaging Association Processing . . . . . . . . . . . . .  51
   7.   Advanced Protocol Features . . . . . . . . . . . . . . . . .  52
     7.1  Route Changes and Local Repair . . . . . . . . . . . . . .  52
     7.2  Policy-Based Forwarding and Flow Wildcarding . . . . . . .  58
     7.3  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  58
     7.4  Interaction with IP Tunnelling . . . . . . . . . . . . . .  60
     7.5  IPv4-IPv6 Transition and Interworking  . . . . . . . . . .  61
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  63
     8.1  Message Confidentiality and Integrity  . . . . . . . . . .  63
     8.2  Peer Node Authentication . . . . . . . . . . . . . . . . .  64
     8.3  Routing State Integrity  . . . . . . . . . . . . . . . . .  64
     8.4  Denial of Service Prevention . . . . . . . . . . . . . . .  66
     8.5  Summary of Requirements on Cookie Mechanisms . . . . . . .  67
     8.6  Residual Threats . . . . . . . . . . . . . . . . . . . . .  68



Schulzrinne & Hancock    Expires November 18, 2005              [Page 2]

Internet-Draft                    GIMPS                         May 2005


   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  70
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  72
     10.1   Additional Discovery Mechanisms  . . . . . . . . . . . .  72
   11.  Change History . . . . . . . . . . . . . . . . . . . . . . .  73
     11.1   Changes In Version -06 . . . . . . . . . . . . . . . . .  73
     11.2   Changes In Version -05 . . . . . . . . . . . . . . . . .  74
     11.3   Changes In Version -04 . . . . . . . . . . . . . . . . .  75
     11.4   Changes In Version -03 . . . . . . . . . . . . . . . . .  76
     11.5   Changes In Version -02 . . . . . . . . . . . . . . . . .  77
     11.6   Changes In Version -01 . . . . . . . . . . . . . . . . .  78
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  81
     12.1   Normative References . . . . . . . . . . . . . . . . . .  81
     12.2   Informative References . . . . . . . . . . . . . . . . .  81
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  83
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  84
   B.   Example Message Routing State Table  . . . . . . . . . . . .  85
   C.   Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . .  86
     C.1  General GIMPS Formatting Guidelines  . . . . . . . . . . .  86
     C.2  The GIMPS Common Header  . . . . . . . . . . . . . . . . .  86
     C.3  General Object Characteristics . . . . . . . . . . . . . .  87
     C.4  GIMPS TLV Objects  . . . . . . . . . . . . . . . . . . . .  88
   D.   API between GIMPS and NSLP . . . . . . . . . . . . . . . . .  95
     D.1  API Concepts . . . . . . . . . . . . . . . . . . . . . . .  95
     D.2  SendMessage  . . . . . . . . . . . . . . . . . . . . . . .  95
     D.3  RecvMessage  . . . . . . . . . . . . . . . . . . . . . . .  97
     D.4  MessageStatus  . . . . . . . . . . . . . . . . . . . . . .  98
     D.5  NetworkNotification  . . . . . . . . . . . . . . . . . . .  98
     D.6  SetStateLifetime . . . . . . . . . . . . . . . . . . . . .  99
     D.7  InvalidateRoutingState . . . . . . . . . . . . . . . . . .  99
        Intellectual Property and Copyright Statements . . . . . . . 100





















Schulzrinne & Hancock    Expires November 18, 2005              [Page 3]

Internet-Draft                    GIMPS                         May 2005


1.  Introduction

   Signaling involves the manipulation of state held in network
   elements.  'Manipulation' could mean setting up, modifying and
   tearing down state; or it could simply mean the monitoring of state
   which is managed by other mechanisms.

   This specification concentrates on "path-coupled" signaling, which
   involves network elements which are located on the path taken by a
   particular data flow, possibly including but not limited to the flow
   endpoints.  Indeed, there are almost always more than two
   participants in a path-coupled-signaling session, although there is
   no need for every node on the path to participate.  Path-coupled
   signaling thus excludes end-to-end higher-layer application signaling
   (except as a degenerate case) such as ISUP (telephony signaling for
   Signaling System #7) messages being transported by SCTP between two
   nodes.

   In the context of path-coupled signaling, examples of state
   management include network resource allocation (for "resource
   reservation"), firewall configuration, and state used in active
   networking; examples of state monitoring are the discovery of
   instantaneous path properties (such as available bandwidth, or
   cumulative queuing delay).  Each of these different uses of path-
   coupled signaling is referred to as a signaling application.

   Every signaling application requires a set of state management rules,
   as well as protocol support to exchange messages along the data path.
   Several aspects of this protocol support are common to all or a large
   number of signaling applications, and hence can be developed as a
   common protocol.  The NSIS framework given in [20] provides a
   rationale for a function split between the common and application
   specific protocols, and gives outline requirements for the former,
   the 'NSIS Transport Layer Protocol' (NTLP).

   This specification provides a concrete solution for the NTLP.  It is
   based on the use of existing transport and security protocols under a
   common messaging layer, the General Internet Messaging Protocol for
   Signaling (GIMPS).  GIMPS does not handle signaling application state
   itself; in that crucial respect, it differs from application
   signaling protocols such as SIP, RTSP, and the control component of
   FTP.  Instead, GIMPS manages its own internal state and the
   configuration of the underlying transport and security protocols to
   ensure the transfer of signaling messages on behalf of signaling
   applications in both directions along the flow path.






Schulzrinne & Hancock    Expires November 18, 2005              [Page 4]

Internet-Draft                    GIMPS                         May 2005


1.1  Restrictions on Scope

   This section briefly lists some important restrictions on GIMPS
   applicability and functionality.  In some cases, these are implicit
   consequences of the functionality split developed in the NSIS
   framework; in others, they are restrictions on the types of scenario
   in which GIMPS can operate correctly.

   Flow splitting: In some cases, e.g. where packet-level load sharing
      has been implemented, the path taken by a single flow in the
      network may not be well defined.  If this is the case, GIMPS
      cannot route signaling meaningfully.  (In some circumstances,
      GIMPS implementations could detect this condition, but even this
      cannot be guaranteed.)

   Multicast: GIMPS does not handle multicast flows.  This includes
      'classical' IP multicast and any of the 'small group multicast'
      schemes recently proposed.

































Schulzrinne & Hancock    Expires November 18, 2005              [Page 5]

Internet-Draft                    GIMPS                         May 2005


2.  Requirements Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [2].

   The terminology used in this specification is fully defined in this
   section.  The basic entities relevant at the GIMPS level are shown in
   Figure 1.

   Source                GIMPS (adjacent) peer nodes         Destination

   IP address              IP addresses = Signaling          IP address
   = Flow                Source/Destination Addresses        = Flow
   Source             (depending on signaling direction)     Destination
   Address                  |                   |            Address
                            V                   V
   +--------+           +------+  Data Flow  +------+         +--------+
   |  Flow  |-----------|------|-------------|------|-------->|  Flow  |
   | Sender |           |      |             |      |         |Receiver|
   +--------+           |GIMPS |============>|GIMPS |         +--------+
                        | Node |<============| Node |
                        +------+  Signaling  +------+
                          GN1       Flow       GN2

                  >>>>>>>>>>>>>>>>>  =  Downstream direction
                  <<<<<<<<<<<<<<<<<  =  Upstream direction

                        Figure 1: Basic Terminology

   [Data] Flow: A set of packets identified by some fixed combination of
      header fields.  Flows are unidirectional (a bidirectional
      communication is considered a pair of unidirectional flows).

   Session: A single application layer flow of information for which
      some state information is to be manipulated or monitored.  See
      Section 3.4 for further detailed discussion.

   [Flow] Sender: The node in the network which is the source of the
      packets in a flow.  Could be a host, or a router (e.g. if the flow
      is actually an aggregate).

   [Flow] Receiver: The node in the network which is the sink for the
      packets in a flow.







Schulzrinne & Hancock    Expires November 18, 2005              [Page 6]

Internet-Draft                    GIMPS                         May 2005


   Downstream: In the same direction as the data flow.

   Upstream: In the opposite direction to the data flow.

   GIMPS Node: Any node along the data path supporting GIMPS (regardless
      of what signaling applications it supports).

   Adjacent Peer: The next GIMPS node along the data path, in the
      upstream or downstream direction.  Whether two nodes are adjacent
      is determined implicitly by the GIMPS peer discovery mechanisms;
      it is possible for adjacencies to 'skip over' intermediate GIMPS
      nodes if it can be determined that they have no interest in the
      signaling messages being exchanged.

   Datagram Mode: A mode of sending GIMPS messages between nodes without
      using any transport layer state or security protection.  Datagram
      mode uses UDP encapsulation, with IP addresses derived either from
      the flow definition or previously discovered adjacency
      information.

   Connection Mode: A mode of sending GIMPS messages directly between
      nodes using point to point "messaging associations" (see below).
      Connection mode allows the re-use of existing transport and
      security protocols where such functionality is required.

   Messaging Association: A single connection between two explicitly
      identified GIMPS adjacent peers, i.e. between a given signaling
      source and destination address.  A messaging association may use a
      specific transport protocol and known ports.  If security
      protection is required, it may use a specific network layer
      security association, or use a transport layer security
      association internally.  A messaging association is bidirectional;
      signaling messages can be sent over it in either direction, and
      can refer to flows of either direction.

   Message Routing Method: Even in the path-coupled case, there can be
      different algorithms for discovering the route that signaling
      messages should take.  These are referred to as message routing
      methods, and GIMPS supports alternatives within a common protocol
      framework.  See Section 3.3.

   Transfer Attributes: A description of the requirements which a
      signaling application has for the delivery of a particular
      message; for example, whether the message should be delivered
      reliably.  See Section 4.1.2.






Schulzrinne & Hancock    Expires November 18, 2005              [Page 7]

Internet-Draft                    GIMPS                         May 2005


3.  Design Overview

3.1  Overall Design Approach

   The generic requirements identified in the NSIS framework [20] for
   transport of path-coupled signaling messages are essentially two-
   fold:

   "Routing": Determine how to reach the adjacent signaling node along
      each direction of the data path (the GIMPS peer), and if necessary
      explicitly establish addressing and identity information about
      that peer;

   "Transport": Deliver the signaling information to that peer.

   To meet the routing requirement, one possibility is for the node to
   use local routing state information to determine the identity of the
   GIMPS peer explicitly.  GIMPS defines a 3-way handshake (Query/
   Response/optional Confirm) which sets up the necessary routing state
   between adjacent peers during which signalling application data can
   also be exchanged; the Query message is encapsulated in a special
   way, depending on the message routing method, in order to probe the
   network infrastructure so that the correct peer will intercept it.
   If the routing state does not exist, it may be possible for GIMPS to
   send a message anyway, with the same encapsulation as used for a
   Query message.

   Once the routing decision has been made, the node has to select a
   mechanism for transport of the message to the peer.  GIMPS divides
   the transport problems into two categories, the easy and the
   difficult.  It handles the easy cases internally, and uses well-
   understood transport protocols for the harder cases.  Here, with
   details discussed later, "easy" messages are those that are sized
   well below the lowest MTU along a path, are infrequent enough not to
   cause concerns about congestion and flow control, and do not need
   security protection or guaranteed delivery.

   In [20] all of these routing and transport requirements are assigned
   to a single notional protocol, the 'NSIS Transport Layer Protocol'
   (NTLP).  The strategy of splitting the transport problem leads to a
   layered structure for the NTLP, as a specialised GIMPS 'messaging'
   layer running over standard transport and security protocols, as
   shown in Figure 2.  This also shows GIMPS offering its services to
   upper layers at an abstract interface, the GIMPS API, further
   discussed in Section 4.1.






Schulzrinne & Hancock    Expires November 18, 2005              [Page 8]

Internet-Draft                    GIMPS                         May 2005


          ^^                       +-------------+
          ||                       |  Signaling  |
         NSIS         +------------|Application 2|
       Signaling      |  Signaling +-------------+
      Application     |Application 1|         |
         Level        +-------------+         |
          ||              |                   |
          VV              |                   |
                 =========|===================|=====  <-- GIMPS API
                          |                   |
          ^^        +------------------------------------------------+
          ||        |+-----------------------+      +--------------+ |
          ||        ||         GIMPS         |      | GIMPS State  | |
          ||        ||     Encapsulation     |<<<>>>| Maintenance  | |
          ||        |+-----------------------+      +--------------+ |
          ||        |GIMPS: Messaging Layer                          |
          ||        +------------------------------------------------+
         NSIS               |       |       |       |
       Transport          .............................
         Level            . Transport Layer Security  .
       ("NTLP")           .............................
          ||                |       |       |       |
          ||              +----+  +----+  +----+  +----+
          ||              |UDP |  |TCP |  |SCTP|  |DCCP|....
          ||              +----+  +----+  +----+  +----+
          ||                |       |       |       |
          ||              .............................
          ||              .     IP Layer Security     .
          ||              .............................
          VV                |       |       |       |
   =========================|=======|=======|=======|===============
                            |       |       |       |
                    +----------------------------------------------+
                    |                      IP                      |
                    +----------------------------------------------+

             Figure 2: Protocol Stacks for Signaling Transport


3.2  Modes and Messaging Associations

   Internally, GIMPS has two modes of operation:

   Datagram mode ('D mode') is used for small, infrequent messages with
      modest delay constraints; it is also used at least for the Query
      message of the 3-way handshake.





Schulzrinne & Hancock    Expires November 18, 2005              [Page 9]

Internet-Draft                    GIMPS                         May 2005


   Connection mode ('C mode') is used for larger data objects or where
      fast state setup in the face of packet loss is desirable, or where
      channel security is required.

   Datagram mode uses UDP, as this is the only encapsulation which does
   not require per-message shared state to be maintained between the
   peers.  The connection mode can in principal use any stream or
   message-oriented transport protocol; this specification currently
   defines the use of TCP as the initial choice.  It may employ specific
   network layer security associations (such as IPsec), or an internal
   transport layer security association (such as TLS).  When GIMPS
   messages are carried in connection mode, they are treated just like
   any other traffic by intermediate routers between the GIMPS peers.
   Indeed, it would be impossible for intermediate routers to carry out
   any processing on the messages without terminating the transport and
   security protocols used.  Also, signaling messages are only ever
   delivered between peers established in GIMPS-Query/Response
   exchanges.

   It is possible to mix these two modes along a path.  This allows, for
   example, the use of datagram mode at the edges of the network and
   connection mode in the core of the network.  Such combinations may
   make operation more efficient for mobile endpoints, while allowing
   multiplexing of signaling messages across shared security
   associations and transport connections between core routers.

   It must be understood that the routing and transport decisions made
   by GIMPS are not independent.  If the message transfer has
   requirements that enforce the use of connection mode (e.g. the
   message is so large that fragmentation is required), this can only be
   used between explicitly identified nodes.  In such cases, GIMPS must
   carry out the 3-way handshake initially in datagram mode to identify
   the peer and then set up the necessary transport connection if it
   does not already exist.  It must also be understood that the
   signaling application does not make the D/C mode selection directly;
   rather, this decision is made by GIMPS on the basis of the message
   characteristics and the transfer attributes stated by the
   application.  The distinction is not visible at the GIMPS service
   interface.

   In general, the state associated with connection mode messaging to a
   particular peer (signaling destination address, protocol and port
   numbers, internal protocol configuration and state information) is
   referred to as a "messaging association".  There may be any number of
   messaging associations between two GIMPS peers (although the usual
   case is 0 or 1), and they are set up and torn down by management
   actions within GIMPS itself.




Schulzrinne & Hancock    Expires November 18, 2005             [Page 10]

Internet-Draft                    GIMPS                         May 2005


3.3  Message Routing Methods

   The baseline message routing functionality in GIMPS is that
   signalling messages follow a route defined by an existing flow in the
   network, visiting a subset of the nodes through which it passes.
   This is the appropriate behaviour for application scenarios where the
   purpose of the signalling is to manipulate resources for that flow.
   However, there are scenarios for which other behaviours are
   applicable.  Two examples are:

   Predictive Routing: Here, the intent is to send signaling along a
      path that the data flow may or will follow in the future.
      Possible cases are pre-installation of state on the backup path
      that would be used in the event of a link failure; and predictive
      installation of state on the path that will be used after a mobile
      node handover.

   NAT Address Reservations: This applies to the case where a node
      behind a NAT wishes to use NSIS signaling to reserve an address
      from which it can be reached by a sender on the other side.  This
      requires a message to be sent outbound from what will be the flow
      receiver although no reverse routing state exists.

   Most of the details of GIMPS operation are independent of which
   alternative is being used.  Therefore, the GIMPS design encapsulates
   the routing-dependent details as a message routing method (MRM), and
   allows multiple MRMs to be defined.  The default is the path-coupled
   MRM, which corresponds to the baseline functionality described above;
   an additional possible MRM for the NAT Address Reservation case is
   described in [29].

   The content of a MRM definition is as follows, using the path-coupled
   MRM as an example:

   o  The format of the information that describes the path that the
      signalling should take, the Message Routing Information (MRI).
      For the path-coupled MRM, this is just the Flow Identifier (see
      Section 5.7.1.1).  The MRI includes an element to distinguish
      between the two directions that signalling messages can take,
      'upstream' and 'downstream'.

   o  A specification of how GIMPS should encapsulate the messages at
      the IP level that probe the network to discover the adjacent
      peers.  A downstream encapsulation must be defined; an upstream
      encapsulation is optional.  For the path-coupled MRM, this
      information is given in Section 5.7.1.2.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 11]

Internet-Draft                    GIMPS                         May 2005


   o  A specification of what validation checks GIMPS should apply to
      the probe messages, for example to protect against IP address
      spoofing attacks.  For the path-coupled MRM this is basically a
      form of ingress filtering, also discussed in Section 5.7.1.2.

   In addition, it should be noted that NAT traversal almost certainly
   requires transformation of the MRI field in GIMPS messages (see
   Section 7.3).  Although the transformation does not have to be
   defined as part of the standard, the impact on existing GIMPS NAT
   implementations should be considered.

3.4  Signalling Sessions

   GIMPS allows signalling applications to associate the message it
   handles with a "signalling session".  Informally, given an
   application layer exchange of information for which some network
   control state information is to be manipulated or monitored, the
   corresponding signalling messages should be associated with the same
   session by a signalling application.  Signalling applications provide
   the session identifier (SID) whenever they wish to send a message,
   and GIMPS reports the SID when a message is received.

   Most GIMPS processing and state information is related to the flow
   (defined by the MRI, see above) and NSLPID.  There are several
   possible relationships between flows and sessions, for example:

   o  The simplest case is that all messages for the same flow have the
      same SID.

   o  Messages for more than one flow may use the same SID, for example
      because one flow is replacing another in a mobility or multihoming
      scenario.

   o  A single flow may have messages for different SIDs, for example
      from independently operating signalling applications.

   Because of this range of options, GIMPS does not perform any
   validation on how signalling applications map between flows and
   sessions, nor does it perform any validation on the properties of the
   SID itself.  In particular, when a new SID is needed, logically it
   should be generated by the NSLP.  (NSIS implementations could provide
   common functionality to generate SIDs for use by any NSLP, but this
   is not part of GIMPS.)  GIMPS only defines the syntax of the SID as
   an opaque 128-bit number.

   The SID assignment has the following impact on GIMPS processing:





Schulzrinne & Hancock    Expires November 18, 2005             [Page 12]

Internet-Draft                    GIMPS                         May 2005


   o  Messages with the same SID to be delivered reliably between the
      same GIMPS peers are delivered in order.

   o  All other messagse are handled independently.

   o  GIMPS identifies routing state (upstream and downstream peer) by
      the triplet (MRI, NSLPID, SID).

   Strictly, the routing state should not depend on the SID.  However,
   if the routing state is keyed only by (MRI, NSLPID) there is a
   trivial denial of service attack (see Section 8.3) where a malicious
   off-path node asserts that it is the peer for a particular flow.
   Instead, the routing state is also segregated between different SIDs,
   which means that the attacking node can only disrupt a signalling
   session if it can guess the corresponding SID.  A consequence of this
   design is that signalling applications should choose SIDs so that
   they are cryptographically random, and should not use several SIDs
   for the same flow unless strictly necessary, to avoid additional load
   on the routing state maintenance.

3.5  Example of Operation

   This section presents an example of GIMPS usage in a relatively
   simple (in particular, NAT-free) signaling scenario, to illustrate
   its main features.

   Consider the case of an RSVP-like signaling application which
   allocates resources for a single unicast flow.  We will consider how
   GIMPS transfers messages between two adjacent peers along the path,
   GN1 and GN2 (see Figure 1).  In this example, the end-to-end exchange
   is initiated by the signaling application instance in the sender; we
   take up the story at the point where the first message is being
   processed (above the GIMPS layer) by the signaling application in
   GN1.

   1.  The signaling application in GN1 determines that this message is
       a simple description of resources that would be appropriate for
       the flow.  It determines that it has no special security or
       transport requirements for the message, but simply that it should
       be transferred to the next downstream signaling application peer
       on the path that the flow will take.

   2.  The message payload is passed to the GIMPS layer in GN1, along
       with a definition of the flow and description of the message
       transfer attributes {unsecured, unreliable}.  GIMPS determines
       that this particular message does not require fragmentation and
       that it has no knowledge of the next peer for this flow and
       signaling application; however, it also determines that this



Schulzrinne & Hancock    Expires November 18, 2005             [Page 13]

Internet-Draft                    GIMPS                         May 2005


       application is likely to require secured upstream and downstream
       transport of large messages in the future.  This determination is
       a function of node-local policy; see Appendix D.1 for some
       additional discussion.

   3.  GN1 therefore constructs a GIMPS-Query message, which is a UDP
       datagram carrying the signaling application payload and
       additional payloads at the GIMPS level to be used to initiate the
       setup of a messaging association.  The Query is injected into the
       network, addressed towards the flow destination and with a Router
       Alert Option included.

   4.  The Query message passes through the network towards the flow
       receiver, and is seen by each router in turn.  GIMPS-unaware
       routers will not recognise the RAO value and will forward the
       message unchanged; GIMPS-aware routers which do not support the
       signaling application in question will also forward the message
       basically unchanged, although they may need to process more of
       the message to decide this.

   5.  The message is intercepted at GN2.  The GIMPS layer identifies
       the message as relevant to a local signaling application, and
       passes the signaling application payload and flow description
       upwards to it.  There, the signaling application in GN2 continues
       to process this message as in GN1 (compare step 1), and this will
       eventually result in the message reaching the flow receiver.

   6.  In parallel, the GIMPS instance in GN2 recognises, by the fact
       that the message is a GIMPS-Query, that GN1 is attempting to
       discover GN2 in order to set up a messaging association for
       future signaling for the flow.  There are two basic possible
       cases for sending back the necessary GIMPS-Response:

       A.  GN1 and GN2 already have an appropriate association.  GN2
           simply records the identity of GN1 as its upstream peer for
           that flow and signaling application, and sends a GIMPS-
           Response back to GN1 over the association identifying itself
           as the peer for this flow.

       B.  No messaging association exists.  GN2 sends the GIMPS-
           Response in D mode directly to GN1, identifying itself and
           agreeing to the association setup.  The protocol exchanges
           needed to complete this will proceed in the background.

   7.  Eventually, another signaling application message works its way
       upstream from the receiver to GN2.  This message contains a
       description of the actual resources requested, along with
       authorisation and other security information.  The signaling



Schulzrinne & Hancock    Expires November 18, 2005             [Page 14]

Internet-Draft                    GIMPS                         May 2005


       application in GN2 passes this payload to the GIMPS level, along
       with the flow definition and transfer attributes {secured,
       reliable}.

   8.  The GIMPS layer in GN2 identifies the upstream peer for this flow
       and signaling application as GN1, and determines that it has a
       messaging association with the appropriate properties.  The
       message is queued on the association for transmission (this may
       mean some delay if the negotiations begun in step 6.B have not
       yet completed).

   Further messages can be passed in each direction in the same way.
   The GIMPS layer in each node can in parallel carry out maintenance
   operations such as route change detection (this can be done by
   sending additional GIMPS-Query messages, see Section 7.1 for more
   details).

   It should be understood that several of these details of GIMPS
   operations can be varied, either by local policy or according to
   signaling application requirements.  The authoritative details are
   contained in the remainder of this document.






























Schulzrinne & Hancock    Expires November 18, 2005             [Page 15]

Internet-Draft                    GIMPS                         May 2005


4.  GIMPS Processing Overview

   This section defines the basic structure and operation of GIMPS.
   Section 4.1 describes the way in which GIMPS interacts with (local)
   signaling applications in the form of an abstract service interface.
   Section 4.2 describes the per-flow and per-peer state that GIMPS
   maintains for the purpose of transferring messages.  Section 4.3
   describes how messages are processed in the case where any necessary
   messaging associations and routing state already exist; this includes
   the simple scenario of pure datagram mode operation, where no
   messaging associations are necessary in the first place.  Finally,
   Section 4.4 describes how routing state and messaging associations
   are created and managed.

4.1  GIMPS Service Interface

   This section defines the service interface that GIMPS presents to
   signaling applications in terms of abstract properties of the message
   transfer.  Note that the same service interface is presented at every
   GIMPS node; however, applications may invoke it differently at
   different nodes (e.g. depending on local policy).  In addition, the
   service interface is defined independently of any specific transport
   protocol, or even the distinction between datagram and connection
   mode.  The initial version of this specification defines how to
   support the service interface using a connection mode based on TCP;
   if additional transport protocol support is added, this will support
   the same interface and so be invisible to applications (except as a
   possible performance improvement).  A more detailed description of
   this service interface is given in Appendix D.

4.1.1  Message Handling

   Fundamentally, GIMPS provides a simple message-by-message transfer
   service for use by signaling applications: individual messages are
   sent, and individual messages are received.  At the service
   interface, the signalling application payload (which is opaque to
   GIMPS) is accompanied by control information expressing the
   application's requirements about how the message should be routed,
   and the application also provides the session identifier (see
   Section 3.4).  Additional message transfer attributes control the
   specific transport and security properties that the signaling
   application desires for the message.

   The distinction between GIMPS connection and datagram modes is not
   visible at the service interface.  In addition, the invocation of
   GIMPS functionality to handle fragmentation and reassembly, bundling
   together of small messages (for efficiency), and congestion control
   is not directly visible at the service interface; GIMPS will take



Schulzrinne & Hancock    Expires November 18, 2005             [Page 16]

Internet-Draft                    GIMPS                         May 2005


   whatever action is necessary based on the properties of the messages
   and local node state.

4.1.2  Message Transfer Attributes

   Message transfer attributes are used to define certain performance
   and security related aspects of message processing.  The attributes
   available are as follows:

   Reliability: This attribute may be 'true' or 'false'.  For the case
      'true', messages will be delivered to the signaling application in
      the peer exactly once or not at all; if there is a chance that the
      message was not delivered, an error will be indicated to the local
      signaling application identifying the routing information for the
      message in question.  For the case 'false', a message may be
      delivered, once, several times or not at all, with no error
      indications in any case.

   Security: This attribute defines the security properties that the
      signaling application requires for the message, including the type
      of protection required, and what authenticated identities should
      be used for the signaling source and destination.  This
      information maps onto the corresponding properties of the security
      associations established between the peers in connection mode.  It
      can be specified explicitly by the signaling application, or
      reported by GIMPS to the signaling application (either on
      receiving a message, or just before sending a message but after
      configuring or selecting the messaging association to be used for
      it).  This attribute can also be used to convey information about
      any address validation carried out by GIMPS (for example, whether
      a return routability check has been carried out).  Further details
      are discussed in Appendix D.

   Local Processing: An NSLP may provide hints to GIMPS to enable more
      efficient or appropriate processing.  For example, the NSLP may
      select a priority from a range of locally defined values to
      influence the sequence in which messages leave a node.  Any
      priority mechanism must respect the ordering requirements for
      reliable messages within a session, and priority values are not
      carried in the protocol or available at the signaling peer or
      intermediate nodes.  An NSLP may also indicate that reverse path
      routing state will not be needed for this flow, to inhibit the
      node requesting its downstream peer to create it.


4.2  GIMPS State





Schulzrinne & Hancock    Expires November 18, 2005             [Page 17]

Internet-Draft                    GIMPS                         May 2005


4.2.1  Message Routing State

   For each flow, the GIMPS layer can maintain message routing state to
   manage the processing of outgoing messages.  This state is
   conceptually organised into a table with the following structure.

   The primary key (index) for the table is the combination of the
   information about how the message is to be routed, the session being
   signalled for, and the signaling application itself:

   Message Routing Information (MRI): This defines the method to be used
      to route the message, the direction in which to send the message,
      and any associated addressing information; see Section 3.3.

   Session Identification (SID): The signalling session with which this
      message should be associated; see Section 3.4.

   Signaling Application Identification (NSLPID): This is an IANA
      assigned identifier of the signaling application which is
      generating messages for this flow.  The inclusion of this
      identifier allows the routing state to be different for different
      signaling applications (e.g. because of different adjacencies).

   The information for a given key consists of two items: the routing
   state to reach the upstream and the downstream peer, with respect to
   the MRI in each case.  The routing state includes information about
   the peer identity (see Section 4.4.2), and a UDP port number (for
   datagram mode) or a reference to one or more messaging associations
   (for connection mode).  All of this information is learned from prior
   GIMPS exchanges.

   It is also possible for the state information for either direction to
   be null.  There are several possible cases:

   o  The signaling application has indicated that no messages will
      actually be sent in that direction.

   o  The node is a flow endpoint, so there can be no signaling peer in
      one or other direction.

   o  The node is the endpoint of the signalling path (for example,
      because it is acting as a proxy, or because it has determined
      explicitly that there are no further signalling nodes in that
      direction).

   o  The node can use other techniques to route the message.  For
      example, it can encapsulate it the same way as a Query message and
      rely on the peer to intercept it.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 18]

Internet-Draft                    GIMPS                         May 2005


   Each item of routing state has an associated validity timer for how
   long it can be considered accurate; when this timer expires, it is
   purged if it has not been refreshed.  Installation and maintenance of
   routing state is described in more detail in Section 4.4.

   Note also that the routing state is described as a table of flows,
   but that there is no implied constraint on how the information is
   stored.  However, in general, and especially if GIMPS peers are
   several IP hops away, there is no way to identify the correct
   downstream peer for a flow and signaling application from the local
   forwarding table using prefix matching, and the same applies always
   to upstream peer state because of the possibility of asymmetric
   routing: per-flow state has to be stored, just as for RSVP [9].

4.2.2  Messaging Association State

   The per-flow message routing state is not the only state stored by
   GIMPS.  There is also the state required to manage the messaging
   associations.  Since these associations are typically per-peer rather
   than per-flow, they are stored in a separate table, including the
   following information:

   o  messages pending transmission while an association is being
      established;

   o  a timer for how long since the peer re-stated its desire to keep
      the association open (see Section 4.4.3).

   In addition, per-association state is held in the messaging
   association protocols themselves.  However, the details of this state
   are not directly visible to GIMPS, and they do not affect the rest of
   the protocol description.

4.3  Basic Message Processing

   This section describes how signaling application messages are
   processed in the case where any necessary messaging associations and
   routing state are already in place.  The description is divided into
   several parts.  Firstly, message reception, local processing and
   message transmission are described for the case where the node
   handles the NSLPID in the message.  Secondly, the case where the
   message is forwarded directly in the IP or GIMPS layer (because there
   is no matching signaling application on the node) is given.  An
   overview is given in Figure 3.







Schulzrinne & Hancock    Expires November 18, 2005             [Page 19]

Internet-Draft                    GIMPS                         May 2005


       +---------------------------------------------------------+
       |        >>  Signaling Application Processing   >>        |
       |                                                         |
       +--------^---------------------------------------V--------+
                ^                                       V
                ^             NSLP Payloads             V
                ^                                       V
       +--------^---------------------------------------V--------+
       |                    >>    GIMPS   >>                     |
       |  ^           ^  ^     Processing      V  V           V  |
       +--x-----------N--Q---------------------Q--N-----------x--+
          x           N  Q                     Q  N           x
          x           N  Q>>>>>>>>>>>>>>>>>>>>>Q  N           x
          x           N  Q      Bypass at      Q  N           x
       +--x-----+  +--N--Q--+  GIMPS level  +--Q--N--+  +-----x--+
       | C-mode |  | D-mode |               | D-mode |  | C-mode |
       |Handling|  |Handling|               |Handling|  |Handling|
       +--x-----+  +--N--Q--+               +--Q--N--+  +-----x--+
          x          N   Q                     Q   N          x
          x    NNNNNN    Q>>>>>>>>>>>>>>>>>>>>>Q    NNNNNN    x
          x   N          Q      Bypass at      Q          N   x
       +--x--N--+  +-----Q--+    router     +--Q-----+  +--N--x--+
       |IP Host |  |  RAO   |  alert level  |  RAO   |  |IP Host |
       |Handling|  |Handling|               |Handling|  |Handling|
       +--x--N--+  +-----Q--+               +--Q-----+  +--N--x--+
          x  N           Q                     Q           N  x
       +--x--N-----------Q--+               +--Q-----------N--x--+
       |      IP Layer      |               |      IP Layer      |
       |   (Receive Side)   |               |  (Transmit Side)   |
       +--x--N-----------Q--+               +--Q-----------N--x--+
          x  N           Q                     Q           N  x
          x  N           Q                     Q           N  x
          x  N           Q                     Q           N  x


            NNNNNNNNNNNNNN = 'Normal' datagram mode messages
            QQQQQQQQQQQQQQ = Datagram mode messages which
                             are Queries or likewise encapsulated
            xxxxxxxxxxxxxx = connection mode messages
                       RAO = Router Alert Option

               Figure 3: Message Paths through a GIMPS Node


4.3.1  Message Reception

   Messages can be received in connection or datagram mode, and in the
   latter case with two types of message encapsulation.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 20]

Internet-Draft                    GIMPS                         May 2005


   Reception in connection mode is simple: incoming packets undergo the
   security and transport treatment associated with the messaging
   association, and the messaging association provides complete messages
   to the GIMPS layer for further processing.  Unless the message is
   protected by a query/response cookie exchange (see Section 4.4), the
   routing state table is checked to ensure that this messaging
   association is associated with the MRI/NSLPID/SID combination given
   in the message.

   Reception in datagram mode depends on the message type.  'Normal'
   messages arrive UDP encapsulated and addressed directly to the
   receiving signaling node, at an address and port learned previously.
   Each datagram contains a single complete message which is passed to
   the GIMPS layer for further processing, just as in the connection
   mode case.

   Where GIMPS is sending messages to be intercepted by the appropriate
   peer rather than directly addressed to it (in particular, Query
   messages), these are UDP encapsulated with an IP router alert option.
   Each signaling node will therefore 'see' all such messages.  The case
   where the NSLPID does not match a local signaling application is
   considered below in Section 4.3.4; otherwise, it is passed up to the
   GIMPS layer for further processing as in the other cases.

4.3.2  Local Processing

   Once a message has been received, by any method, it is processed
   locally within the GIMPS layer.  The GIMPS processing to be done
   depends on the message type and payloads carried; most of the GIMPS-
   internal payloads are associated with state maintenance and are
   covered in Section 4.4.  There is also a hop count to prevent message
   looping, see Section 4.3.4.

   The remainder of the GIMPS message consists of an NSLP payload.  This
   is delivered locally to the signaling application identified at the
   GIMPS level; the format of the NSLP payload is not constrained by
   GIMPS, and the content is not interpreted.

   Signaling applications can generate their messages for transmission,
   either asynchronously, or in response to an input message, and GIMPS
   can also generate messages autonomously.  Regardless of the source,
   outgoing messages are passed downwards for message transmission.

4.3.3  Message Transmission

   When a message is available for transmission, GIMPS uses internal
   policy and the stored routing state to determine how to handle it.
   The following processing applies equally to locally generated



Schulzrinne & Hancock    Expires November 18, 2005             [Page 21]

Internet-Draft                    GIMPS                         May 2005


   messages and messages forwarded from within the GIMPS or signaling
   application levels.

   The main decision is whether the message must be sent in connection
   mode or datagram mode.  Reasons for using the former could be:

   o  NSLP requirements: for example, the signaling application has
      requested channel secured delivery, or reliable delivery;

   o  protocol specification: for example, this document specifies that
      a message that requires fragmentation MUST be sent over a
      messaging association;

   o  local GIMPS policy: for example, a node may prefer to send
      messages over a messaging association to benefit from adaptive
      congestion control.

   In principle, as well as determining that some messaging association
   must be used, GIMPS could select between a set of alternatives, e.g.
   for load sharing or because different messaging associations provide
   different transport or security attributes.

   If the use of a messaging association is selected, the message is
   queued on the association found from the routing state table, and
   further output processing is carried out according to the details of
   the protocol stacks used.  If no appropriate association exists, the
   message is queued while one is created (see Section 4.4).  If no
   association can be created, this is an error condition, and should be
   indicated back to the local NSLP.

   If a messaging association is not required, the message is sent in
   datagram mode.  The processing in this case depends on the message
   type and whether routing state exists or not.

   o  If the message is not a Query, and routing state exists, it is UDP
      encapsulated and sent directly to the address from the routing
      state table.

   o  If the message is a Query, then it is UDP encapsulated with IP
      address and router alert option determined from the MRI and NSLPID
      (further details depend on the message routing method).

   o  If no routing state exists, GIMPS can attempt to use the same IP/
      UDP encapsulation as in the Query case.  If this is not possible
      (e.g. because the encapsulation algorithm for the message routing
      method is only defined valid for one message direction), then this
      is an error condition which is reported back to the local NSLP.




Schulzrinne & Hancock    Expires November 18, 2005             [Page 22]

Internet-Draft                    GIMPS                         May 2005


4.3.4  Bypass Forwarding

   A node may have to handle messages for which it has no signaling
   application corresponding to the message NSLPID.  There are several
   possible cases depending mainly on the RAO setting (see Section 5.3.3
   for more details):

   1.  A datagram mode message contains an RAO value which is relevant
       to NSIS but not to the specific node, but the IP layer is unable
       to recognise whether it needs to be passed to GIMPS for further
       processing or whether the packet should be forwarded just like a
       normal IP datagram.

   2.  A datagram mode message contains an RAO value which is relevant
       to the node, but the specific signaling application for the
       actual NSLPID in the message is not processed there.

   3.  A message is delivered directly to the node for which there is no
       corresponding signaling application.  (According to the rules of
       the current specification, this should never happen.  However,
       future versions might find a use for such a feature.)

   +-------------+-------------+-------------------+-------------------+
   |  Match RAO? |    Match    |  IP TTL Handling  |    GHC Handling   |
   |             |   NSLPID?   |                   |                   |
   +-------------+-------------+-------------------+-------------------+
   |      No     | N/A (NSLPID |     Decrement;    |       Ignore      |
   |             |     not     |  forward message  |                   |
   |             |  examined)  |                   |                   |
   |             |             |                   |                   |
   |     Yes     |      No     |     Decrement;    |    Decremented    |
   |             |             |  forward message  |                   |
   |             |             |                   |                   |
   |   Message   |      No     |       Reset       |   Decrement and   |
   |   directly  |             |                   |  forward at GIMPS |
   |  addressed  |             |                   |     level (not    |
   |             |             |                   |    possible in    |
   |             |             |                   |      current      |
   |             |             |                   |   specification)  |
   |             |             |                   |                   |
   |   Yes, or   |     Yes     | Locally delivered |   N/A (ignored)   |
   |   message   |             |                   |                   |
   |   directly  |             |                   |                   |
   |  addressed  |             |                   |                   |
   +-------------+-------------+-------------------+-------------------+

    In all cases, the role of GIMPS is to forward the message
   essentially unchanged.  However, a GIMPS implementation must ensure



Schulzrinne & Hancock    Expires November 18, 2005             [Page 23]

Internet-Draft                    GIMPS                         May 2005


   that the IP TTL field and GIMPS hop count are managed correctly to
   prevent message looping, and this should be done consistently
   independently of whether the processing (e.g. for case (1)) takes
   place on the fast path or in GIMPS-specific code.  The rules are that
   in cases (1) and (2), the IP TTL is decremented just as if the
   message was a normal IP forwarded packet; in cases (2) and (3) the
   GIMPS hop count is decremented as in the case of normal input
   processing.  These rules are summarised in the table above.

4.4  Routing State and Messaging Association Maintenance

   The main responsibility of GIMPS is to manage the routing state and
   messaging associations which are used in the basic message processing
   described above.  Routing state is installed and maintained by
   specific GIMPS messages.  Messaging associations are dependent on the
   existence of routing state, but are actually set up by the normal
   procedures of the transport and security protocols that comprise
   them.  Timers control routing state and messaging association refresh
   and expiration.

   There are two different cases for state installation and refresh:

   1.  Where routing state is being discovered or a new association is
       to be established; and

   2.  Where an existing association can be re-used, including the case
       where routing state for the flow is being refreshed.

   These cases are now considered in turn, along with the case of
   general management procedures.

4.4.1  State Setup

   The complete sequence of possible messages for state setup between
   adjacent peers is shown in Figure 4 and described in detail in the
   following text.

   The initial message in any routing state maintenance operation is a
   GIMPS-Query message, sent from the querying node and intercepted at
   the responding node.  This message has addressing and other
   identifiers appropriate for the flow and signaling application that
   state maintenance is being done for, addressing information about the
   node itself, and it is allowed to contain an NSLP payload.  The
   querying node also includes additional payloads: a Query Cookie, and
   optionally a proposal for possible messaging association protocol
   stacks.  The role of the cookies in this and subsequent messages is
   to protect against certain denial of service attacks and to correlate
   the various events in the message sequence.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 24]

Internet-Draft                    GIMPS                         May 2005


            +----------+                     +----------+
            | Querying |                     |Responding|
            |   Node   |                     |   Node   |
            +----------+                     +----------+
                             GIMPS-Query
                       ---------------------->        .............
                       Router Alert Option            .  Routing  .
                       MRI/SID/NSLPID                 .   state   .
                       Q-Node Network Layer Info      . installed .
                       Query Cookie                   .    at     .
                       [Q-Node Stack-Proposal         . R-node(1) .
                        Q-Node Stack-Config Data]     .............
                       [NSLP Payload]

               ......................................
               .  The responder can use an existing .
               . messaging association if available .
               . from here onwards to short-circuit .
               .     messaging association setup    .
               ......................................

                           GIMPS-Response
   .............       <----------------------
   .  Routing  .       MRI/SID/NSLPID
   .   state   .       R-Node Network Layer Info (D Mode only)
   . installed .       Query cookie
   .    at     .       [R-Node Stack-Proposal
   .  Q-Node   .        R-Node Stack-Config Data]
   .............       [Responder Cookie]
                       [NSLP Payload]

                ....................................
                . If a messaging association needs .
                . to be created, it is set up here .
                ....................................

                           GIMPS-Confirm
                       ---------------------->
                       MRI/SID/NSLPID                 .............
                       Q-Node Network Layer Info      .  Routing  .
                       Responder Cookie               .   state   .
                       [R-Node Stack-Proposal]        . installed .
                       [NSLP Payload]                 .    at     .
                                                      . R-node(2) .
                                                      .............

                 Figure 4: Message Sequence at State Setup




Schulzrinne & Hancock    Expires November 18, 2005             [Page 25]

Internet-Draft                    GIMPS                         May 2005


   Reception of a GIMPS-Query triggers the generation of a GIMPS-
   Response message.  This is a 'normally' encapsulated datagram mode
   message with additional payloads.  It contains network layer
   information about the responding node, echoes the Query Cookie, and
   can contain an NSLP payload (possibly a response to the NSLP payload
   in the initial message).  In case a messaging association was
   requested, it must also contain a Responder Cookie and counter-
   proposal for the messaging association protocol stacks.  Otherwise,
   it may still include a Responder Cookie if the node's routing state
   setup policy requires it (see below).

   Setup of a new messaging association begins when peer addressing
   information is available and a new messaging association is actually
   needed.  The setup has to be contemporaneous with a specific GIMPS-
   Query/Response exchange, because the addressing information used may
   have a limited lifetime (either because it depends on limited
   lifetime NAT bindings, or because it refers to agile destination
   ports for the transport protocols).  The negotiation of what
   protocols to use for the messaging association is controlled by the
   Stack-Proposal and Stack-Configuration-Data information exchanged,
   and the processing of these objects is described in more detail in
   Section 5.6.  With the protocol options currently defined, setup of
   the messaging association always starts from the Querying node,
   although more flexible configurations are possible within the overall
   GIMPS design.  In any case, once set up the association itself can be
   used equally in both directions.

   The GIMPS-Confirm is the first message sent over the association and
   echoes the Responder Cookie and Stack Proposal from the GIMPS-
   Response.  The former is used to allow the receiver to validate the
   contents of the message (see Section 8.5), and the latter is to
   prevent certain bidding-down attacks on messaging association
   security.  The association can be used in the upstream direction for
   that flow and NSLPID after the Confirm has been received.

   The querying node installs the responder address as routing state
   information after verifying the Query Cookie in the GIMPS-Response.
   The responding node can install the querying address as peer state
   information at two points in time:

   1.  after the receipt of the initial GIMPS-Query, or

   2.  after a GIMPS-Confirm message containing the Responder Cookie.

   The precise constraints on when state information is installed are a
   matter of security policy considerations on prevention of denial-of-
   service attacks and state poisoning attacks, which are discussed
   further in Section 8.  Because the responding node may choose to



Schulzrinne & Hancock    Expires November 18, 2005             [Page 26]

Internet-Draft                    GIMPS                         May 2005


   delay state installation as in case (2), the GIMPS-Confirm must
   contain sufficient information to allow it to be processed
   identically to the original Query.  This places some special
   requirements on NAT traversal and cookie functionality, which are
   discussed in Section 7.3 and Section 8 respectively.

4.4.2  Association Re-use

   It is a general design goal of GIMPS that, so far as possible,
   messaging associations should be re-used for multiple flows and
   sessions, rather than a new association set up for each.  This is to
   ensure that the association cost scales only like the number of
   peers, and to avoid the latency of new association setup where
   possible.

   However, re-use requires the identification of an existing
   association which matches the same routing state and desired
   properties that would be the result of a full handshake in D-mode,
   and this identification must be done as reliably and securely as
   continuing with the full procedure.  Note that this requirement is
   complicated by the fact that NATs may remap the node addresses in
   D-mode messages, and also interacts with the fact that some nodes may
   peer over multiple interfaces (and so with different addresses).

   Association re-use is controlled by the Network-Layer-Information
   (NLI) object, which is carried in GIMPS-Query/Confirm and optionally
   GIMPS-Response messages.  The NLI object includes:

   Peer-Identity: For a given node, this is a stable quantity (interface
      independent) with opaque syntax.  It should be chosen so as to
      have a high probability of uniqueness between peers.  Note that
      there is no cryptographic protection of this identity (attempting
      to provide this would essentially duplicate the functionality in
      the messaging association security protocols).

   Interface-Address: This is an IP address associated with the
      interface through which the flow associated with the signaling is
      routed.  This can be considered as a routable identifier through
      which the signaling node can be reached; further discussion is
      contained in Section 5.6.

   By default, a messaging association is associated with the NLI object
   that was provided by the peer in the Query/Response/Confirm at the
   time the association was set up.  There may be more than one
   association for a given NLI object (e.g. with different properties).

   Association re-use is controlled by matching the NLI provided in a
   GIMPS message with those associated with existing associations.  This



Schulzrinne & Hancock    Expires November 18, 2005             [Page 27]

Internet-Draft                    GIMPS                         May 2005


   can be done on receiving either a GIMPS-Query or GIMPS-Response (the
   former is more likely):

   o  If there is a perfect match to the NLI of an existing association,
      that association can be re-used (provided it has the appropriate
      properties in other respects).  This is indicated by sending the
      remaining messages in the handshake over that association.  This
      will only fail (i.e. lead to re-use of an association to the
      'wrong' node) if signaling nodes have colliding Peer-Identities,
      and one is reachable at the same Interface-Address as another.
      (This could be done by an on-path attacker.)

   o  In all other cases, the full handshake is executed in datagram
      mode as usual.  There are in fact four possibilities:

      1.  Nothing matches: this is clearly a new peer.

      2.  Only the Peer-Identity matches: this may be either a new
          interface on an existing peer, or a changed address mapping
          behind a NAT, or an attacker attempting to hijack the Peer-
          Identity.  These should be rare events, so the expense of a
          new association setup is acceptable.  If the authenticated
          peer identities match after association setup, the two
          Interface-Addresses may be bound to the association.

      3.  Only the Interface-Address matches: this is probably a new
          peer behind the same NAT as an existing one.  A new
          association setup is required.

      4.  The full NLI object matches: this is a degenerate case, where
          one node recognises an existing peer, but wishes to allow the
          option to set up a new association in any case (for example to
          create an association with different transport or security
          properties).


4.4.3  State Maintenance Procedures

   Refresh and expiration of all types of state is controlled by timers.

   Each item of routing state expires after a validity lifetime which is
   negotiated during the Query/Response/Confirm handshake.  The NLI
   object in the Query contains a proposal for the lifetime value, and
   the NLI in the Response contains the value the Responding node
   requires.  It is the responsibility of the Querying node to generate
   a GIMPS-Query message before this timer expires, if it believes that
   the flow is still active; otherwise, the Responding node may delete
   the state.  Receipt of the message at the Responding node will



Schulzrinne & Hancock    Expires November 18, 2005             [Page 28]

Internet-Draft                    GIMPS                         May 2005


   refresh peer addressing state for one direction, and receipt of a
   GIMPS-Response at the querying node will refresh it for the other.

   Unneeded messaging associations can be torn down by either end.
   Whether an association is needed is a combination of two factors:

   o  local policy, which could take into account the cost of keeping
      the messaging association open, the level of past activity on the
      association, and the likelihood of future activity (e.g. if there
      is routing state still in place which might generate messages to
      use it).

   o  whether the peer still wants the association in place.  During
      messaging association setup, each node indicates its own MA-hold-
      time as part of the Stack-Configuration-Data; the node promises
      not to tear down the association if it has received traffic from
      its peer over that period.  A peer which has generated no traffic
      but still wants the association retained can use a special 'null'
      message (GIMPS-MA-Hello) to indicate the fact.

   Messaging associations can always be set up on demand, and messaging
   association status is not made directly visible outside the GIMPS
   layer.  Therefore, even if GIMPS tears down and later re-establishes
   a messaging association, signaling applications cannot distinguish
   this from the case where the association is kept permanently open.
   (To maintain the transport semantics described in Section 4.1, GIMPS
   must close transport connections carrying reliable messages
   gracefully or report an error condition, and must not open a new
   association for a given session and peer while messages on a previous
   association may still be outstanding.)





















Schulzrinne & Hancock    Expires November 18, 2005             [Page 29]

Internet-Draft                    GIMPS                         May 2005


5.  Message Formats and Transport

5.1  GIMPS Messages

   All GIMPS messages begin with a common header, which includes a
   version number, information about message type, signaling
   application, and additional control information.  The remainder of
   the message is encoded in an RSVP-style format, i.e., as a sequence
   of type-length-value (TLV) objects.  This subsection describes the
   possible GIMPS messages and their contents at a high level; a more
   detailed description of each information element is given in
   Section 5.2.

   The following gives the syntax of GIMPS messages in ABNF [3].

   GIMPS-Message: The main messages are either one of the stages in the
   3-way handshake, or a simple message carrying NSLP data.  Additional
   types are allocated for errors and messaging association keepalive.

       GIMPS-Message = GIMPS-Query / GIMPS-Response /
                       GIMPS-Confirm / GIMPS-Data /
                       GIMPS-Error / GIMPS-MA-Hello

   GIMPS-Query: A GIMPS-Query is always sent in datagram mode.  As well
   as the common header, it contains certain mandatory control objects,
   and may contain a signaling application payload.  A stack proposal
   and configuration data are mandatory if the message exchange relates
   to setup of a messaging association.

       GIMPS-Query = Common-Header
                     Message-Routing-Information
                     Session-Identification
                     Network-Layer-Information
                     Query-Cookie
                     [ Stack-Proposal Stack-Configuration-Data ]
                     [ NSLP-Data ]

   GIMPS-Response: A GIMPS-Response may be sent in datagram or
   connection mode (if a messaging association is being re-used).  It
   echoes the MRI, SID and Query-Cookie of the Query, and in D-mode
   carries its own Network-Layer-Information; if the message exchange
   relates to setup of a messaging association (which can only take
   place in datagram mode), a Responder cookie is mandatory, as is its
   own stack proposal and configuration data.







Schulzrinne & Hancock    Expires November 18, 2005             [Page 30]

Internet-Draft                    GIMPS                         May 2005


       GIMPS-Response = Common-Header
                        Message-Routing-Information
                        Session-Identification
                        [ Network-Layer-Information ]
                        Query-Cookie
                        [ Responder-Cookie
                          [ Stack-Proposal Stack-Configuration-Data ] ]
                        [ NSLP-Data ]

   GIMPS-Confirm: A GIMPS-Confirm may be sent in datagram or connection
   mode (if a messaging association has been re-used).  It echoes the
   MRI, SID and Responder-Cookie of the Response; if the message
   exchange relates to setup of a new messaging association or reuse of
   an existing one (which can only take place in connection mode), the
   message must also echo the Stack-Proposal from the GIMPS-Response so
   it can be verified that this has not been tampered with.

       GIMPS-Confirm = Common-Header
                       Message-Routing-Information
                       Session-Identification
                       Network-Layer-Information
                       Responder-Cookie
                       [ Stack-Proposal ]
                       [ NSLP-Data ]

   GIMPS-Data: A plain data message contains no control objects, but
   only the MRI and SID associated with the NSLP data being transferred.
   Network-Layer-Information is only carried in the datagram mode case.

       GIMPS-Data = Common-Header
                    Message-Routing-Information
                    Session-Identification
                    [ Network-Layer-Information ]
                    NSLP-Data

   GIMPS-Error: A GIMPS-Error message reports a problem determined at
   the GIMPS level.  (Errors generated by signalling applications are
   reported in NSLP-Data payloads and are not treated specially by
   GIMPS.)  The message includes the MRI and SID of the message that
   caused the error (if these can be determined), and Network-Layer-
   Information if the GIMPS-Error is being sent in D-Mode.

       GIMPS-Error = Common-Header
                     [ Message-Routing-Information ]
                     [ Session-Identification ]
                     [ Network-Layer-Information ]
                     GIMPS-Error-Data




Schulzrinne & Hancock    Expires November 18, 2005             [Page 31]

Internet-Draft                    GIMPS                         May 2005


   GIMPS-MA-Hello: This message can be sent only in C-Mode to indicate
   that a node wishes to keep a messaging association open.  It contains
   only the common header, with a null NSLPID.  A flag can be set in the
   Common-Header to indicate that a reply is requested, thus allowing a
   node to test the liveness of the peer.

       GIMPS-MA-Hello = Common-Header


5.2  Information Elements

   This section describes the content of the various information
   elements that can be present in each GIMPS message, both the common
   header, and the individual TLVs.  The bit patterns are provided in
   Appendix C.

5.2.1  The Common Header

   Each message begins with a fixed format common header, which contains
   the following information:

   Version: The version number of the GIMPS protocol.

   Length: The number of 32 bit words in the message following the
      common header.

   Signaling application identifier (NSLPID): This describes the
      specific signaling application, such as resource reservation or
      firewall control.

   GIMPS hop counter: A hop counter to prevent a message from looping
      indefinitely.

   Message type: The message type (Query, Response, etc.)

   Source addressing mode: A flag to indicate whether the IP source
      address of the message was set to be the signaling source address,
      or whether it was derived from the message routing information in
      the payload.

   Response requested: A flag to indicate that a message should be sent
      in response to this message.


5.2.2  TLV Objects

   All data following the common header is encoded as a sequence of
   type-length-value objects.  Currently, each object can occur at most



Schulzrinne & Hancock    Expires November 18, 2005             [Page 32]

Internet-Draft                    GIMPS                         May 2005


   once; the set of required and permitted objects is determined by the
   message type encapsulation.  The ABNF given above fixes the order of
   objects within a message.

   Message-Routing-Information (MRI): Information sufficient to define
      how the signaling message should be routed through the network.

       Message-Routing-Information = message-routing-method
                                     method-specific-information

      The format of the method-specific-information depends on the
      message-routing-method requested by the signaling application.
      The MRI is essentially a read only object for GIMPS processing.
      It is set by the NSLP in the message sender and used by GIMPS to
      select the message addressing, but not otherwise modified.

   Session-Identification (SID): The GIMPS session identifier is a long,
      cryptographically random identifier chosen by the node which
      originates the signaling exchange.  See Section 3.4.

   Network-Layer-Information: This object carries information about the
      network layer attributes of the node sending the message,
      including data related to the management of routing state.  This
      includes a peer identity and IP address for the sending node.  It
      also includes IP TTL information to allow the hop count between
      GIMPS peers to be measured and reported, and a validity time for
      the routing state.

       Network-Layer-Information = peer-identity
                                   interface-address
                                   RS-validity-time
                                   IP-TTL

      The peer-identity and interface-address are used for matching
      existing associations, as discussed in Section 4.4.2.  Any
      technique may be used to generate the peer-identity, so long as it
      is stable.  The interface-address should be a routable address
      where the sending node can be reached over UDP or messaging
      association protocols.  Where this object is used in a GIMPS-
      Query, the interface-address should specifically be set to the
      address of the interface that will be used for the outbound flow,
      to allow its use in route change handling, see Section 7.1.  The
      use of the RS-validity-time field is described in Section 4.4.3.

      The setting and interpretation of the IP-TTL field depends on the
      message direction (as determined from the MRI) and encapsulation.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 33]

Internet-Draft                    GIMPS                         May 2005


      *  If the message is downstream, the IP-TTL is set to the TTL that
         will be set in the IP header for the message (if this can be
         determined), or else 0.

      *  On receiving a downstream message in datagram mode, the IP-TTL
         is compared to the TTL in the IP header, and the result is
         stored as the IP-hop-count-to-peer for the upstream peer in the
         routing state table for that flow.  Otherwise, the field is
         ignored.

      *  If the message is upstream, the IP-TTL is set to the value of
         the IP-hop-count-to-peer stored in the routing state table, or
         0 if there is no value yet stored.

      *  On receiving an upstream message, the IP-TTL is stored as the
         IP-hop-count-to-peer for the downstream peer.

      In all cases, the TTL value reported to signaling applications is
      the one stored with the routing state for that flow, after it has
      been updated (if appropriate) from processing the message in
      question.

   Stack-Proposal: This field contains information about which
      combinations of transport and security protocols are proposed for
      use in messaging associations, and is also discussed further in
      Section 5.6.

       Stack-Proposal = *stack-profile

       stack-profile = *protocol-layer

      Each protocol-layer field identifies a protocol with a unique tag;
      any address-related (mutable) information associated with the
      protocol will be carried in a higher-layer-addressing field in the
      Stack-Configuration-Data TLV (see below).

   Stack-Configuration-Data: This object carries information about the
      overall configuration of a messaging association.

       Stack-Configuration-Data = MA-hold-time
                                  *higher-layer-addressing

      The MA-hold-time field indicates how long a node will hold open an
      inactive association; see Section 4.4.3 for more discussion.  The
      higher-layer-addressing fields give the configuration of the
      protocols to be used for new messaging associations, and they are
      described in more detail in Section 5.6.




Schulzrinne & Hancock    Expires November 18, 2005             [Page 34]

Internet-Draft                    GIMPS                         May 2005


   Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a
      GIMPS-Query message and must be echoed in a GIMPS-Response; a
      Response-Cookie is optional in a GIMPS-Response message, and if
      present must be echoed in the following GIMPS-Confirm message.
      Cookies are variable length (chosen by the cookie generator) and
      need to be designed so that a node can determine the validity of a
      cookie without keeping state.  See Section 8.5 for further details
      on requirements and mechanisms for cookie generation.

   NSLP-Data: The NSLP payload to be delivered to the signaling
      application.  GIMPS does not interpret the payload content.


5.3  Datagram Mode Transport

   This section describes the various encapsulation options for datagram
   mode messages.  Although there are several variant possibilities,
   depending on message type, message routing method, and local policy,
   the general design principle is that the sole purpose of the
   encapsulation is to ensure that the message is delivered to or
   intercepted at the correct peer.  Beyond that, minimal significance
   is attached to the type of encapsulation or the values of addresses
   or ports used for it.  This allows new options to be developed in the
   future to handle particular deployment requirements without modifying
   the overall protocol specification.

5.3.1  Normal Encapsulation

   Normal encapsulation is used for all datagram mode messages where the
   signaling peer is already known from previous signaling.  This
   includes Response and Confirm messages, and Data messages except if
   these are being sent without using local routing state.  Normal
   encapsulation is simple: the complete set of GIMPS payloads is
   concatenated together with the common header, and placed in the data
   field of a UDP datagram.  UDP checksums should be enabled.  The
   message is IP addressed directly to the adjacent peer; the UDP port
   numbering should be compatible with that used on Query messages (see
   below), that is, the same for messages in the same direction and
   swapped otherwise.

5.3.2  Query Encapsulation

   Query encapsulation is used for messages where no routing state is
   available or where the routing state is being refreshed, in
   particular for GIMPS-Query messages.  Query encapsulation is similar
   to normal encapsulation, with changes in IP address selection, IP
   options, and a defined method for selecting UDP ports.




Schulzrinne & Hancock    Expires November 18, 2005             [Page 35]

Internet-Draft                    GIMPS                         May 2005


   In general, the IP addresses are derived from information in the MRI;
   the exact rules depend on the message routing method.  In addition,
   the IP header is given a Router Alert Option to assist the peer in
   intercepting the message depending on the NSLPID.  Router alert
   option value-field setting is discussed in Section 5.3.3.

   The source UDP port is selected by the message sender as the port at
   which it is prepared to receive UDP messages in reply, and a
   destination UDP port should be allocated by IANA.  Note that GIMPS
   may send messages addressed as {flow sender, flow receiver} which
   could make their way to the flow receiver even if that receiver were
   GIMPS-unaware.  This should be rejected (with an ICMP message) rather
   than delivered to the user application (which would be unable to use
   the source address to identify it as not being part of the normal
   data flow).  Therefore, a "well-known" port is required.

5.3.3  Intermediate Node Bypass and Router Alert Values

   We assume that the primary mechanism for intercepting messages is the
   use of the RAO.  The RAO contains a 16 bit value field, within which
   35 values have currently been assigned by IANA.  This section
   discusses the technical considerations to be taken into account when
   assigning values for use by GIMPS.

   The basic goal is to optimise protocol processing, i.e. to minimise
   the amount of slow-path processing that nodes have to carry out for
   messages they are not actually interested in.  There are two basic
   reasons why a GIMPS node might wish to ignore a message:

   o  because it is for a signaling application that the node does not
      process;

   o  because even though the signaling application is present on the
      node, the interface on which the message arrives is only
      processing signaling messages at the aggregate level and not for
      individual flows (compare [15]).

   Conversely, note that a node might wish to process a number of
   different signaling applications.

   Some or all of this information can be encoded in the RAO value
   field, which then allows messages to be filtered on the fast path.
   There is a tradeoff between two approaches here, whose evaluation
   depends on whether the processing node is specialised or general
   purpose:






Schulzrinne & Hancock    Expires November 18, 2005             [Page 36]

Internet-Draft                    GIMPS                         May 2005


   Fine-Grained: The signaling application (including specific version)
      and aggregation level are directly identified in the RAO value.  A
      specialised node which handles only a single NSLP can efficiently
      ignore all other messages; a general purpose node may have to
      match the RAO value in a message against a long list of possible
      values.

   Coarse-Grained: IANA allocates RAO values for 'popular' applications
      or groups of applications (such as 'All QoS Signaling
      Applications').  This speeds up the processing in a general
      purpose node, but a specialised node may have to carry out further
      processing on the GIMPS common header to identify the precise
      messages it needs to consider.

   These considerations imply that the RAO value should not be tied
   directly to the NSLPID, but should be selected for the application on
   broader considerations of likely deployment scenarios.  Note that the
   exact NSLP is given in the GIMPS common header, and some
   implementations may still be able to process it on the fast path.
   The semantics of the node dropping out of the signaling path are the
   same however the filtering is done (see Section 4.3.4).

   There is a special consideration in the case of the aggregation
   level.  In this case, whether a message should be processed depends
   on the network region it is in (specifically, the link it is on).
   There are then two basic possibilities:

   1.  All routers have essentially the same algorithm for which
       messages they process, i.e. all messages at aggregation level 0.
       However, messages have their aggregation level incremented on
       entry to an aggregation region and decremented on exit.

   2.  Router interfaces are configured to process messages only above a
       certain aggregation level and ignore all others.  The aggregation
       level of a message is never changed; signaling messages for end
       to end flows have level 0, but signaling messages for aggregates
       are generated with a higher level.

   The first technique requires aggregating/deaggregating routers to be
   configured with which of their interfaces lie at which aggregation
   level, and also requires consistent message rewriting at these
   boundaries.  The second technique eliminates the rewriting, but
   requires interior routers to be configured also.  It is not clear
   what the right trade-off between these options is.

5.3.4  Retransmission and Rate-Control

   Datagram mode uses UDP, and hence has no automatic reliability or



Schulzrinne & Hancock    Expires November 18, 2005             [Page 37]

Internet-Draft                    GIMPS                         May 2005


   congestion control capabilities.  Signaling applications requiring
   reliability should be serviced using C-mode, which should also carry
   the bulk of signaling traffic.  However, some form of messaging
   reliability is required for the GIMPS control messages themselves, as
   is rate control to handle retransmissions and also bursts of
   unreliable signaling or state setup requests from the signaling
   applications.

   GIMPS-Query messages which do not receive GIMPS-Responses should be
   retransmitted with a binary exponential backoff, with an initial
   timeout of T1 up to a maximum of T2 seconds.  The values of T1 and T2
   may be implementation defined; default values are for further study.
   The value of T1 may be increased on long latency links.  Note that
   GIMPS-Queries may go unanswered either because of message loss, or
   because there is no reachable GIMPS peer.  Therefore, implementations
   must trade off reliability (large T2) against promptness of error
   feedback to applications (small T2).  GIMPS-Responses should always
   be sent promptly to avoid spurious retransmissions.  Retransmitted
   GIMPS-Queries should use different Query-Cookie values and will
   therefore elicit different GIMPS-Responses.  If either message
   carries NSLP data, it may be delivered multiple times to the
   signaling application.

   Other datagram mode messages are not generally retransmitted.  GIMPS-
   Responses do not need reliability; if they are lost, the initiating
   Query will eventually be resent.

   The case of a lost GIMPS-Confirm is more subtle.  Notionally, we can
   distinguish between two cases:

   1.  Where the Responding node is already prepared to store per-flow
       state after receiving a single (Query) message.  This would
       include any cases where the node has NSLP data queued to send.
       Here, it is reasonable for the protocol to demand that the
       Responding node runs a retransmission timer to resend the
       Response message until a Confirm is received, since the node is
       already managing state for that flow.  The problem of an
       amplification attack stimulated by a malicious Query should be
       handled by requiring the cookie mechanism to enable the node
       receiving the Response to discard it efficiently if it does not
       match a previously sent Query.

   2.  where the responding node is not prepared to store per-flow state
       until receiving a properly formed Confirm message.

   In case (2), a retransmission timer should not be required.  However,
   we can assume that the next signaling message will be in the
   direction Querying Node -> Responding Node (if there is no 'next



Schulzrinne & Hancock    Expires November 18, 2005             [Page 38]

Internet-Draft                    GIMPS                         May 2005


   signaling message' the fact that the Confirm has been lost is moot).
   In this case, the responding node will start to receive messages at
   the GIMPS level for a MRI/NSLP combination for which there is no
   stored routing state (since this state is only created on receipt of
   a Confirm).

   The consequence of this is that the error condition is detected at
   the Responding node when such a message arrives, without the need for
   a specific timer.  Recovery requires a Confirm to be transmitted and
   successfully received.  The mechanism to cause this is for the
   Responding node to reject the incoming message with an error "No
   Routing State Exists" back to the Querying node, which interprets
   this as caused by a lost Confirm; the Querying node needs to be able
   to regenerate the Confirm purely from local state (e.g. in particular
   it needs to remember a valid Responder Cookie).

   The basic rate-control requirements for datagram mode traffic are
   deliberately minimal.  A single rate limiter applies to all traffic
   (for all interfaces and message types).  It applies to
   retransmissions as well as new messages, although an implementation
   may choose to prioritise one over the other.  When the rate limiter
   is imposed, datagram mode messages are queued until transmission is
   re-enabled, or an error condition may be indicated back to local
   signaling applications.  The rate limiting mechanism is
   implementation defined, but it is recommended that a token bucket
   limiter as described in [8] should be used.

5.4  Connection Mode Transport

   Encapsulation in connection mode is more complex, because of the
   variation in available transport functionality.  This issue is
   treated in Section 5.4.1.  The actual encapsulation is given in
   Section 5.4.2.

5.4.1  Choice of Transport Protocol

   It is a general requirement of the NTLP defined in [20] that it
   should be able to support bundling (of small messages), fragmentation
   (of large messages), and message boundary delineation.  Not all
   transport protocols natively support all these features.

   SCTP [6] satisfies all requirements.

   DCCP [7] is message based but does not provide bundling or
      fragmentation.  Bundling can be carried out by the GIMPS layer
      sending multiple messages in a single datagram; because the common
      header includes length information (number of TLVs), the message
      boundaries within the datagram can be discovered during parsing.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 39]

Internet-Draft                    GIMPS                         May 2005


      Fragmentation of GIMPS messages over multiple datagrams should be
      avoided, because of amplification of message loss rates that this
      would cause.

   TCP provides both bundling and fragmentation, but not message
      boundaries.  However, the length information in the common header
      allows the message boundary to be discovered during parsing.

   The bundling together of small messages is either built into the
   transport protocol or can be carried out by the GIMPS layer during
   message construction.  Either way, two approaches can be
   distinguished:

   1.  As messages arrive for transmission they are gathered into a
       bundle until a size limit is reached or a timeout expires (cf.
       the Nagle algorithm of TCP or similar optional functionality in
       SCTP).  This provides maximal efficiency at the cost of some
       latency.

   2.  Messages awaiting transmission are gathered together while the
       node is not allowed to send them (e.g. because it is congestion
       controlled).

   The second type of bundling is always appropriate.  For GIMPS, the
   first type is inappropriate for 'trigger' (i.e. state-changing)
   messages, but may be appropriate for refresh messages.  These
   distinctions are known only to the signaling applications, but could
   be indicated (as an implementation issue) by setting the priority
   transfer attribute.

   It can be seen that all of these protocol options can be supported by
   the basic GIMPS message format already presented.  GIMPS messages
   requiring fragmentation must be carried using a reliable transport
   protocol, TCP or SCTP.  This specification defines only the use of
   TCP, but it can be seen that the other possibilities could be
   included without additional work on message formatting.

5.4.2  Encapsulation Format

   The GIMPS message, consisting of common header and TLVs, is carried
   directly in the transport protocol (possibly incorporating transport
   layer security protection).  Further messages can be carried in a
   continuous stream (for TCP), or up to the next transport layer
   message boundary (for SCTP/DCCP/UDP).  This situation is shown in
   Figure 5.






Schulzrinne & Hancock    Expires November 18, 2005             [Page 40]

Internet-Draft                    GIMPS                         May 2005


      +---------------------------------------------+
      |                  L2 Header                  |
      +---------------------------------------------+
      |                  IP Header                  |   ^
      |      Source address = signaling source      |   ^
      | Destination address = signaling destination |   .
      +---------------------------------------------+   .
      |                  L4 Header                  |   . ^
      |     (Standard TCP/SCTP/DCCP/UDP header)     |   . ^
      +---------------------------------------------+   . .
      |                GIMPS Message                |   . . ^
      | (Common header and TLVs as in section 5.1)  |   . . ^  Scope of
      +---------------------------------------------+   . . .  security
      | Additional GIMPS messages, each with its    |   . . . protection
      | own common header, either as a continuous   |   . . . (depending
      |   stream, or continuing to the next L4      |   . . . on channel
      .             message boundary                .   . . .  security
      .                                             .   V V V  mechanism
      .                                             .   V V V   in use)

                  Figure 5: Connection Mode Encapsulation


5.5  Message Type/Encapsulation Relationships

   GIMPS has four message types (Query/Response/Confirm/Data) and three
   possible encapsulation methods (D-Mode Normal/D-Mode Query/C-Mode).
   For information, the allowed combinations of message type and
   encapsulation are given in the table below.  However, it should be
   noted that the processing of the message at the receiver is not
   directly affected by the encapsulation method used, with the
   exception that the decapsulation process may provide additional
   information (e.g. translated addresses or IP hop count) which is used
   in the subsequent message processing.  The selection of the
   encapsulation method is a matter for the message sender.

   +----------------+----------------+----------------+----------------+
   |     Message    |  D-Mode Normal |  D-Mode Query  |     C-Mode     |
   +----------------+----------------+----------------+----------------+
   |   GIMPS-Query  |      Never     |     Always     |      Never     |
   |                |                |                |                |
   | GIMPS-Response |    Unless a    |      Never     | If a messaging |
   |                |    messaging   |                | association is |
   |                | association is |                |  being re-used |
   |                |  being re-used |                |                |
   |                |                |                |                |





Schulzrinne & Hancock    Expires November 18, 2005             [Page 41]

Internet-Draft                    GIMPS                         May 2005


   |  GIMPS-Confirm |    Unless a    |      Never     | If a messaging |
   |                |    messaging   |                |   association  |
   |                |   association  |                |  has been set  |
   |                |  has been set  |                | up or is being |
   |                | up or is being |                |     re-used    |
   |                |     re-used    |                |                |
   |                |                |                |                |
   |   GIMPS-Data   |   If routing   |  If no routing | If a messaging |
   |                |  state exists  |  state exists  |   association  |
   |                |  for the flow  |   and the MRI  |     exists     |
   |                |     but no     | can be used to |                |
   |                |   appropriate  |   derive the   |                |
   |                |    messaging   |      query     |                |
   |                |   association  |  encapsulation |                |
   +----------------+----------------+----------------+----------------+


5.6  Messaging Association Negotiation

5.6.1  Overview

   A key attribute of GIMPS is that it is flexible in its ability to use
   existing transport and security protocols.  Different transport
   protocols may have performance attributes appropriate to different
   environments; different security protocols may fit appropriately with
   different authentication infrastructures.  Even given an initial
   default mandatory protocol set for GIMPS, the need to support new
   protocols in the future cannot be ruled out, and secure feature
   negotation cannot be added to an existing protocol in a backwards-
   compatible way.  Therefore, some sort of negotiation capability is
   required.

   Protocol negotiation is carried out in GIMPS-Query/Response messages,
   using Stack-Proposal and Stack-Configuration-Data objects.  If a new
   messaging association is required it is then set up, followed by a
   GIMPS-Confirm.  Messaging association re-use is achieved by short-
   circuiting this exchange by sending the GIMPS-Response or GIMPS-
   Confirm messages on an existing association (Section 4.4.2); whether
   to do this is a matter of local policy.  If multiple associations
   exist, it is a matter of local policy how to distribute messages over
   them, subject to respecting the transfer attributes requested for
   each message.

   The end result of the negotiation is a messaging association which is
   a stack of protocols.  Every possible protocol has the following
   attributes:





Schulzrinne & Hancock    Expires November 18, 2005             [Page 42]

Internet-Draft                    GIMPS                         May 2005


   o  MA-Protocol-ID, a 1-byte IANA assigned value.

   o  A specification of the (non-negotiable) policies about how the
      protocol should be used (for example, in which direction a
      connection should be opened).

   o  Formats for carrying the protocol addressing and other
      configuration information in higher-layer-addressing information
      elements in the Stack-Configuration-Data object.  There are
      different formats depending on whether the information is carried
      in the Query or Response (the object for a Confirm echoes the
      Response).

   A Stack-Proposal object is simply a list of profiles; each profile is
   a sequence of MA-Protocol-IDs.  A Stack-Proposal is generally
   accompanied by a Stack-Configuration-Data object which carries a
   higher-layer-addressing information element for every protocol listed
   in the Stack-Proposal.  A node generating a Stack-Configuration-Data
   object is committed to honouring the implied protocol configuration;
   in particular, it must be immediately prepared to accept incoming
   datagrams or connections at the protocol/port combinations
   advertised.  However, the object contents should be retained only for
   the duration of the Query/Response exchange and any following
   association setup and afterwards discarded.  (They may become invalid
   because of expired bindings at intermediate NATs, or because the
   advertising node is using agile ports.)

   A GIMPS-Query requesting association setup always contains a Stack-
   Proposal and Stack-Configuration-Data object, and unless re-use
   occurs, the GIMPS-Response does so also.  For a GIMPS-Response, the
   Stack-Proposal must be invariant for the combination of outgoing
   interface and NSLPID (it must not depend on the GIMPS-Query).  Once
   the messaging association is set up, the querying node repeats the
   responder's Stack-Proposal over it in the GIMPS-Confirm.  The
   responding node can verify this to ensure that no bidding-down attack
   has occurred.

5.6.2  Protocol Definition: Forwards-TCP

   This defines a basic configuration for the use of TCP between peers.
   Support for this protocol is mandatory; associations using it can
   carry messages with the transfer attribute Reliable=True.  The
   connection is opened in the forwards direction, from the querying
   node, towards the responder at a previously advertised port.  The
   higher-layer-addressing formats are:

   o  downstream: no additional data (just the MA-Protocol-ID)




Schulzrinne & Hancock    Expires November 18, 2005             [Page 43]

Internet-Draft                    GIMPS                         May 2005


   o  upstream: 2 byte port number at which the connection will be
      accepted.


5.6.3  Additional Protocol Options

   It is expected that the base GIMPS specification will define a single
   mandatory protocol for channel security (one of IKE/IPsec or TLS).
   Further protocols or configurations could be defined in the future
   for additional performance or flexibility.  Examples are:

   o  SCTP or DCCP as alternatives to TCP, with essentially the same
      configuration.

   o  SigComp [17] for message compression.

   o  ssh [25] or HIP/IPsec [26] for channel security.

   o  Alternative modes of TCP operation, for example where it is set up
      from the responder to the querying node.


5.7  Specific Message Routing Methods

   Each message routing method (see Section 3.3) requires the definition
   of the format of the message routing information (MRI) and Query-
   encapsulation rules.  These are given in the following subsections
   for the various possible message routing methods.

5.7.1  The Path-Coupled MRM

5.7.1.1  Message Routing Information

   For the path-coupled MRM, this is just the Flow Identifier as in
   [20].  Minimally, this could just be the flow destination address;
   however, to account for policy based forwarding and other issues a
   more complete set of header fields should be used (see Section 7.2
   and Section 7.3 for further discussion).

       Flow-Identifier = network-layer-version
                         source-address prefix-length
                         destination-address prefix-length
                         IP-protocol
                         traffic-class
                         [ flow-label ]
                         [ ipsec-SPI / L4-ports]

   Additional control information defines whether the flow-label, SPI



Schulzrinne & Hancock    Expires November 18, 2005             [Page 44]

Internet-Draft                    GIMPS                         May 2005


   and port information are present, the direction of the message
   relative to this flow, and whether the IP-protocol and traffic-class
   fields should be interpreted as significant.

5.7.1.2  Query Encapsulation for the Path-Coupled Message Routing Method

   Where the signalling message is travelling in the same ('downstream')
   direction as the flow defined by the MRI, the IP addressing for Query
   messages is as follows:

   o  The destination address MUST be the flow destination address as
      given in the MRI of the message payload.

   o  By default, the source address is the flow source address, again
      from the MRI.  This provides the best likelihood that the message
      will be correctly routed through any region which performs per-
      packet policy-based forwarding or load balancing which takes the
      source address into account.  However, there may be circumstances
      where the use of the signaling source address is preferable,
      specifically:

      *  In order to receive ICMP error messages about the Query message
         (such as unreachable port or address).  If these are delivered
         to the flow source rather than the signaling source, it will be
         very difficult for the querying node to detect that it is the
         last GIMPS node on the path.

      *  In order to attempt to run GIMPS through an unmodified NAT,
         which will only process and translate IP addresses in the IP
         header.

      Because of these considerations, use of the signaling source
      address is allowed as an option, with use based on local policy.
      A node SHOULD use the flow source address for initial Query
      messages, but MAY transition to the signaling source address for
      retransmissions or as a matter of static configuration (e.g. if a
      NAT is known to be in the path out of a certain interface).  A
      flag in the common header tells the message receiver which option
      was used.

   It is vital that the Query message mimics the actual data flow as
   closely as possible, since this is the basis of how the signaling
   message is attached to the data path.  To this end, GIMPS may set the
   traffic class and (for IPv6) flow label to match the values in the
   MRI if this would be needed to ensure correct routing.

   Any message sent in datagram mode should be below a conservative
   estimate of the path MTU (e.g. 512 bytes).  It is possible that



Schulzrinne & Hancock    Expires November 18, 2005             [Page 45]

Internet-Draft                    GIMPS                         May 2005


   fragmented datagrams including an RAO will not be correctly handled
   in the network, so the sender may set the DF (do not fragment) bit in
   the IPv4 header in order to detect that a message has encountered a
   link with an unusually low MTU.  In this case, it must use the
   signalling source address for the IP source address in order to
   receive the ICMP error.

   A GIMPS implementation may apply validation checks to the MRI, to
   reject Query messages that are being injected by nodes with no
   legitimate interest in the flow being signalled for.  In general, if
   the GIMPS node can detect that no flow could arrive over the same
   interface as the Query message, it should be rejected.  (Such checks
   apply only to messages with the query encapsulation, since only those
   messages are required to track the flow path.)  The main checks are
   that the IP version should match the version(s) used on that
   interface, and that the full range of source addresses (the source-
   address masked with its prefix-length) would pass ingress filtering
   checks.  In addition, the MRI destination-address can also be checked
   against the destination in the IP header.

   These encapsulation rules allow Query messages to be sent in the same
   direction as the flow, and hence allow routing state to be set up
   from the flow source towards the flow destination.  In some
   deployment scenarios (see Section 10.1 for further discussion), it is
   desirable and logically possible to set up routing state in the
   reverse direction.  Implementing this in the specification would
   require defining rules for encapsulating a Query message in the
   upstream direction.  Details are for further study.























Schulzrinne & Hancock    Expires November 18, 2005             [Page 46]

Internet-Draft                    GIMPS                         May 2005


6.  Formal Protocol Specification

   This section provides a more formal specification of the operation of
   GIMPS processing, in terms of rules for transitions between states of
   a set of communicating state machines within a node.  The content
   here is currently preliminary, and includes only the top-level
   outline and the state transition diagrams for the different state
   machiens.  In the future it will include message processing rules
   that should be applied for each event/state combination.

   Conceptually, the operation of GIMPS processing at a node may be seen
   as the cooperation of 4 types of state machine:

   1.  There is a top-level state machine which represents the node
       itself (Node-SM).  This is responsible for the processing of
       events which cannot be directed towards a more specific state
       machine, for example, inbound messages for which no per-flow
       routing state currently exists.  This machine exists permanently,
       and is responsible for creating 'per-flow' state machines to
       manage the operation of the GIMPS handshake and routing state
       maintenance procedures.

   2.  For each flow and signalling direction where the node is
       responsible for initiating the creation of routing state, there
       is an instance of a Query-Node Routing state machine (Query-SM).
       This machine sends Query and Confirm messages and waits for
       Responses, according to the requirements from locally generated
       API commands or timer processing (e.g. message repetition or
       routing state refresh).

   3.  For each flow and signalling direction where the node has
       accepted the creation of routing state by a peer, there is an
       instance of a Responding-Node Routing state machine
       (Response-SM).  This machine is responsible for managing the
       status of the routing state for that flow.  In some cases, it is
       also responsible for retransmission of Response messages;
       however, in many cases, the generation of Response messages is
       handled by the Node-SM, and a Response-SM is not even created for
       a flow until a properly formatted Confirm has been accepted.

   4.  Messaging assocations have their own lifecycle, represented by
       MA-SM, from when they are first created (in an 'incomplete'
       state, listening for an inbound connection or waiting for
       outbound connections to complete), to when they are active and
       available for use.

   Note that, apart from the fact that the various machines can be
   created and destroyed by each other, there is almost no interaction



Schulzrinne & Hancock    Expires November 18, 2005             [Page 47]

Internet-Draft                    GIMPS                         May 2005


   between them.  The machines for different flows do not interact; the
   Query-SM and Response-SM for a single flow and signalling direction
   do not interact.  That is, the Response-SM which accepts the creation
   of routing state for a flow on one interface has no direct
   interaction with the Query-SM which sets up routing state on the next
   interface along the path.  This interaction is mediated through the
   NSLP.

   The state transition diagrams use the following terminology for event
   naming:

   o  rx_ = a message received event.  The rest of the event name is the
      name of the message

   o  tg_ = a trigger event, either from the API or from another
      internal state machine.

   o  to_ = a timeout event.

   o  er_ = an error indication event.  This may be filtered back to the
      NSLP.


6.1  Node Processing

   The Node level state machine is responsible for processing events for
   which no more appropriate messaging association state or routing
   state exists.  Its structure is trivial: there is a single state
   ('Idle'); all events cause a transition back to Idle.  Some events
   cause the creation of other state machines.





















Schulzrinne & Hancock    Expires November 18, 2005             [Page 48]

Internet-Draft                    GIMPS                         May 2005


6.2  Query Node Processing

           tg_Initialise_QNode   +-----+
        -------------------------|Birth|
       |                         +-----+
       |
       |
       |
       |                                                    tg_Data_Rcvd
       |      tg_NSLP_Data                               || tg_NSLP_Data
       |        --------                                     --------
       |       |        V                                   |        V
       |       |        V                                   |        V
       |      +----------+                                 +-----------+
        ---->>| Awaiting |       tg_Response_Rcvd          |Established|
        ------| Response |------------------------------>> |           |
       |      +----------+                                 +-----------+
       |       ^        |                                      ^   |
       |       ^        |                                      ^   |
       |        --------                                       |   |
       |       to_No_Resp                                      |   |
       |    [!nResp_reached]      tg_Data_Rcvd                 |   |
       |                       || tg_NSLP_Data                 |   |
       |                           --------                    |   |
       |to_No_Resp                |        V                   |   |
       |[nResp_reached]           |        V                   |   |
       V                         +-----------+ tg_Response_Rcvd|   |
       V                         |  Awaiting |-----------------    |
    +-----+                      |  Refresh  |<<-------------------
    |Death|                      +-----------+    to_Refresh_QNode
    +-----+
       ^
       ^
       |
       |to_Expire_QNode
       |(from all states)

                    Figure 6: Query Node State Machine













Schulzrinne & Hancock    Expires November 18, 2005             [Page 49]

Internet-Draft                    GIMPS                         May 2005


6.3  Responder Node Processing

              tg_Query_Rcvd                   tg_Query_Rcvd
            [confirmRequired]    +-----+    [!confirmRequired]
        -------------------------|Birth|---------------------------
       |                         +-----+                            |
       |                            |                               |
       |                            |      tg_Confirm_Rcvd          |
       |                             --------------------------     |
       |                                                         |  |
       |                                                         |  |
       |                                           tg_Data_Rcvd  |  |
       |      tg_NSLP_Data                      || tg_NSLP_Data  |  |
       |        --------                          ------------   |  |
       |       |        V                        |            V  V  V
       |       |        V                        |            V  V  V
       |      +----------+                       |         +-----------+
        ---->>| Awaiting |  tg_Confirm_Rcvd       ---------|Established|
        ------| Confirm  |------------------------------>> |           |
       |      +----------+                                 +-----------+
       |       ^        |
       |       ^        |
       |        --------
       |       to_No_Conf
       |    [!nConf_reached]
       |
       |
       |                         +-----+
        ----------------------->>|Death|<<-----------------------
              to_No_Resp         +-----+       to_Expire_RNode
            [nConf_reached]                   (from all states)

                  Figure 7: Responder Node State Machine


















Schulzrinne & Hancock    Expires November 18, 2005             [Page 50]

Internet-Draft                    GIMPS                         May 2005


6.4  Messaging Association Processing


         tg_Initialise_MA       +-----+
    ----------------------------|Birth|
   |                            +-----+
   |
   |                                                  tg_Send_Message
   |      tg_Send_Message                              || rx_Message
   |        --------                                     --------
   |       |        V                                   |        V
   |       |        V                                   |        V
   |      +----------+                                 +-----------+
    ---->>| Awaiting |         tg_Connect              | Connected |
    ------|Connection|------------------------------>> |           |
   |      +----------+                                 +-----------+
   |                                                         |
   |                                                         |
   |                                                         |
   |                                                         |
   |                                        to_Inactive_MA   |
   |       er_MA_Connect        +-----+    || er_MA_Failure  |
    -------------------------->>|Death|<<--------------------
                                +-----+

               Figure 8: Messaging Association State Machine

























Schulzrinne & Hancock    Expires November 18, 2005             [Page 51]

Internet-Draft                    GIMPS                         May 2005


7.  Advanced Protocol Features

7.1  Route Changes and Local Repair

7.1.1  Introduction

   When re-routing takes place in the network, GIMPS and signaling
   application state needs to be updated for all flows whose paths have
   changed.  The updates to signaling application state are usually
   signaling application dependent: for example, if the path
   characteristics have actually changed, simply moving state from the
   old to the new path is not sufficient.  Therefore, GIMPS cannot carry
   out the complete path update processing.  Its responsibilities are to
   detect the route change, update its own routing state consistently,
   and inform interested signaling applications at affected nodes.

   Route change management is complicated by the distributed nature of
   the problem.  Consider the re-routing event shown in Figure 9.  An
   external observer can tell that the main responsibility for
   controlling the updates will probably lie with nodes A and E;
   however, D1 is best placed to detect the event quickly at the GIMPS
   level, and B1 and C1 could also attempt to initiate the repair.

   On the assumption that NSLPs are soft-state based and operate end to
   end, and because GIMPS also periodically updates its picture of
   routing state, route changes will eventually be repaired
   automatically.  However, especially if NSLP refresh times are
   extended to reduce signaling load, the duration of inconsistent state
   may be very long indeed.  Therefore, GIMPS includes logic to deliver
   prompt notifications to NSLPs, to allow NSLPs to carry out local
   repair if possible.




















Schulzrinne & Hancock    Expires November 18, 2005             [Page 52]

Internet-Draft                    GIMPS                         May 2005


                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
               x  +--+        +--+        +--+  x      Initial
              x  .|B1|_.......|C1|_.......|D1|   x     Configuration
             x  . +--+.      .+--+.      .+--+\.  x
            x  .       .    .      .    .       .  x
    >>xxxxxx  .         .  .        .  .         .  xxxxxx>>
         +-+ .           ..          ..           . +-+
    .....|A|/            ..          ..            .|E|_....
         +-+ .          .  .        .  .          . +-+
              .        .    .      .    .        .
               .      .      .    .      .      .
                . +--+        +--+        +--+ .
                 .|B2|_.......|C2|_.......|D2|/
                  +--+        +--+        +--+

                  +--+        +--+        +--+         Configuration
                 .|B1|........|C1|........|D1|         after failure
                . +--+       .+--+        +--+         of D1-E link
               .      \.    .     \.    ./
              .         .  .        .  .
         +-+ .           ..          ..             +-+
    .....|A|.            ..          ..            .|E|_....
         +-+\.          .  .        .  .          . +-+
    >>xxxxxx  .        .    .      .    .        .  xxxxxx>>
            x  .      .      .    .      .      .  x
             x  . +--+        +--+        +--+ .  x
              x  .|B2|_.......|C2|_.......|D2|/  x
               x  +--+        +--+        +--+  x
                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


               ........... = physical link topology

               >>xxxxxxx>> = flow direction

               _.......... = indicates outgoing link
                             for flow xxxxxx given
                             by local forwarding table

                       Figure 9: A Re-Routing Event


7.1.2  Route Change Detection

   There are two aspects to detecting a route change at a single node:

   o  Detecting that the path in the direction of the Query has (or may
      have) changed.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 53]

Internet-Draft                    GIMPS                         May 2005


   o  Detecting that the path in the direction of the Response has (or
      may have) changed (in which case the node may no longer be on the
      path at all).

   At a single node, these processes are largely independent, although
   clearly a change in the path in one direction at a node corresponds
   to a change in path in the opposite direction at its peer.  Note that
   there are two possible aspects of route change:

   Interface: The interface through which a flow leaves or enters a node
      may change.

   Peer: The adjacent peer may change.

   In general, a route change could include one or the other or both.
   (In theory it could include neither, although such changes are hard
   to detect and even harder to do anything useful about.)

   There are five mechanisms for a GIMPS node to detect that a route
   change has occurred, which are listed below.  They apply differently
   depending on whether the change is in the Query or Response
   direction, and these differences are summarised in the following
   table.

   Local Trigger: In trigger mode, a node finds out that the next hop
      has changed.  This is the RSVP trigger mechanism where some form
      of notification mechanism from the routing table to the protocol
      handler is assumed.  Clearly this only works if the routing change
      is local, not if the routing change happens somewhere a few
      routing hops away (including the case that the change happens at a
      GIMPS-unaware node).

   Extended Trigger: An extended trigger, where the node checks a link-
      state routing table to discover that the path has changed.  This
      makes certain assumptions on consistency of route computation (but
      you probably need to make those to avoid routing loops) and only
      works within a single area for OSPF and similar link-state
      protocols.  Where available, this offers the most accurate and
      expeditious indication of route changes, but requires more access
      to the routing internals than a typical OS may provide.

   GIMPS C-mode Monitoring: A node may find that C-mode packets are
      arriving (from either peer) with a different TTL or on a different
      interface.  This provides no direct information about the new flow
      path, but indicates that routing has changed and that rediscovery
      may be required.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 54]

Internet-Draft                    GIMPS                         May 2005


   Data Plane Monitoring: The signaling application on a node may detect
      a change in behaviour of the flow, such as TTL change, arrival on
      a different interface, or loss of the flow altogether.  The
      signaling application on the node is allowed to notify this
      information locally to GIMPS.

   GIMPS Probing: In probing mode, each GIMPS node periodically repeats
      the discovery (GIMPS-Query/GIMPS-Response) operation.  The
      querying node will discover the route change by a modification in
      the Network-Layer-Information in the GIMPS-Response.  This is
      similar to RSVP behavior, except that there is an extra degree of
      freedom since not every message needs to repeat the discovery,
      depending on the likely stability of routes.  All indications are
      that, leaving mobility aside, routes are stable for hours and
      days, so this may not be necessary on a 30-second interval,
      especially if the other techniques listed above are available.

   When these methods discover a route change in the Response direction,
   this cannot be handled directly by GIMPS at the detecting node, since
   route discovery proceeds only in the Query direction.  Therefore, to
   exploit these mechanisms, it must be possible for GIMPS to send a
   notification message to initiate this.  (This would be possible for
   example by setting an additional flag in the Common-Header of a
   message.)

   +----------------------+----------------------+---------------------+
   | Method               | Query direction      | Response direction  |
   +----------------------+----------------------+---------------------+
   | Local Trigger        | Discovers new        | Not applicable      |
   |                      | interface (and peer  |                     |
   |                      | if local)            |                     |
   |                      |                      |                     |
   | Extended Trigger     | Discovers new        | May determine that  |
   |                      | interface and may    | route from peer     |
   |                      | determine new peer   | will have changed   |
   |                      |                      |                     |
   | C-Mode Monitoring    | Provides hint that   | Provides hint that  |
   |                      | change has occurred  | change has occurred |
   |                      |                      |                     |
   | Data Plane           | Not applicable       | NSLP informs GIMPS  |
   | Monitoring           |                      | that a change may   |
   |                      |                      | have occurred       |
   |                      |                      |                     |
   | Probing              | Discovers changed    | Discovers changed   |
   |                      | Network-Layer-Inform | Network-Layer-Infor |
   |                      | ation in             | mation in           |
   |                      |  GIMPS-Response      |  GIMPS-Query        |
   +----------------------+----------------------+---------------------+



Schulzrinne & Hancock    Expires November 18, 2005             [Page 55]

Internet-Draft                    GIMPS                         May 2005


7.1.3  Local Repair

   Once a node has detected that a change may have occurred, there are
   three possible cases:

   1.  Only a change in the Response direction is indicated.  There is
       nothing that can be done locally; GIMPS must propagate a
       notification to its peer.

   2.  A Query direction change has been detected and a Response
       direction change cannot be ruled out.  Although some local repair
       may be appropriate, it is difficult to decide what, since the
       path change may actually have taken place remotely from the
       detecting node (so that this node is no longer on the path at
       all).

   3.  A Query direction change has been detected, but there is no
       change in the Responding direction.  In this case, the detecting
       node is the true crossover router, i.e. the point in the network
       where old and new paths diverge.  It is the correct node to
       initiate the local repair process.

   In case (3), i.e. at the crossover node, the local repair process is
   initiated by the GIMPS level as follows:

   o  GIMPS marks its routing state information for this flow as
      'invalid', unless the route change was actually detected by D-mode
      probing (in which case the new state has already been installed).

   o  GIMPS notifies the local NSLP that local repair is necessary.

   It is assumed that the second step will typically trigger the NSLP to
   generate a message, and the attempt to send it will stimulate a
   GIMPS-Query/Response.  This signaling application message will
   propagate, also discovering the new route, until it rejoins the old
   path; the node where this happens may also have to carry out local
   repair actions.

   A problem is that there is usually no robust technique to distinguish
   case (2) from case (3), because of the relative weakness of the
   techniques in determining that such changes have not occurred.  (They
   can be effective in determining that a change has occurred; however,
   even where they can tell that the route from the peer has not
   changed, they cannot rule out a change beyond that peer.)  There is
   therefore a danger that multiple nodes within the network would
   attempt to carry out local repair in parallel.

   One possible technique to address this problem is that a GIMPS node



Schulzrinne & Hancock    Expires November 18, 2005             [Page 56]

Internet-Draft                    GIMPS                         May 2005


   that detects case (3) locally, rather than initiating local repair
   immediately, still sends a route change notification, just in case
   (2) actually applies.  If the peer locally detects no downstream
   route change, it can signal this in the Query direction (e.g. by
   setting another flag in the Common-Header of a GIMPS message).  This
   acts to damp the possibility of a 'local repair storm', at the cost
   of an additional peer-peer round trip time.

7.1.4  Local Signaling Application State Removal

   After a route change, a signaling application may wish to remove
   state at another node which is no longer on the path.  However, since
   it is no longer on the path, in principle GIMPS can no longer send
   messages to it.  (In general, provided this state is soft, it will
   time out anyway; however, the timeouts involved may have been set to
   be very long to reduce signaling load.)  The requirement to remove
   state in a specific peer node is identified in [23].

   This requirement can be met provided that GIMPS is able to 'remember'
   the old path to the signaling application peer for the period while
   the NSLP wishes to be able to use it.  Since NSLP peers are a single
   GIMPS hop apart, the necessary information is just the old entry in
   the node's routing state table for that flow.  Rather than requiring
   the GIMPS level to maintain multiple generations of this information,
   it can just be provided to the signaling application in the same node
   (in an opaque form), which can store it if necessary and provide it
   back to the GIMPS layer in case it needs to be used.  This
   information is denoted as 'SII-Handle' in the abstract API of
   Appendix D; however, the details are an implementation issue which do
   not affect the rest of the protocol.

7.1.5  Operation with Heterogeneous NSLPs

   A potential problem with route change detection is that the detecting
   GIMPS node may not implement all the signaling applications that need
   to be informed.  Therefore, it would need to be able to send a
   notification back along the unchanged path to trigger the nearest
   signaling application aware node to take action.  If multiple
   signaling applications are in use, it would be hard to define when to
   stop propagating this notification.  However, given the rules on
   message interception and routing state maintenance in Section 4.3,
   Section 4.4 and Section 5.3.3, this situation cannot arise: all NSLP
   peers are exactly one GIMPS hop apart.

   The converse problem is that the ability of GIMPS to detect route
   changes by purely local monitoring of forwarding tables is more
   limited.  (This is probably an appropriate limitation of GIMPS
   functionality.  If we need a protocol for distributing notifications



Schulzrinne & Hancock    Expires November 18, 2005             [Page 57]

Internet-Draft                    GIMPS                         May 2005


   about local changes in forwarding table state, a flow signaling
   protocol is probably not the right starting point.)

7.2  Policy-Based Forwarding and Flow Wildcarding

   Signaling messages almost by definition need to contain address and
   port information to identify the flow they are signaling for.  We can
   divide this information into two categories:

   Message-Routing-Information: This is the information needed to
      determine how a message is routed within the network.  It may
      include a number of flow N-tuple parameters, and is carried as an
      object in each GIMPS message (see Section 5.1).

   Additional Packet Classification Information: This is any further
      higher layer information needed to select a subset of packets for
      special treatment by the signaling application.  The need for this
      is highly signaling application specific, and so this information
      is invisible to GIMPS (if indeed it exists); it will be carried
      only in the corresponding NSLP.

   The correct pinning of signaling messages to the data path depends on
   how well the downstream messages in datagram mode can be made to be
   routed correctly.  Two strategies are used:

      The messages themselves match the flow in destination address and
      possibly other fields (see Section 5.3 and Section 5.3.2 for
      further discussion).  In many cases, this will cause the messages
      to be routed correctly even by GIMPS-unaware nodes.

      A GIMPS-aware node carrying out policy based forwarding on higher
      layer identifiers (in particular, the protocol and port numbers
      for IPv4) should take into account the entire Message-Routing-
      Information object in selecting the outgoing interface rather than
      relying on the IP layer.

   Message-Routing-Information formats may allow a degree of
   'wildcarding', for example by applying a prefix length to the source
   or destination address, or by leaving certain fields unspecified.  A
   GIMPS-aware node must verify that all flows matching the Message-
   Routing-Information would be routed identically in the downstream
   direction, or else reject the message with an error.

7.3  NAT Traversal

   As already noted, GIMPS messages must carry packet addressing and
   higher layer information as payload data in order to define the flow
   signalled for.  (This applies to all GIMPS messages, regardless of



Schulzrinne & Hancock    Expires November 18, 2005             [Page 58]

Internet-Draft                    GIMPS                         May 2005


   how they are encapsulated or which direction they are travelling in.)
   At an addressing boundary the data flow packets will have their
   headers translated; if the signaling payloads are not likewise
   translated, the signaling messages will refer to incorrect (and
   probably meaningless) flows after passing through the boundary.  In
   addition, some GIMPS messages (those used in the discovery process)
   carry addressing information about the GIMPS nodes themselves, and
   this must also be processed appropriately when traversing a NAT.

   The simplest solution to this problem is to require that a NAT is
   GIMPS-aware, and to allow it to modify datagram mode messages based
   on the contents of the Message-Routing-Information payload.  (This is
   making the implicit assumption that NATs only rewrite the header
   fields included in this payload, and not higher layer identifiers.)
   Provided this is done consistently with the data flow header
   translation, signaling messages will be valid each side of the
   boundary, without requiring the NAT to be signaling application
   aware.  An outline of the set of operations necessary on a downstream
   datagram mode message is as follows:

   1.  Verify that bindings for the data flow are actually in place.

   2.  Create bindings for subsequent C-mode signaling (based on the
       information in the Network-Layer-Information and Stack-
       Configuration-Data objects).

   3.  Create a new Message-Routing-Information object with fields
       modified according to the data flow bindings.

   4.  Create new Network-Layer-Information and Stack-Configuration-Data
       objects with fields to force upstream D-mode messages through the
       NAT, and to allow C-mode exchanges using the C-mode signaling
       bindings.

   5.  Add a new NAT-Traversal payload, listing the objects which have
       been modified and including the unmodified Message-Routing-
       Information.

   6.  Forward the message with these new payloads.

   The original Message-Routing-Information payload is retained in the
   message, but encapsulated in the new TLV type.  Further information
   can be added corresponding to the Network-Layer-Information payload,
   either the original payload itself or, in the case of a GIMPS node
   that wished to do topology hiding, opaque tokens (or it could be
   omitted altogether).  In the case of a sequence of NATs, this part of
   the NAT-Traversal object would become a list.  Note that a
   consequence of this approach is that the routing state tables at the



Schulzrinne & Hancock    Expires November 18, 2005             [Page 59]

Internet-Draft                    GIMPS                         May 2005


   actual signaling application peers (either side of the NAT) are no
   longer directly compatible.  In particular, the values of Message-
   Routing-Information are different, which is why the unmodified MRI is
   propagated in the NAT-Traversal payload to allow subsequent C-mode
   messages to be interpreted correctly..

   The case of traversing a GIMPS-unaware NAT is for further study.
   There is a dual problem of whether the GIMPS peers either side of the
   boundary can work out how to address each other, and whether they can
   work out what translation to apply to the Message-Routing-Information
   from what is done to the signaling packet headers.  The fundamental
   problem is that GIMPS messages contain 3 or 4 interdependent
   addresses which all have to be consistently translated, and existing
   generic NAT traversal techniques such as STUN [19] can process only
   two.

7.4  Interaction with IP Tunnelling

   The interaction between GIMPS and IP tunnelling is very simple.  An
   IP packet carrying a GIMPS message is treated exactly the same as any
   other packet with the same source and destination addresses: in other
   words, it is given the tunnel encapsulation and forwarded with the
   other data packets.

   Tunnelled packets will not be identifiable as GIMPS messages until
   they leave the tunnel, since any router alert option and the standard
   GIMPS protocol encapsulation (e.g. port numbers) will be hidden
   behind the standard tunnel header.  If signaling is needed for the
   tunnel itself, this has to be initiated as a separate signaling
   session by one of the tunnel endpoints - that is, the tunnel counts
   as a new flow.  Because the relationship between signaling for the
   'microflow' and signaling for the tunnel as a whole will depend on
   the signaling application in question, we are assuming that it is a
   signaling application responsibility to be aware of the fact that
   tunnelling is taking place and to carry out additional signaling if
   necessary; in other words, one tunnel endpoint must be signaling
   application aware.

   In some cases, it is the tunnel exit point (i.e. the node where
   tunnelled data and downstream signaling packets leave the tunnel)
   that will wish to carry out the tunnel signaling, but this node will
   not have knowledge or control of how the tunnel entry point is
   carrying out the data flow encapsulation.  This information could be
   carried as additional data (an additional GIMPS payload) in the
   tunnelled signaling packets if the tunnel entry point was at least
   GIMPS-aware.  This payload would be the GIMPS equivalent of the RSVP
   SESSION_ASSOC object of [11].  Whether this functionality should
   really be part of GIMPS and if so how the payload should be handled



Schulzrinne & Hancock    Expires November 18, 2005             [Page 60]

Internet-Draft                    GIMPS                         May 2005


   will be considered in a later version.

7.5  IPv4-IPv6 Transition and Interworking

   GIMPS itself is essentially IP version neutral (version dependencies
   are isolated in the formats of the Message-Routing-Information,
   Network-Layer-Information and Stack-Configuration-Data objects, and
   GIMPS also depends on the version independence of the protocols that
   support messaging associations).  In mixed environments, GIMPS
   operation will be influenced by the IP transition mechanisms in use.
   This section provides a high level overview of how GIMPS is affected,
   considering only the currently predominant mechanisms.

   Dual Stack: (This applies both to the basic approach described in
      [24] as well as the dual-stack aspects of more complete
      architectures such as [28].)  In mixed environments, GIMPS should
      use the same IP version as the flow it is signaling for; hosts
      which are dual stack for applications and routers which are dual
      stack for forwarding should have GIMPS implementations which can
      support both IP versions.

      In theory, for some connection mode encapsulation options, a
      single messaging association could carry signaling messages for
      flows of both IP versions, but the saving seems of limited value.
      The IP version used in datagram mode is closely tied to the IP
      version used by the data flow, so it is intrinsically impossible
      for a IPv4-only or IPv6-only GIMPS node to support signaling for
      flows using the other IP version.

      Applications with a choice of IP versions might select a version
      based on which could be supported in the network by GIMPS, which
      could be established by running parallel discovery procedures.  In
      theory, a GIMPS message related to a flow of one IP version could
      flag support for the other; however, given that IPv4 and IPv6
      could easily be separately routed, the correct GIMPS peer for a
      given flow might well depend on IP version anyway, making this
      flagged information irrelevant.

   Packet Translation: (Applicable to SIIT [5] and NAT-PT [12].)  Some
      transition mechanisms allow IPv4 and IPv6 nodes to communicate by
      placing packet translators between them.  From the GIMPS
      perspective, this should be treated essentially the same way as
      any other NAT operation (e.g. between 'public' and 'private'
      addresses) as described in Section 7.3.  In other words, the
      translating node needs to be GIMPS-aware; it will run GIMPS with
      IPv4 on some interfaces and with IPv6 on others, and will have to
      translate the Message-Routing-Information payload between IPv4 and
      IPv6 formats for flows which cross between the two.  The



Schulzrinne & Hancock    Expires November 18, 2005             [Page 61]

Internet-Draft                    GIMPS                         May 2005


      translation rules for the fields in the payload (including e.g.
      traffic class and flow label) are as defined in [5].

   Tunnelling: (Applicable to 6to4 [13] and a whole host of other
      tunnelling schemes.)  Many transition mechanisms handle the
      problem of how an end to end IPv6 (or IPv4) flow can be carried
      over intermediate IPv4 (or IPv6) regions by tunnelling; the
      methods tend to focus on minimising the tunnel administration
      overhead.

      From the GIMPS perspective, the treatment should be as similar as
      possible to any other IP tunnelling mechanism, as described in
      Section 7.4.  In particular, the end to end flow signaling will
      pass transparently through the tunnel, and signaling for the
      tunnel itself will have to be managed by the tunnel endpoints.
      However, additional considerations may arise because of special
      features of the tunnel management procedures.  For example, [14]
      is based on using an anycast address as the destination tunnel
      endpoint.  It might be unwise to carry out signaling for the
      tunnel to such an address, and the GIMPS implementation there
      would not be able to use it as a source address for its own
      signaling messages (e.g.  GIMPS-responses).  Further analysis will
      be contained in a future version of this specification.




























Schulzrinne & Hancock    Expires November 18, 2005             [Page 62]

Internet-Draft                    GIMPS                         May 2005


8.  Security Considerations

   The security requirement for the GIMPS layer is to protect the
   signaling plane against identified security threats.  For the
   signaling problem as a whole, these threats have been outlined in
   [21]; the NSIS framework [20] assigns a subset of the responsibility
   to the NTLP.  The main issues to be handled can be summarised as:

   Message Protection: Signaling message content should be protected
      against eavesdropping, modification, injection and replay while in
      transit.  This applies both to GIMPS payloads, and GIMPS should
      also provide such protection as a service to signaling
      applications between adjacent peers.

   State Integrity Protection: It is important that signaling messages
      are delivered to the correct nodes, and nowhere else.  Here,
      'correct' is defined as 'the appropriate nodes for the signaling
      given the Message-Routing-Information'.  In the case where the MRI
      is the Flow Identification for path-coupled signaling,
      'appropriate' means 'the same nodes that the infrastructure will
      route data flow packets through'.  (GIMPS has no role in deciding
      whether the data flow itself is being routed correctly; all it can
      do is ensure the signaling is routed consistently with it.)  GIMPS
      uses internal state to decide how to route signaling messages, and
      this state needs to be protected against corruption.

   Prevention of Denial of Service Attacks: GIMPS nodes and the network
      have finite resources (state storage, processing power,
      bandwidth).  The protocol should try to minimise exhaustion
      attacks against these resources and not allow GIMPS nodes to be
      used to launch attacks on other network elements.

   The main missing issue is handling authorisation for executing
   signaling operations (e.g. allocating resources).  This is assumed to
   be done in each signaling application.

   In many cases, GIMPS relies on the security mechanisms available in
   messaging associations to handle these issues, rather than
   introducing new security measures.  Obviously, this requires the
   interaction of these mechanisms with the rest of the GIMPS protocol
   to be understood and verified, and some aspects of this are discussed
   in Section 5.6.

8.1  Message Confidentiality and Integrity

   GIMPS can use messaging association functionality, such as TLS or
   IPsec, to ensure message confidentiality and integrity.  In many
   cases, confidentiality of GIMPS information itself is not likely to



Schulzrinne & Hancock    Expires November 18, 2005             [Page 63]

Internet-Draft                    GIMPS                         May 2005


   be a prime concern, in particular since messages are often sent to
   parties which are unknown ahead of time, although the content visible
   even at the GIMPS level gives significant opportunities for traffic
   analysis.  Signaling applications may have their own mechanism for
   securing content as necessary; however, they may find it convenient
   to rely on protection provided by messaging associations, since it
   runs unbroked between signaling application peers.

8.2  Peer Node Authentication

   Cryptographic protection (of confidentiality or integrity) requires a
   security association with session keys, which can be established
   during an authentication and key exchange protocol run based on
   shared secrets, public key techniques or a combination of both.
   Authentication and key agreement is possible using the protocols
   associated with the messaging association being secured (TLS
   incorporates this functionality directly; IKE, IKEv2 or KINK can
   provide it for IPsec).  GIMPS nodes rely on these protocols to
   authenticate the identity of the next hop, and GIMPS has no
   authentication capability of its own.

   However, with discovery, there are few effective ways to know what is
   the legitimate next or previous hop as opposed to an impostor.  In
   other words, cryptographic authentication here only provides
   assurance that a node is 'who' it is (i.e. the legitimate owner of
   identity in some namespace), not 'what' it is (i.e. a node which is
   genuinely on the flow path and therefore can carry out signaling for
   a particular flow).  Authentication provides only limited protection,
   in that a known peer is unlikely to lie about its role.  Additional
   methods of protection against this type of attack are considered in
   Section 8.3 below.

   It is an implementation issue whether peer node authentication should
   be made signaling application dependent; for example, whether
   successful authentication could be made dependent on presenting
   authorisation to act in a particular signaling role (e.g. signaling
   for QoS).  The abstract API of Appendix D does not specify such
   policy and authentication interactions between GIMPS and the NSLP it
   is serving.

8.3  Routing State Integrity

   The internal state in a node (see Section 4.2), specifically the peer
   identification, is used to route messages.  If this state is
   corrupted, signaling messages may be misdirected.

   In the case where the message routing method is path-coupled
   signaling, the messages need to be routed identically to the data



Schulzrinne & Hancock    Expires November 18, 2005             [Page 64]

Internet-Draft                    GIMPS                         May 2005


   flow described by the Flow Identifier, and the routing state table is
   the GIMPS view of how these flows are being routed through the
   network in the immediate neighbourhood of the node.  Routes are only
   weakly secured (e.g. there is usually no cryptographic binding of a
   flow to a route), and there is no other authoritative information
   about flow routes than the current state of the network itself.
   Therefore, consistency between GIMPS and network routing state has to
   be ensured by directly interacting with the routing mechanisms to
   ensure that the signaling peers are the appropriate ones for any
   given flow.  A good overview of security issues and techniques in
   this sort of context is provided in [27].

   In one direction, peer identification is installed and refreshed only
   on receiving a GIMPS-Reponse message (compare Figure 4).  This must
   echo the cookie from a previous GIMPS-Query message, which will have
   been sent along the flow path (in datagram mode, i.e. end-to-end
   addressed).  Hence, only the true next peer or an on-path attacker
   will be able to generate such a message, provided freshness of the
   cookie can be checked at the querying node.

   In the other direction, peer identification can be installed directly
   on receiving a GIMPS-Query message containing addressing information
   for the signaling source.  However, any node in the network could
   generate such a message (indeed, almost any node in the network could
   be the genuine upstream peer for a given flow).  To protect against
   this, three strategies are possible:

   Filtering: the receiving node may be able to reject signaling
      messages which claim to be for flows with flow source addresses
      which would be ruled out by ingress filtering.  An extension of
      this technique would be for the receiving node to monitor the data
      plane and to check explicitly that the flow packets are arriving
      over the same interface and if possible from the same link layer
      neighbour as the datagram mode signaling packets.  (If they are
      not, it is likely that at least one of the signaling or flow
      packets is being spoofed.)  Signaling applications should only
      install state on the route taken by the signaling itself.

   Authentication (weak or strong): the receiving node may refuse to
      install upstream state until it has completed a GIMPS-Confirm
      handshaked with the peer.  This echoes the response cookie of the
      GIMPS-Response, and discourages nodes from using forged source
      addresses.  A stronger approach is to require full peer
      authentication within the messaging association, the reasoning
      being that an authenticated peer can be trusted not to pretend
      that it is on path when it is not.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 65]

Internet-Draft                    GIMPS                         May 2005


   SID segregation: The routing state lookup for a given MRI and NSLPID
      also takes the SID into account.  A malicious node can only
      overwrite existing routing state if it can guess the corresponding
      SID; it can insert state with random SID values, but generally
      this will not be used to route messages for which state has
      already been legitimately established.

   The second technique also plays a role in denial of service
   prevention, see below.  In practice, a combination of all techniques
   may be appropriate.

8.4  Denial of Service Prevention

   GIMPS is designed so that in general each Query message only
   generates at most one Response, so that a GIMPS node cannot become
   the source of a denial of service amplification attack.  (There is a
   special case of retransmitted Response messages, see Section 5.3.4.)

   However, GIMPS can still be subjected to denial-of-service attacks
   where an attacker using forged source addresses forces a node to
   establish state without return routability, causing a problem similar
   to TCP SYN flood attacks.  Furthermore, an adversary might use
   modified or replayed unprotected signaling messages as part of such
   an attack.  There are two types of state attacks and one
   computational resource attack.  In the first state attack, an
   attacker floods a node with messages that the node has to store until
   it can determine the next hop.  If the destination address is chosen
   so that there is no GIMPS-capable next hop, the node would accumulate
   messages for several seconds until the discovery retransmission
   attempt times out.  The second type of state-based attack causes
   GIMPS state to be established by bogus messages.  A related
   computational/network-resource attack uses unverified messages to
   cause a node to make AAA queries or attempt to cryptographically
   verify a digital signature.  (RSVP is vulnerable to this type of
   attack.)  Relying only on upper layer security, for example based on
   CMS, might open a larger door for denial of service attacks since the
   messages are often only one-shot-messages without utilizing multiple
   roundtrips and DoS protection mechanisms.

   We use a combination of two defences against these attacks:

   1.  The responding node does not establish a session or discover its
       next hop on receiving the GIMPS-Query message, but can wait for a
       GIMPS-Confirm message on a secure channel.  If the channel
       exists, the additional delay is a one one-way delay and the total
       is no more than the minimal theoretically possible delay of a
       three-way handshake, i.e., 1.5 node-to-node round-trip times.
       The delay gets significantly larger if a new connection needs to



Schulzrinne & Hancock    Expires November 18, 2005             [Page 66]

Internet-Draft                    GIMPS                         May 2005


       be established first.

   2.  The Response to the Query message contains a cookie, which is
       repeated in the Confirm.  State is only established for messages
       that contain a valid cookie.  The setup delay is also 1.5 round-
       trip times.  (This mechanism is similar to that in SCTP [6] and
       other modern protocols.)

   Once a node has decided to establish routing state, there may still
   be transport and security state to be established between peers.
   This state setup is also vulnerable to additional denial of service
   attacks.  GIMPS relies on the lower layer protocols that make up
   messaging associations to mitigate such attacks.  The current
   description assumes that the querying node is always the one wishing
   to establish a messaging association, so it is typically the
   responding node that needs to be protected.

8.5  Summary of Requirements on Cookie Mechanisms

   The requirements on the Query cookie can be summarised as follows:

   Liveness: The cookie must be live (must change from one handshake to
      the next).  To prevent replay attacks.

   Unpredictability: The cookie must not be guessable (e.g. not from a
      sequence or timestamp).  To prevent direct forgery based on seeing
      a history of captured messages.

   Easily validated: It must be efficient for the Q-Node to validate
      that a particular cookie matches an in-progress handshake, for a
      routing state machine which already exists.  To discard responses
      to spoofed queries.

   Uniqueness: The cookie must be unique to a given handshake (since it
      is actually used to match the Response to a handshake anyway, e.g.
      during messaging association re-use).

   Likewise, the requirements on the Responder cookie can be summarised
   as follows:

   Liveness: The cookie must be live (must change from one handshake to
      the next).  To prevent replay attacks.

   Creation simplicity: The cookie must be lightweight to generate.  To
      avoid resource exhaustion at the responding node.






Schulzrinne & Hancock    Expires November 18, 2005             [Page 67]

Internet-Draft                    GIMPS                         May 2005


   Validation simplicity: It must be simple for the R-node to validate
      that an R-cookie was generated by itself (and no-one else),
      without storing state about the handshake it was generated for.

   Binding: The cookie must be bound to the routing state that will be
      installed.  To prevent use with different routing state e.g. in a
      modified Confirm.  The routing state here includes:

         The NLI of the Query

         The MRI/NSLPID for the messaging

         The interface on which the Query was received (probably)

   A suitable implementation for the Q-Cookie is a cryptographically
   random number which is unique for this routing state machine
   handshake.

   A suitable implementation for the R-Cookie is as follows:

       R-Cookie = liveness data + hash (locally known secret,
                                        Q-Node NLI, MRI, NSLPID,
                                        reception interface,
                                        liveness data)

   There are a couple of alternatives for the liveness data.  One is to
   use a timestamp like SCTP.  Another is to use a local secret with
   (rapid) rollover, and the liveness data is the generation number of
   the secret, like IKEv2.  In both cases, the liveness data has to be
   carried outside the hash, to allow the hash to be verified at the
   Responder.  Another approach is to replace the hash with encryption
   under a locally known secret, in which case the liveness data does
   not need to be carried in the clear.  Any symmetric cipher immune to
   known plaintext attacks can be used.

8.6  Residual Threats

   Taking the above security mechanisms into account, the main residual
   threats against NSIS are three types of on-path attack.

   An on-path attacker who can intercept the initial Query can do most
   things it wants to the subsequent signalling.  It is very hard to
   protect against this at the GIMPS level; the only defence is to use
   strong messaging association security to see whether the Responding
   node is authorised to take part in NSLP signalling exchanges.  To
   some extent, this behaviour is logically indistinguishable from
   correct operation, so it is easy to see why defence is difficult.
   Note than an on-path attacker of this sort can do anything to the



Schulzrinne & Hancock    Expires November 18, 2005             [Page 68]

Internet-Draft                    GIMPS                         May 2005


   traffic as well as the signalling.  Therefore, the additional threat
   induced by the signalling weakness seems tolerable.

   At the NSLP level, there is a concern about transitivity of trust of
   correctness of routing along the signalling chain.  The NSLP at the
   querying node can have good assurance that it is communicating with
   an on-path peer (or a node delegated by the on-path node).  However,
   it has no assurance that the node beyond the responder is also on-
   path, or that the MRI (in particular) is not being modified by the
   responder to refer to a different flow.  Therefore, if it sends
   signalling messages with payloads (e.g. authorisation tokens) which
   are "valuable" to nodes beyond the first hop, it is up to the NSLP to
   ensure that the appropriate chain of trust exists, which must in
   general use messaging association (strong) security.

   There is a further residual attack by a node which is not on the path
   of the flow, but is on the path of the Response, or is able to use a
   Response from one handshake to interfere with another.  The attacker
   modifies the Response to cause the Querying node to form an adjacency
   with it rather than the true downstream node.  In principle, this
   attack can be prevented by including an additional cryptographic
   object in the Response message which ties the Response to the initial
   Query and the routing state and can be verified by the Querying node.




























Schulzrinne & Hancock    Expires November 18, 2005             [Page 69]

Internet-Draft                    GIMPS                         May 2005


9.  IANA Considerations

   This section outlines the content of a future IANA considerations
   section.

   The GIMPS specification requires the creation of registries, as
   follows:

   GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a
      1 byte message type field (initially distinguishing Query/
      Response/Confirm/Data/Error and MA-Hello messages).

   NSLP Identifiers: Each signaling application requires one of more
      NSLPIDs (different NSLPIDs may be used to distinguish different
      classes of signaling node, for example to handle different
      aggregation levels or different processing subsets).  An NSLPID
      must be associated with a unique RAO value; further considerations
      are discussed in Section 5.3.3.

   Object Types: There is an TBD-bit field in the object header
      (Appendix C.3.1).  Distinguish different ranges for different
      allocation styles (standards action, expert review etc.) and
      different applicability scopes (experimental/private).  When a new
      object type is defined, the extensibility bits (A/B, see
      Appendix C.3.2) must also be defined.

   Extensibility Flags: There are TBD reserved flag bits in the generic
      object header (Appendix C.3.1).  These are reserved for the
      definition of more complex extensibility encoding schemes.

   Message Routing Methods: GIMPS allows the idea of multiple message
      routing methods (see Section 3.3).  The message routing method is
      indicated in the leading 2 bytes of the MRI object
      (Appendix C.4.1).

   MA-Protocol-IDs: The GIMPS design allows the set of possible
      protocols to be used in a messaging association to be extended, as
      discussed in Section 5.6.  Every new mode of using a protocol is
      given a single byte MA-Protcol-ID, which is used as a tag in the
      Stack-Proposal and Stack-Configuration-Data objects
      (Appendix C.4.4 and Appendix C.4.5).  Allocating a new MA-
      Protocol-ID requires defining the higher layer addressing
      information (if any) in the Stack-Configuration-Data object that
      is needed to define its configuration.  Note that the
      MA-Protocol-ID is not an IP Protocol number (indeed, some of the
      possible messaging association protocols - such as TLS - do not
      have an IP Protocol number).




Schulzrinne & Hancock    Expires November 18, 2005             [Page 70]

Internet-Draft                    GIMPS                         May 2005


   Error Classes: There is a 1 byte field at the start of the Value
      field of the Error object (Appendix C.4.10).  Five values for this
      field have already been defined.  Further general classes of error
      could be defined.  Note that the value here is primarily to aid
      human or management interpretation of otherwise unknown error
      codes.

   Error Codes: There is a 3 byte error code in the Value field of the
      Error object (Appendix C.4.10).  When a new error code is
      allocated, the Error Class and the format of any associated error-
      specific information must also be defined.








































Schulzrinne & Hancock    Expires November 18, 2005             [Page 71]

Internet-Draft                    GIMPS                         May 2005


10.  Open Issues

   Note that this section is now partially historic; the authoritative
   list of open issues is contained in an online issue tracker at
   http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index.
   The subsections remaining here are preserved to keep cross-reference
   integrity with the rest of the specification until the issues are
   resolved.

10.1  Additional Discovery Mechanisms

   The routing state maintenance procedures described in Section 4.4 are
   strongly focussed on the problem of discovering, implicitly or
   explicitly, the neighbouring peers on the flow path - which is the
   necessary functionality for path-coupled signaling.

   As well as the GIMPS-Query/Response discovery mechanism for
   determining the downstream peer for the path-coupled message routing
   method, other techniques may sometimes also be possible.  For
   example, in many environments, a host has a single access router,
   i.e. the downstream peer (for outgoing flows) and the upstream peer
   (for incoming ones) are known a priori.  More generally, a link state
   routing protocol database can be analysed to determine downstream
   peers in more complex topologies, and maybe upstream ones if strict
   ingress filtering is in effect.  More radically, much of the GIMPS
   protocol is unchanged if we consider off-path signaling nodes,
   although there are significant differences in some of the security
   analysis (Section 8.3).  None of these possibilities are currently
   considered further in this specification.  However, the basic
   protocol description is unchanged if an encapsulation mechanism is
   defined for sending Query messages upstream or directed to particular
   nodes, if this information is available from other sources.



















Schulzrinne & Hancock    Expires November 18, 2005             [Page 72]

Internet-Draft                    GIMPS                         May 2005


11.  Change History

11.1  Changes In Version -06

   Version -06 does not introduce any major structural changes to the
   protocol definition, although it does clarify a number of details and
   resolve some outstanding open issues.  The primary changes are as
   follows:

   1.   Added a new high level Section 3.3 which gathers together the
        various aspects of the message routing method concept.

   2.   Added a new high level Section 3.4 which explains the concept
        and significance of the session identifier.  Also clarified that
        the routing state always depends on the session identifier.

   3.   Added notes about the level of address validation performed by
        GIMPS in Section 4.1.2 and extensions to the API in Appendix D.

   4.   Split the old Node-Addressing object into a Network-Layer-
        Information object and Stack-Configuration-Data object.  The
        former refers to basic information about a node, and the latter
        carries information about messaging association configuration.
        Redefined the content of the various handshake messages
        accordingly in Section 4.4.1 and Section 5.1.

   5.   Re-wrote Section 4.4.3 to clarify the rules on refresh and purge
        of routing state and messaging associations.  Also, moved the
        routing state lifetime into the Network-Layer-Information object
        and added a messaging association lifetime to the Stack-
        Configuration-Data object (Section 5.2).

   6.   Added specific message types for errors and MA-Refresh in
        Section 5.1.  The error object is now GIMPS-specific
        (Appendix C.4.10).

   7.   Moved the Flow-Identifier information about the message routing
        method from the general description of the object to the path-
        coupled MRM section (Section 5.7.1.1), and made a number of
        clarifications to the bit format (Appendix C.4.1.1).

   8.   Removed text about assumptions on the version numbering of
        NSLPs, and restricted the scope of the description of TLV objct
        formats and extensibility flags to GIMPS rather than the whole
        of NSIS (Appendix C).

   9.   Added a new Section 5.5 explaining the possible relationships
        between message types and encapsulation formats.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 73]

Internet-Draft                    GIMPS                         May 2005


   10.  Added a new Section 6 in outline form, to capture the formal
        specification of the protocol operation.

   11.  Added new security sections on cookie requirements (Section 8.5)
        and residual threats (Section 8.6).


11.2  Changes In Version -05

   Version -05 reformulates the specification, to describe routing state
   maintenance in terms of exchanging explicitly identified Query/
   Response/Confirm messages, leaving the upstream/downstream
   distinction as a specific detail of how Query messages are
   encapsulated.  This necessitated widespread changes in the
   specification text, especially Section 4.2.1, Section 4.4,
   Section 5.1 and Section 5.3 (although the actual message sequences
   are unchanged).  A number of other issues, especially in the area of
   message encapsulation, have also been closed.  The main changes are
   the following:

   1.   Added a reference to [29] as a concrete example of an
        alternative message routing method.

   2.   Added further text (particularly in Section 2) on what GIMPS
        means by the concept of 'session'.

   3.   Firmed up the selection of UDP as the encapsulation choice for
        datagram mode, removing the open issue on this topic.

   4.   Defined the interaction between GIMPS and signaling applications
        for communicating about the cryptographic security properties of
        how a message will be sent or has been received (see
        Section 4.1.2 and Appendix D).

   5.   Closed the issue on whether Query messages should use the
        signaling or flow source address in the IP header; both options
        are allowed by local policy and a flag in the common header
        indicates which was used.  (See Section 5.7.1.2.)

   6.   Added the necessary information elements to allow the IP hop
        count between adjacent GIMPS peers to be measures and reported.
        (See Section 5.2.2 and Appendix C.4.3.)

   7.   The old open-issue text on selection of IP router alert option
        values has been moved into the main specification to capture the
        technical considerations that should be used in assigning such
        values (in section Section 5.3.3).




Schulzrinne & Hancock    Expires November 18, 2005             [Page 74]

Internet-Draft                    GIMPS                         May 2005


   8.   Resolved the open issue on lost Confirm messages by allowing a
        choice of timer-based retransmission of the Response, or an
        error message from the responding node which causes the
        retransmission of the Confirm (see Section 5.3.4).

   9.   Closed the open issue on support for message scoping (this is
        now assumed to be a NSLP function).

   10.  Moved the authoritative text for most of the remaining open
        issues in Section 10 to an online issue tracker.


11.3  Changes In Version -04

   Version -04 includes mainly clarifications of detail and extensions
   in particular technical areas, in part to support ongoing
   implementation work.  The main details are as follows:

   1.   Substantially updated Section 4, in particular clarifying the
        rules on what messages are sent when and with what payloads
        during routing and messaging association setup, and also adding
        some further text on message transfer attributes.

   2.   The description of messaging association protocol negotiation
        including the related object formats has been centralised in a
        new Section 5.6, removing the old Section 6.6 and also closing
        old open issues 8.5 and 8.6.

   3.   Made a number of detailed changes in the message format
        definitions (Appendix C), as well as incorporating initial rules
        for encoding message extensibility information.  Also included
        explicit formats for a general purpose Error object, and the
        objects used to negotiate messaging association protocols.
        Updated the corresponding open issues section (old section 9.3)
        with a new item on NSLP versioning.

   4.   Updated the GIMPS API (Appendix D), including more precision on
        message transfer attributes, making the NSLP hint about storing
        reverse path state a return value rather than a separate
        primitive, and adding a new primitive to allow signaling
        applications to invalidate GIMPS routing state.  Also, added a
        new parameter to SendMessage to allow signaling applications to
        'bypass' a message statelessly, preserving the source of an
        input message.

   5.   Added an outline for the future content of an IANA
        considerations section (Section 9).  Currently, this is
        restricted to identifying the registries and allocations



Schulzrinne & Hancock    Expires November 18, 2005             [Page 75]

Internet-Draft                    GIMPS                         May 2005


        required, without defining the allocation policies and other
        considerations involved.

   6.   Shortened the background design discussion in Section 3.

   7.   Made some clarifications in the terminology section relating to
        how the use of C-mode does and does not mandate the use of
        transport or security protection.

   8.   The ABNF for message formats in Section 5.1 has been re-written
        with a grammar structured around message purpose rather than
        message direction, and additional explanation added to the
        information element descriptions in Section 5.2.

   9.   The description of the datagram mode transport in Section 5.3
        has been updated.  The encapsulation rules (covering IP
        addressing and UDP port allocation) have been corrected, and a
        new subsection on message retransmission and rate limiting has
        been added, superceding the old open issue on the same subject
        (section 8.10).

   10.  A new open issue on IP TTL measurement to detect non-GIMPS
        capable hops has been added (old section 9.5).


11.4  Changes In Version -03

   Version -03 includes a number of minor clarifications and extensions
   compared to version -02, including more details of the GIMPS API and
   messaging association setup and the node addressing object.  The full
   list of changes is as follows:

   1.  Added a new section pinning down more formally the interaction
       between GIMPS and signaling applications (Section 4.1), in
       particular the message transfer attributes that signaling
       applications can use to control GIMPS (Section 4.1.2).

   2.  Added a new open issue identifying where the interaction between
       the security properties of GIMPS and the security requirements of
       signaling applications should be identified (old section 9.10).

   3.  Added some more text in Section 4.2.1 to clarify that GIMPS has
       the (sole) responsibility for generating the messages that
       refresh message routing state.

   4.  Added more clarifying text and table to GHC and IP TTL handling
       discussion of Section 4.3.4.




Schulzrinne & Hancock    Expires November 18, 2005             [Page 76]

Internet-Draft                    GIMPS                         May 2005


   5.  Split Section 4.4 into subsections for different scenarios, and
       added more detail on Node-Addressing object content and use to
       handle the case where association re-use is possible in
       Section 4.4.2.

   6.  Added strawman object formats for Node-Addressing and Stack-
       Proposal objects in Section 5.1 and Appendix C.

   7.  Added more detail on the bundling possibilities and appropriate
       configurations for various transport protocols in Section 5.4.1.

   8.  Included some more details on NAT traversal in Section 7.3,
       including a new object to carry the untranslated address-bearing
       payloads, the NAT-Traversal object.

   9.  Expanded the open issue discussion in old section 9.3 to include
       an outline set of extensibility flags.


11.5  Changes In Version -02

   Version -02 does not represent any radical change in design or
   structure from version -01; the emphasis has been on adding details
   in some specific areas and incorporation of comments, including early
   review comments.  The full list of changes is as follows:

   1.   Added a new Section 1.1 which summarises restrictions on scope
        and applicability; some corresponding changes in terminology in
        Section 2.

   2.   Closed the open issue on including explicit GIMPS state teardown
        functionality.  On balance, it seems that the difficulty of
        specifying this correctly (especially taking account of the
        security issues in all scenarios) is not matched by the saving
        of state enabled.

   3.   Removed the option of a special class of message transfer for
        reliable delivery of a single message.  This can be implemented
        (inefficiently) as a degenerate case of C-mode if required.

   4.   Extended Appendix C with a general discussion of rules for
        message and object formats across GIMPS and other NSLPs.  Some
        remaining open issues are noted in old section 9.3 (since
        removed).

   5.   Updated the discussion of Section 5.3.3 to take into account the
        proposed message formats and rules for allocation of NSLP id,
        and propose considerations for allocation of RAO values.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 77]

Internet-Draft                    GIMPS                         May 2005


   6.   Modified the description of the information used to route
        messages (first given in Section 4.2.1 but also throughout the
        document).  Previously this was related directly to the flow
        identification and described as the Flow-Routing-Information.
        Now, this has been renamed Message-Routing-Information, and
        identifies a message routing method and any associated
        addressing.

   7.   Modified the text in Section 4.3 and elsewhere to impose sanity
        checks on the Message-Routing-Information carried in C-mode
        messages, including the case where these messages are part of a
        GIMPS-Query/Response exchange.

   8.   Added rules for message forwarding to prevent message looping in
        a new Section 4.3.4, including rules on IP TTL and GIMPS hop
        count processing.  These take into account the new RAO
        considerations of Section 5.3.3.

   9.   Added an outline mechanism for messaging association protocol
        stack negotiation, with the details in a new Section 6.6 and
        other changes in Section 4.4 and the various sections on message
        formats.

   10.  Removed the open issue on whether storing reverse routing state
        is mandatory or optional.  This is now explicit in the API
        (under the control of the local NSLP).

   11.  Added an informative annex describing an abstract API between
        GIMPS and NSLPs in Appendix D.


11.6  Changes In Version -01

   The major change in version -01 is the elimination of
   'intermediaries', i.e. imposing the constraint that signaling
   application peers are also GIMPS peers.  This has the consequence
   that if a signaling application wishes to use two classes of
   signaling transport for a given flow, maybe reaching different
   subsets of nodes, it must do so by running different signaling
   sessions; and it also means that signaling adaptations for passing
   through NATs which are not signaling application aware must be
   carried out in datagram mode.  On the other hand, it allows the
   elimination of significant complexity in the connection mode handling
   and also various other protocol features (such as general route
   recording).

   The full set of changes is as follows:




Schulzrinne & Hancock    Expires November 18, 2005             [Page 78]

Internet-Draft                    GIMPS                         May 2005


   1.   Added a worked example in Section 3.5.

   2.   Stated that nodes which do not implement the signaling
        application should bypass the message (Section 4.3).

   3.   Decoupled the state handling logic for routing state and
        messaging association state in Section 4.4.  Also, allow
        messaging associations to be used immediately in both directions
        once they are opened.

   4.   Added simple ABNF for the various GIMPS message types in a new
        Section 5.1, and more details of the common header and each
        object in Section 5.2, including bit formats in Appendix C.  The
        common header format means that the encapsulation is now the
        same for all transport types (Section 5.4.1).

   5.   Added some further details on datagram mode encapsulation in
        Section 5.3, including more explanation of why a well known port
        is needed.

   6.   Removed the possibility for fragmentation over DCCP
        (Section 5.4.1), mainly in the interests of simplicity and loss
        amplification.

   7.   Removed all the tunnel mode encapsulations (old sections 5.3.3
        and 5.3.4).

   8.   Fully re-wrote the route change handling description
        (Section 7.1), including some additional detection mechanisms
        and more clearly distinguishing between upstream and downstream
        route changes.  Included further details on GIMPS/NSLP
        interactions, including where notifications are delivered and
        how local repair storms could be avoided.  Removed old
        discussion of propagating notifications through signaling
        application unaware nodes (since these are now bypassed
        automatically).  Added discussion on how to route messages for
        local state removal on the old path.

   9.   Revised discussion of policy-based forwarding (Section 7.2) to
        account for actual FLow-Routing-Information definition, and also
        how wildcarding should be allowed and handled.

   10.  Removed old route recording section (old Section 6.3).

   11.  Extended the discussion of NAT handling (Section 7.3) with an
        extended outline on processing rules at a GIMPS-aware NAT and a
        pointer to implications for C-mode processing and state
        management.



Schulzrinne & Hancock    Expires November 18, 2005             [Page 79]

Internet-Draft                    GIMPS                         May 2005


   12.  Clarified the definition of 'correct routing' of signaling
        messages in Section 8 and GIMPS role in enforcing this.  Also,
        opened the possibility that peer node authentication could be
        signaling application dependent.

   13.  Removed old open issues on Connection Mode Encapsulation
        (section 8.7); added new open issues on Message Routing (old
        Section 9.3 of version -05, later moved to Section 3.3) and
        Datagram Mode congestion control.

   14.  Added this change history.








































Schulzrinne & Hancock    Expires November 18, 2005             [Page 80]

Internet-Draft                    GIMPS                         May 2005


12.  References

12.1  Normative References

   [1]  Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

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

   [3]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
        RFC 2711, October 1999.

   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
        RFC 2765, February 2000.

   [6]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [7]  Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
        draft-ietf-dccp-spec-11 (work in progress), March 2005.

   [8]  Conta, A., "Internet Control Message Protocol (ICMPv6)for the
        Internet Protocol Version  6 (IPv6) Specification",
        draft-ietf-ipngwg-icmp-v3-06 (work in progress), November 2004.

12.2  Informative References

   [9]   Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", RFC 2205, September 1997.

   [10]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [11]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
         Operation Over IP Tunnels", RFC 2746, January 2000.

   [12]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
         Protocol Translation (NAT-PT)", RFC 2766, February 2000.

   [13]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [14]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",



Schulzrinne & Hancock    Expires November 18, 2005             [Page 81]

Internet-Draft                    GIMPS                         May 2005


         RFC 3068, June 2001.

   [15]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
         "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
         September 2001.

   [16]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [17]  Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
         Z., and J. Rosenberg, "Signaling Compression (SigComp)",
         RFC 3320, January 2003.

   [18]  Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
         Haukka, "Security Mechanism Agreement for the Session
         Initiation Protocol (SIP)", RFC 3329, January 2003.

   [19]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [20]  Hancock, R., "Next Steps in Signaling: Framework",
         draft-ietf-nsis-fw-07 (work in progress), December 2004.

   [21]  Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
         draft-ietf-nsis-threats-06 (work in progress), October 2004.

   [22]  Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
         (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
         May 2005.

   [23]  Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
         of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
         progress), February 2005.

   [24]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in
         progress), March 2005.

   [25]  Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
         draft-ietf-secsh-architecture-22 (work in progress),
         March 2005.

   [26]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02
         (work in progress), February 2005.

   [27]  Nikander, P., "Mobile IP version 6 Route Optimization Security



Schulzrinne & Hancock    Expires November 18, 2005             [Page 82]

Internet-Draft                    GIMPS                         May 2005


         Design Background", draft-ietf-mip6-ro-sec-02 (work in
         progress), October 2004.

   [28]  Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
         (DSTM)", draft-bound-dstm-exp-02 (work in progress),
         January 2005.

   [29]  Stiemerling, M., "Loose End Message Routing Method for NATFW
         NSLP", draft-stiemerling-nsis-natfw-mrm-01 (work in progress),
         February 2005.


Authors' Addresses

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7042
   Email: hgs+nsis@cs.columbia.edu
   URI:   http://www.cs.columbia.edu


   Robert Hancock
   Siemens/Roke Manor Research
   Old Salisbury Lane
   Romsey, Hampshire  SO51 0ZN
   UK

   Email: robert.hancock@roke.co.uk
   URI:   http://www.roke.co.uk

















Schulzrinne & Hancock    Expires November 18, 2005             [Page 83]

Internet-Draft                    GIMPS                         May 2005


Appendix A.  Acknowledgements

   This document is based on the discussions within the IETF NSIS
   working group.  It has been informed by prior work and formal and
   informal inputs from: Cedric Aoun, Attila Bader, Bob Braden, Marcus
   Brunner, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth,
   Cheng Hong, Georgios Karagiannis, Chris Lang, John Loughney, Allison
   Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Glenn Morrow,
   Dave Oran, Tom Phelan, Takako Sanda, Charles Shen, Melinda Shore,
   Martin Stiemerling, Mike Thomas, Hannes Tschofenig, Sven van den
   Bosch, Michael Welzl, and Lars Westberg.  In particular, Hannes
   Tschofenig provided a detailed set of review comments on the security
   section, and Andrew McDonald provided the formal description for the
   initial packet formats.  Chris Lang's implementation work provided
   objective feedback on the clarity and feasibility of the
   specification.  We look forward to inputs and comments from many more
   in the future.


































Schulzrinne & Hancock    Expires November 18, 2005             [Page 84]

Internet-Draft                    GIMPS                         May 2005


Appendix B.  Example Message Routing State Table

   Figure 10 shows a signaling scenario for a single flow being managed
   by two signaling applications using the path-coupled message routing
   method.  The flow sender and receiver and one router support both,
   two other routers support one each.

       A                        B          C          D           E
   +------+                  +-----+    +-----+    +-----+    +--------+
   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
   |      |    +-+    +-+    |GIMPS|    |GIMPS|    |GIMPS|    |        |
   +------+                  +-----+    +-----+    +-----+    +--------+

                     ------------------------------>>
                              Flow Direction

                      Figure 10: A Signaling Scenario

   The routing state table at node B is as follows:

   +--------------------+----------+----------+----------+-------------+
   |   Message Routing  |  Session |  NSLP ID | Response |    Query    |
   |     Information    |    ID    |          | Directio |  Direction  |
   |                    |          |          | n        |             |
   +--------------------+----------+----------+----------+-------------+
   |    Method = Path   |  0xABCD  |   NSLP1  |   IP-#A  |    (null)   |
   | Coupled; Flow ID = |          |          |          |             |
   |   {IP-#A, IP-#E,   |          |          |          |             |
   |  protocol, ports}  |          |          |          |             |
   |                    |          |          |          |             |
   |    Method = Path   |  0x1234  |   NSLP2  |   IP-#A  |  Pointer to |
   | Coupled; Flow ID = |          |          |          |     B-D     |
   |   {IP-#A, IP-#E,   |          |          |          |  messaging  |
   |  protocol, ports}  |          |          |          | association |
   +--------------------+----------+----------+----------+-------------+

   The Response direction state is just the same address for each
   application.  For the Query direction, NSLP1 only requires datagram
   mode messages and so no explicit routing state towards C is needed.
   NSLP2 requires a messaging association for its messages towards node
   D, and node C does not process NSLP2 at all, so the peer state for
   NSLP2 is a pointer to a messaging association that runs directly from
   B to D. Note that E is not visible in the state table (except
   implicitly in the address in the message routing information);
   routing state is stored only for adjacent peers.  (In addition to the
   peer identification, IP hop counts are stored for each peer where the
   state itself if not null; this is not shown in the table.)



Schulzrinne & Hancock    Expires November 18, 2005             [Page 85]

Internet-Draft                    GIMPS                         May 2005


Appendix C.  Bit-Level Formats

   This appendix provides initial formats for the various component
   parts of the GIMPS messages defined abstractly in Section 5.2.  It
   should be noted that these formats are extremely preliminary and
   should be expected to change completely several times during the
   further development of this specification.

C.1  General GIMPS Formatting Guidelines

   Each GIMPS message consists of a header and a sequence of objects.
   The GIMPS header has a specific format, described in more detail in
   Appendix C.2 below.  An NSLP message is one object within a GIMPS
   message.  Note that GIMPS provides the message length information and
   signaling application identification.

   Every object has the following general format:

   o  The overall format is Type-Length-Value (in that order).

   o  Some parts of the type field are set aside for control flags which
      define how unknown types should be handled; this is discussed in
      Appendix C.3.2.

   o  Length has the units of 32 bit words, and measures the length of
      Value.  If there is no Value, Length=0.

   o  Value is (therefore) a whole number of 32 bit words.  If there is
      any padding required, the length and location must be defined by
      the object-specific format information; objects which contain
      variable length (e.g. string) types may need to include additional
      length subfields to do so.

   o  Any part of the object used for padding or defined as reserved
      must be set to 0 on transmission and must be ignored on reception.


C.2  The GIMPS Common Header

   This header precedes all GIMPS messages.  It has a fixed format, as
   shown below.










Schulzrinne & Hancock    Expires November 18, 2005             [Page 86]

Internet-Draft                    GIMPS                         May 2005


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |  GIMPS hops   |        Message length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Signaling Application ID    |   Type        |S|R| Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message length = the total number of words in the message after
                    the common header itself
   Type           = the GIMPS message type (Query, Response, etc.)
   S flag         = set if the IP source address is the signaling
                    source address, clear if it was derived from the
                    MRI
   R flag         = set if a response to this message is explicitly
                    requested


C.3  General Object Characteristics

C.3.1  TLV Header

   Each object begins with a fixed header giving the object type and
   object length.  The bits marked 'A' and 'B' are extensibility flags
   which are defined below; the remaining bits marked 'r' are reserved.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|B|r|r|         Type          |r|r|r|r|        Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


C.3.2  Object Extensibility

   The leading two bits of the common TLV header are used to signal the
   desired treatment for objects whose treatment has not been defined in
   the protocol specification in question (i.e. whose Type field is
   unknown at the receiver).  The following four categories of object
   have been identified, and are loosely described here.

   AB=00 ("Mandatory"): If the object is not understood, the entire
      message containing it must be rejected with an error indication.

   AB=01 ("Ignore"): If the object is not understood, it should be
      deleted and then the rest of the message processed as usual.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 87]

Internet-Draft                    GIMPS                         May 2005


   AB=10 ("Forward"): If the object is not understood, it should be
      retained unchanged in any message forwarded as a result of message
      processing, but not stored locally.

   The combination AB=11 is reserved.  Note that the concept of
   retaining an unknown object and including it in refresh messages
   further up or down the signalling path does not apply to GIMPS, since
   refresh operations only take place between adjacent peers.

C.4  GIMPS TLV Objects

   In the following object diagrams, '//' is used to indicate a variable
   sized field and ':' is used to indicate a field that is optionally
   present.

C.4.1  Message-Routing-Information

   Type: Message-Routing-Information

   Length: Variable (depends on message routing method)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Message-Routing-Method        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   //     Method-specific addressing information (variable)       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


C.4.1.1  Path-Coupled MRM

   In the case of basic path-coupled routing, the addressing information
   takes the following format:


















Schulzrinne & Hancock    Expires November 18, 2005             [Page 88]

Internet-Draft                    GIMPS                         May 2005


                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |IP-Ver |P|T|F|S|A|B|D|Reserved |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       Source Address                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      Destination Address                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Prefix |  Dest Prefix  |   Protocol    | Traffic Class |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :       Reserved        |              Flow Label               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              SPI                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :          Source Port          :       Destination Port        :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The flags are:
   P - IP Protocol
   T - Traffic Class
   F - Flow Label
   S - SPI
   A - Source Port
   B - Destination Port
   D - Direction of message relative to MRI

   The contents of the Protocol field is only interpreted if P is set.
   The contents of the Traffic Class field is only interpreted if T is
   set.  The S/A/B flags can only be set if P is set.

   F may only be set if IP-Ver is 6.  If F is not set, the entire 32 bit
   word for the FLow Label is absent.

   If either of A, B is set, the word containing the port numbers is
   included in the object.  However, the contents of each field is only
   significant if the corresponding flag is set; otherwise, the contents
   of the field is regarded as padding, and the MRI refers to all ports
   (i.e. acts as a wildcard).  If the flag is set and Port=0x0000, the
   MRI will apply to a specific port, whose value is not yet known.  If
   neither of A or B is set, the word is absent.

   Likewise, the SPI field is only present if the S flag is set.

   The Direction flag has the following meaning: the value 0 means 'in
   the same direction as the flow' (or "downstream"), and the value 1
   means 'in the opposite direction to the flow' (or "upstream").






Schulzrinne & Hancock    Expires November 18, 2005             [Page 89]

Internet-Draft                    GIMPS                         May 2005


C.4.2  Session Identification

   Type: Session-Identification

   Length: Fixed (4 32-bit words)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                          Session ID                           +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


C.4.3  Network-Layer-Information

   Type: Network-Layer-Information

   Length: Variable (depends on length of Peer-Identity and IP version)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PI-Length   |    IP-TTL     |IP-Ver |        Reserved       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Routing State Validity Time                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       Peer Identity                         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     Interface Address                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PI-Length = the byte length of the Peer-Identity field
               (note that the Peer-Identity field itself is padded
               to a whole number of words)
   IP-TTL    = initial or reported IP-TTL
   IP-Ver    = the IP version for the Interface-Address field


C.4.4  Stack Proposal

   Type: Stack-Proposal






Schulzrinne & Hancock    Expires November 18, 2005             [Page 90]

Internet-Draft                    GIMPS                         May 2005


   Length: Variable (depends on number of profiles and size of each
      profile)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prof-Count   |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Profile 1                                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Profile 2                                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Prof-Count = The number of profiles in the proposal

   Each profile is itself a sequence of protocol layers, and the profile
   is formatted as a list as follows:

   o  The first byte is a count of the number of layers in the profile.

   o  This is followed by a sequence of 1-byte MA-Protocol-IDs as
      described in Section 5.6.

   o  The profile is padded to a word boundary with 0, 1, 2 or 3 zero
      bytes.


C.4.5  Stack-Configuration-Data

   Type: Stack-Configuration-Data

   Length: Variable (depends on number of protocols and size of each
      protocol configuration data)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    HL-Count   |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                Higher-Layer-Information 1                   //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                Higher-Layer-Information N                   //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   HL-Count  = the number of higher-layer-information fields
               (these contain their own length information)




Schulzrinne & Hancock    Expires November 18, 2005             [Page 91]

Internet-Draft                    GIMPS                         May 2005


   The higher layer information fields are formatted as follows:

   o  There is a 1-byte MA-Protocol-ID, as described in Section 5.6.

   o  There is a 1-byte length field defining the amount of
      configuration data that follows after the length field.

   o  There is a variable length of configuration data.

   o  There are 0, 1, 2, or 3 bytes of zero padding to the next word
      boundary.

   Note that the contents of the configuration data may differ depending
   on whether the object is in a GIMPS-Query or GIMPS-Response.

C.4.6  Query Cookie

   Type: Query-Cookie

   Length: Variable (selected by querying node)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        Query Cookie                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents are implementation defined.  See Section 8.5 for further
   discussion.

C.4.7  Responder Cookie

   Type: Responder-Cookie

   Length: Variable (selected by responding node)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Responder Cookie                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents are implementation defined.  See Section 8.5 for further
   discussion.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 92]

Internet-Draft                    GIMPS                         May 2005


C.4.8  NAT Traversal

   Type: NAT-Traversal

   Length: Variable (depends on length of contained fields)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MRI-Length    | Type-Count    | NAT-Count    |  Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //            Original Message-Routing-Information             //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                 List of translated objects                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length of opaque NLI info.    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
   //            NLI information replaced by NAT #1                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length of opaque NLI info.    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
   //            NLI information replaced by NAT #N                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MRI-Length = the word length of the included MRI payload
   Type-Count = the number of GIMPS payloads translated by the
                NAT; the Type numbers are included as a list
                (padded with 2 null bytes if necessary)
   NAT-Count  = the number of NATs traversed by the message, and the
                number of opaque NLI-related payloads at the end
                of the object


C.4.9  NSLP Data

   Type: NSLP-Data

   Length: Variable (depends on NSLP)


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                          NSLP Data                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Schulzrinne & Hancock    Expires November 18, 2005             [Page 93]

Internet-Draft                    GIMPS                         May 2005


C.4.10  Error Object

   Type: Error

   Length: Variable (depends on error)

   Value: Contains a 1 byte error class and 3 byte error code, and
      optionally variable length error-specific information.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Error Class |                   Error Code                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //             Optional error-specific information             //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first byte "Error Class" indicates the severity level.  The
   currently defined severity levels are:

   Informational: response data which should not be thought of as
      changing the condition of the protocol state machine.

   Success: response data which indicates that the message being
      responded to has been processed successfully in some sense.

   Protocol-Error: the message has been rejected because of a protocol
      error (e.g. an error in message format).

   Transient-Failure: the message has been rejected because of a
      particular local node status which may be transient (i.e. it may
      be worthwhile to retry after some delay).

   Permanent-Failure: the message has been rejected because of local
      node status which will not change without additional out of band
      (e.g. management) operations.

   Additional error class values are reserved.

   The allocation of error classes to particular errors is not precise;
   the above descriptions are deliberately informal.  Actually error
   processing should take into account the specific error in question;
   the error class may be useful supporting information (e.g. in network
   debugging).








Schulzrinne & Hancock    Expires November 18, 2005             [Page 94]

Internet-Draft                    GIMPS                         May 2005


Appendix D.  API between GIMPS and NSLP

D.1  API Concepts

   This appendix provides an initial abstract API between GIMPS and
   NSLPs.

   This does not constrain implementors, but rather helps clarify the
   interface between the different layers of the NSIS protocol suite.
   In addition, although some of the data types carry the information
   from GIMPS Information Elements, this does not imply that the format
   of that data as sent over the API has to be the same.

   Conceptually the API has similarities to the UDP sockets API,
   particularly that for unconnected UDP sockets.  An extension for an
   API like that for UDP connected sockets could be considered.  In this
   case, for example, the only information needed in a SendMessage
   primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
   (which can be null).  Other information which was persistent for a
   group of messages could be configured once for the socket.  Such
   extensions may make a concrete implementation more scalable and
   efficient but do not change the API semantics, and so are not
   considered further here.

D.2  SendMessage

   This primitive is passed from an NSLP to GIMPS.  It is used whenever
   the NSLP wants to send a message.

   SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
                 NSLP-Id, Session-ID, MRI,
                 Source-SII-Handle, Peer-SII-Handle,
                 Transfer-Attributes, Timeout, IP-TTL )

   The following arguments are mandatory.

   NSLP-Data: The NSLP message itself.

   NSLP-Data-Size: The length of NSLP-Data.

   NSLP-Message-Handle: A handle for this message, that can be used
      later by GIMPS to reference it in status reports (in particular,
      notification about what security attributes will be used for the
      message, or error notifications).  A NULL handle may be supplied
      if the NSLP is not interested in receiving MessageStatus
      notifications for this message.





Schulzrinne & Hancock    Expires November 18, 2005             [Page 95]

Internet-Draft                    GIMPS                         May 2005


   NSLP-Id: An identifier indicating which NSLP this is.

   Session-ID: The NSIS session identifier.  Note that it is assumed
      that the signaling application provides this to GIMPS rather than
      GIMPS providing a value itself.

   MRI: Message routing information for use by GIMPS in determining the
      correct next GIMPS hop for this message.  It contains, for
      example, the flow source/destination addresses and the type of
      routing to use for the signaling message.  The message routing
      information implies the message routing method to be used and also
      includes the direction of the message.

   The following arguments are optional.

   Source-SII-Handle: A handle, previously supplied by GIMPS in
      RecvMessage, which indicates that the NSLP wishes to originate the
      message as though it came from the identified source (e.g. so
      responses will be returned to that source).  Will cause an error
      if set with a large payload or non-trivial Transfer-Attributes.

   Peer-SII-Handle: A handle, previously supplied by GIMPS, to a data
      structure (identifying peer addresses and interfaces) that should
      be used to explicitly route the message to a particular GIMPS next
      hop.  If supplied, GIMPS should validate that it is consistent
      with the MRI.

   Transfer-Attributes: Attributes defining how the message should be
      handled (see Section 4.1.2).  The following attributes can be
      considered:

      Reliability: Values 'unreliable' (default) or 'reliable'.

      Security: This attribute allows the NSLP to specify what level of
         security protection is requested for the message (selected from
         'integrity' and 'confidentiality'), and can also be used to
         specify what authenticated signaling source and destination
         identities should be used to send the message.  The
         possibilities can be learned by the NSLP from prior
         MessageStatus or RecvMessage notifications.  If an NSLP-
         Message-Handle is provided, GIMPS will inform the NSLP of what
         values it has actually chosen for this attribute via a
         MessageStatus callback.  This might take place either
         synchronously (where GIMPS is just selecting from available
         messaging associations), or asynchronously (when a new
         messaging association needs to be created).





Schulzrinne & Hancock    Expires November 18, 2005             [Page 96]

Internet-Draft                    GIMPS                         May 2005


      Local Processing: This attribute contains hints from the NSLP
         about what local policy should be applied to the message; in
         particular, its transmission priority relative to other
         messages, or whether GIMPS should attempt to set up or maintain
         forward routing state.

   Timeout: Length of time GIMPS should attempt to send this message
      before indicating an error.

   IP-TTL: The value of the IP TTL that should be used when sending this
      message.


D.3  RecvMessage

   This primitive is passed from GIMPS to an NSLP.  It is used whenever
   GIMPS receives a message from the network.  This primitive can return
   a value from the NSLP which indicates whether the NSLP wishes GIMPS
   to retain message routing state.

   RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI,
                 SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance )

   NSLP-Data: The NSLP message itself (may be empty).

   NSLP-Data-Size: The length of NSLP-Data (may be zero).

   NSLP-Id: An identifier indicating which NSLP this is message is for.

   Session-ID: The NSIS session identifier.

   MRI: Message routing information that was used by GIMPS in forwarding
      this message.  It contains, for example, the flow source/
      destination addresses, the type of routing used for the signaling
      message, and the direction of the message relative to the MRI.
      Implicitly defines the message routing method that was used.

   SII-Handle: A handle to a data structure, identifying peer addresses
      and interfaces.  Can be used to identify route changes and for
      explicit routing to a particular GIMPS next hop.

   Transfer-Attributes: The reliability and security attributes that
      were associated with the reception of this particular message.  As
      well as the attributes associated with SendMessage, GIMPS may
      indicate the level of verification of the addresses in the MRI.
      Two flags can be indicated:





Schulzrinne & Hancock    Expires November 18, 2005             [Page 97]

Internet-Draft                    GIMPS                         May 2005


      *  Whether the signalling source address is one of the flow
         endpoints (i.e. whether this is the first or last GIMPS hop);

      *  Whether the signalling source address has been validated by a
         return routability check.

   IP-TTL: The value of the IP TTL (or Hop Limit) this message was
      received with (if available).

   IP-Distance: The number of IP hops from the peer signaling node which
      sent this message along the path, or 0 if this information is not
      available.


D.4  MessageStatus

   This primitive is passed from GIMPS to an NSLP.  It is used to notify
   the NSLP that a message that it requested to be sent has failed to be
   dispatched, or to inform the NSLP about the transfer attributes that
   have been selected for the message (specifically, security
   attributes).  The NSLP can respond to this message with a return code
   to abort the sending of the message if the attributes are not
   acceptable.

   MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type )

   NSLP-Message-Handle: A handle for the message provided by the NSLP at
      the time of sending.

   Transfer-Attributes: The reliability and security attributes that
      will be used to transmit this particular message.

   Error-Type: Indicates the type of error that occurred.  For example,
      'no next node found'.


D.5  NetworkNotification

   This primitive is passed from GIMPS to an NSLP.  It indicates that a
   network event of possible interest to the NSLP occurred.

   NetworkNotification ( MRI, Network-Notification-Type )

   MRI: Provides the message routing information to which the network
      notification applies.






Schulzrinne & Hancock    Expires November 18, 2005             [Page 98]

Internet-Draft                    GIMPS                         May 2005


   Network-Notification-Type: Indicates the type of event that caused
      the notification, e.g. downstream route change, upstream route
      change, detection that this is the last node.


D.6  SetStateLifetime

   This primitive is passed from an NSLP to GIMPS.  It indicates the
   lifetime for which GIMPS should retain its state.  It can also give a
   hint that the NSLP is no longer interested in the state.

   SetStateLifetime ( MRI, Direction, State-Lifetime )

   MRI: Provides the message routing information to which the network
      notification applies.

   Direction: A flag indicating whether this relates to state for the
      upstream or downstream direction (in relation to the MRI).

   State-Lifetime: Indicates the lifetime for which the NSLP wishes
      GIMPS to retain its state (may be zero, indicating that the NSLP
      has no further interest in the GIMPS state).


D.7  InvalidateRoutingState

   This primitive is passed from an NSLP to GIMPS.  It indicates that
   the NSLP has knowledge that the next signaling hop known to GIMPS may
   no longer be valid, either because of changes in the network routing
   or the processing capabilities of NSLP nodes.  It is an indication to
   GIMPS to restart the discovery process.

   InvalidateRoutingState ( NSLP-Id, MRI, Direction, Urgency )

   NSLP-Id: The NSLP originating the message.  May be null (in which
      case the invalidation applies to all signaling applications).

   MRI: The flow for which routing state should be invalidated.

   Direction: A flag indicating whether this relates to state for the
      upstream or downstream direction (in relation to the MRI).

   Urgency: A hint as to whether rediscovery should take place
      immediately, or only when the next signaling message is to be
      sent.






Schulzrinne & Hancock    Expires November 18, 2005             [Page 99]

Internet-Draft                    GIMPS                         May 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Schulzrinne & Hancock    Expires November 18, 2005            [Page 100]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/