idnits 2.17.1 

draft-ietf-nsis-ntlp-05.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 3929.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3906.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3913.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3919.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        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.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 3218 has weird spacing: '...   | ti   on  ...'

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (February 21, 2005) is 7004 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: 'Data' on line 216

  -- Looks like a reference, but probably isn't: 'Flow' on line 233

  == Unused Reference: '1' is defined on line 3041, but no explicit reference
     was found in the text

  == Unused Reference: '4' is defined on line 3049, but no explicit reference
     was found in the text

  == Unused Reference: '10' is defined on line 3072, but no explicit
     reference was found in the text

  == Unused Reference: '16' is defined on line 3091, but no explicit
     reference was found in the text

  == Unused Reference: '18' is defined on line 3099, but no explicit
     reference was found in the text

  == Unused Reference: '22' is defined on line 3113, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234)

  ** Obsolete normative reference: RFC 2765 (ref. '5') (Obsoleted by RFC 6145)

  ** Obsolete normative reference: RFC 2960 (ref. '6') (Obsoleted by RFC 4960)

  == Outdated reference: A later version (-13) exists of
     draft-ietf-dccp-spec-09

  == Outdated reference: A later version (-07) exists of
     draft-ietf-ipngwg-icmp-v3-06

  -- Possible downref: Normative reference to a draft: ref. '8' 

  -- Obsolete informational reference (is this intentional?): RFC 2409 (ref.
     '10') (Obsoleted by RFC 4306)

  -- Obsolete informational reference (is this intentional?): RFC 2766 (ref.
     '12') (Obsoleted by RFC 4966)

  -- Obsolete informational reference (is this intentional?): RFC 3068 (ref.
     '14') (Obsoleted by RFC 7526)

  -- Obsolete informational reference (is this intentional?): RFC 3489 (ref.
     '19') (Obsoleted by RFC 5389)

  == Outdated reference: A later version (-25) exists of
     draft-ietf-nsis-nslp-natfw-04

  == Outdated reference: A later version (-18) exists of
     draft-ietf-nsis-qos-nslp-05

  == Outdated reference: A later version (-07) exists of
     draft-ietf-v6ops-mech-v2-06

  == Outdated reference: A later version (-22) exists of
     draft-ietf-secsh-architecture-21

  == Outdated reference: A later version (-10) exists of
     draft-ietf-hip-base-01

  == Outdated reference: A later version (-03) exists of
     draft-ietf-mip6-ro-sec-02

  == Outdated reference: A later version (-04) exists of
     draft-bound-dstm-exp-02

  == Outdated reference: A later version (-02) exists of
     draft-stiemerling-nsis-natfw-mrm-01


     Summary: 9 errors (**), 0 flaws (~~), 19 warnings (==), 14 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Next Steps in Signaling                                   H. Schulzrinne
3	Internet-Draft                                               Columbia U.
4	Expires: August 25, 2005                                      R. Hancock
5	                                                             Siemens/RMR
6	                                                       February 21, 2005

8	       GIMPS:  General Internet Messaging Protocol for Signaling
9	                        draft-ietf-nsis-ntlp-05

11	Status of this Memo

13	   This document is an Internet-Draft and is subject to all provisions
14	   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
15	   author represents that any applicable patent or other IPR claims of
16	   which he or she is aware have been or will be disclosed, and any of
17	   which he or she become aware will be disclosed, in accordance with
18	   RFC 3668.

20	   Internet-Drafts are working documents of the Internet Engineering
21	   Task Force (IETF), its areas, and its working groups.  Note that
22	   other groups may also distribute working documents as
23	   Internet-Drafts.

25	   Internet-Drafts are draft documents valid for a maximum of six months
26	   and may be updated, replaced, or obsoleted by other documents at any
27	   time.  It is inappropriate to use Internet-Drafts as reference
28	   material or to cite them other than as "work in progress."

30	   The list of current Internet-Drafts can be accessed at
31	   http://www.ietf.org/ietf/1id-abstracts.txt.

33	   The list of Internet-Draft Shadow Directories can be accessed at
34	   http://www.ietf.org/shadow.html.

36	   This Internet-Draft will expire on August 25, 2005.

38	Copyright Notice

40	   Copyright (C) The Internet Society (2005).

42	Abstract

44	   This document specifies protocol stacks for the routing and transport
45	   of per-flow signaling messages along the path taken by that flow
46	   through the network.  The design uses existing transport and security
47	   protocols under a common messaging layer, the General Internet
48	   Messaging Protocol for Signaling (GIMPS), which provides a universal
49	   service for diverse signaling applications.  GIMPS does not handle
50	   signaling application state itself, but manages its own internal
51	   state and the configuration of the underlying transport and security
52	   protocols to enable the transfer of messages in both directions along
53	   the flow path.  The combination of GIMPS and the lower layer
54	   transport and security protocols provides a solution for the base
55	   protocol component of the "Next Steps in Signaling" framework.

57	Table of Contents

59	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
60	     1.1  Restrictions on Scope  . . . . . . . . . . . . . . . . . .   5
61	   2.   Requirements Notation and Terminology  . . . . . . . . . . .   6
62	   3.   Design Overview  . . . . . . . . . . . . . . . . . . . . . .   8
63	     3.1  Overall Design Approach  . . . . . . . . . . . . . . . . .   8
64	     3.2  Example of Operation . . . . . . . . . . . . . . . . . . .  10
65	   4.   GIMPS Processing Overview  . . . . . . . . . . . . . . . . .  14
66	     4.1  GIMPS Service Interface  . . . . . . . . . . . . . . . . .  14
67	     4.2  GIMPS State  . . . . . . . . . . . . . . . . . . . . . . .  16
68	     4.3  Basic Message Processing . . . . . . . . . . . . . . . . .  18
69	     4.4  Routing State and Messaging Association Maintenance  . . .  22
70	   5.   Message Formats and Transport  . . . . . . . . . . . . . . .  28
71	     5.1  GIMPS Messages . . . . . . . . . . . . . . . . . . . . . .  28
72	     5.2  Information Elements . . . . . . . . . . . . . . . . . . .  29
73	     5.3  Datagram Mode Transport  . . . . . . . . . . . . . . . . .  33
74	     5.4  Connection Mode Transport  . . . . . . . . . . . . . . . .  38
75	     5.5  Messaging Association Negotiation  . . . . . . . . . . . .  40
76	   6.   Advanced Protocol Features . . . . . . . . . . . . . . . . .  43
77	     6.1  Route Changes and Local Repair . . . . . . . . . . . . . .  43
78	     6.2  Policy-Based Forwarding and Flow Wildcarding . . . . . . .  49
79	     6.3  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  49
80	     6.4  Interaction with IP Tunnelling . . . . . . . . . . . . . .  51
81	     6.5  IPv4-IPv6 Transition and Interworking  . . . . . . . . . .  52
82	   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  54
83	     7.1  Message Confidentiality and Integrity  . . . . . . . . . .  54
84	     7.2  Peer Node Authentication . . . . . . . . . . . . . . . . .  55
85	     7.3  Routing State Integrity  . . . . . . . . . . . . . . . . .  55
86	     7.4  Denial of Service Prevention . . . . . . . . . . . . . . .  57
87	   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  59
88	   9.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  61
89	     9.1  Additional Discovery Mechanisms  . . . . . . . . . . . . .  61
90	     9.2  Alternative Message Routing Requirements . . . . . . . . .  61
91	     9.3  Message Format Issues  . . . . . . . . . . . . . . . . . .  62
92	   10.  Change History . . . . . . . . . . . . . . . . . . . . . . .  64
93	     10.1   Changes In Version -05 . . . . . . . . . . . . . . . . .  64
94	     10.2   Changes In Version -04 . . . . . . . . . . . . . . . . .  65
95	     10.3   Changes In Version -03 . . . . . . . . . . . . . . . . .  66
96	     10.4   Changes In Version -02 . . . . . . . . . . . . . . . . .  67
97	     10.5   Changes In Version -01 . . . . . . . . . . . . . . . . .  68
98	   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  71
99	     11.1   Normative References . . . . . . . . . . . . . . . . . .  71
100	     11.2   Informative References . . . . . . . . . . . . . . . . .  71
101	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  73
102	   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  74
103	   B.   Example Message Routing State Table  . . . . . . . . . . . .  75
104	   C.   Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . .  77
105	     C.1  General NSIS Formatting Guidelines . . . . . . . . . . . .  77
106	     C.2  The GIMPS Common Header  . . . . . . . . . . . . . . . . .  78
107	     C.3  General Object Characteristics . . . . . . . . . . . . . .  78
108	     C.4  GIMPS Specific TLV Objects . . . . . . . . . . . . . . . .  79
109	     C.5  Generic NSIS TLV Objects . . . . . . . . . . . . . . . . .  85
110	   D.   API between GIMPS and NSLP . . . . . . . . . . . . . . . . .  87
111	     D.1  SendMessage  . . . . . . . . . . . . . . . . . . . . . . .  87
112	     D.2  RecvMessage  . . . . . . . . . . . . . . . . . . . . . . .  89
113	     D.3  MessageStatus  . . . . . . . . . . . . . . . . . . . . . .  90
114	     D.4  NetworkNotification  . . . . . . . . . . . . . . . . . . .  90
115	     D.5  SetStateLifetime . . . . . . . . . . . . . . . . . . . . .  90
116	     D.6  InvalidateRoutingState . . . . . . . . . . . . . . . . . .  91
117	        Intellectual Property and Copyright Statements . . . . . . .  92

119	1.  Introduction

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

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

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

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

154	   This specification provides a concrete solution for the NTLP.  It is
155	   based on the use of existing transport and security protocols under a
156	   common messaging layer, the General Internet Messaging Protocol for
157	   Signaling (GIMPS).  Different signaling applications may make use of
158	   different services provided by GIMPS.  However, GIMPS does not handle
159	   signaling application state itself; in that crucial respect, it
160	   differs from application signaling protocols such as the control
161	   component of FTP, SIP and RTSP.  Instead, GIMPS manages its own
162	   internal state and the configuration of the underlying transport and
163	   security protocols to ensure the transfer of signaling messages on
164	   behalf of signaling applications in both directions along the flow
165	   path.

167	1.1  Restrictions on Scope

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

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

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

186	2.  Requirements Notation and Terminology

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

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

196	   Source                GIMPS (adjacent) peer nodes         Destination

198	   IP address              IP addresses = Signaling          IP address
199	   = Flow                Source/Destination Addresses        = Flow
200	   Source             (depending on signaling direction)     Destination
201	   Address                  |                   |            Address
202	                            V                   V
203	   +--------+           +------+  Data Flow  +------+         +--------+
204	   |  Flow  |-----------|------|-------------|------|-------->|  Flow  |
205	   | Sender |           |      |             |      |         |Receiver|
206	   +--------+           |GIMPS |============>|GIMPS |         +--------+
207	                        | Node |<============| Node |
208	                        +------+  Signaling  +------+
209	                          GN1       Flow       GN2

211	                  >>>>>>>>>>>>>>>>>  =  Downstream direction
212	                  <<<<<<<<<<<<<<<<<  =  Upstream direction

214	                      Figure 1: Basic Terminology

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

220	   Session: A single application layer flow of information for which
221	      some network control state information is to be manipulated or
222	      monitored.  IP mobility may cause the mapping between sessions and
223	      flows to change, and IP multihoming may mean there is more than
224	      one flow for a given session.  GIMPS implements the session
225	      concept by allowing signaling applications to associate messages
226	      with a Session Identifier; however, GIMPS does not place any
227	      constraints on how this association should be done.

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

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

236	   Downstream: In the same direction as the data flow.

238	   Upstream: In the opposite direction to the data flow.

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

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

250	   Datagram mode: A mode of sending GIMPS messages between nodes without
251	      using any transport layer state or security protection.  Datagram
252	      mode uses UDP encapsulation, with IP addresses derived either from
253	      the flow definition or previously discovered adjacency
254	      information; the details depend on the direction of the message.

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

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

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

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

282	3.  Design Overview

284	3.1  Overall Design Approach

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

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

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

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

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

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

327	   Internally, GIMPS has two modes of operation:

329	   Datagram mode is used for small, infrequent messages with modest
330	      delay constraints; it is also used at least for the Query message
331	      of the 3-way handshake.

333	   Connection mode is used for larger data objects or where fast state
334	      setup in the face of packet loss is desirable, or where channel
335	      security is required.

337	          ^^                       +-------------+
338	          ||                       |  Signaling  |
339	         NSIS         +------------|Application 2|
340	       Signaling      |  Signaling +-------------+
341	      Application     |Application 1|         |
342	         Level        +-------------+         |
343	          ||              |                   |
344	          VV              |                   |
345	                 =========|===================|=====  <-- GIMPS API
346	                          |                   |
347	          ^^        +------------------------------------------------+
348	          ||        |+-----------------------+      +--------------+ |
349	          ||        ||         GIMPS         |      | GIMPS State  | |
350	          ||        ||     Encapsulation     |<<<>>>| Maintenance  | |
351	          ||        |+-----------------------+      +--------------+ |
352	          ||        |GIMPS: Messaging Layer                          |
353	          ||        +------------------------------------------------+
354	         NSIS               |       |       |       |
355	       Transport          .............................
356	         Level            . Transport Layer Security  .
357	       ("NTLP")           .............................
358	          ||                |       |       |       |
359	          ||              +----+  +----+  +----+  +----+
360	          ||              |UDP |  |TCP |  |SCTP|  |DCCP|....
361	          ||              +----+  +----+  +----+  +----+
362	          ||                |       |       |       |
363	          ||              .............................
364	          ||              .     IP Layer Security     .
365	          ||              .............................
366	          VV                |       |       |       |
367	   =========================|=======|=======|=======|===============
368	                            |       |       |       |
369	                    +----------------------------------------------+
370	                    |                      IP                      |
371	                    +----------------------------------------------+

373	           Figure 2: Protocol Stacks for Signaling Transport

375	   Datagram mode uses UDP, as this is the only encapsulation which does
376	   not require shared state to be established between the peers.  The
377	   connection mode can in principal use any stream or message-oriented
378	   transport protocol; this specification currently defines the use of
379	   TCP as the initial choice.  It may employ specific network layer
380	   security associations (such as IPsec), or an internal transport layer
381	   security association (such as TLS).

383	   It is possible to mix these two modes along a chain of nodes, without
384	   coordination or manual configuration.  This allows, for example, the
385	   use of datagram mode at the edges of the network and connection mode
386	   in the core of the network.  Such combinations may make operation
387	   more efficient for mobile endpoints, while allowing multiplexing of
388	   signaling messages across shared security associations and transport
389	   connections between core routers.

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

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

413	3.2  Example of Operation

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

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

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

435	   2.  The message payload is passed to the GIMPS layer in GN1, along
436	       with a definition of the flow and description of the message
437	       transfer attributes {downstream, unsecured, unreliable}.  GIMPS
438	       determines that this particular message does not require
439	       fragmentation and that it has no knowledge of the next peer for
440	       this flow and signaling application; however, it also determines
441	       that this application is likely to require secured upstream and
442	       downstream transport of large messages in the future.  This
443	       determination is a function of node-local policy, and some
444	       options for how it may be communicated between NSLP and GIMPS
445	       implementations within a node are indicated in Appendix D.

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

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

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

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

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

481	       B.  No messaging association exists.  Again, GN2 records the
482	           identity of GN1 as before, but sends a GIMPS-Response
483	           upstream to GN1, identifying itself and agreeing to the
484	           association setup.  The protocol exchanges needed to complete
485	           this will proceed in the background, controlled by GN1.

487	   7.  Eventually, another signaling application message works its way
488	       upstream from the receiver to GN2.  This message contains a
489	       description of the actual resources requested, along with
490	       authorisation and other security information.  The signaling
491	       application in GN2 passes this payload to the GIMPS level, along
492	       with the flow definition and transfer attributes {upstream,
493	       secured, reliable}.

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

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

508	   Note that when GIMPS messages are carried in connection mode, they
509	   are treated just like any other traffic by intermediate routers
510	   between the GIMPS peers.  Indeed, it would be impossible for
511	   intermediate routers to carry out any processing on the messages
512	   without terminating the transport and security protocols used.  In
513	   connection mode, signaling messages are only ever delivered between
514	   peers established in GIMPS-Query/Response exchanges.  Any route
515	   change is not detected until another GIMPS-Query/Response procedure
516	   takes place; in the meantime, signaling messages are misdelivered.
517	   GIMPS is responsible for prompt detection of route changes to
518	   minimise the period during which this can take place.

520	   It should be understood that several of these details of GIMPS
521	   operations can be varied, either by local policy or according to
522	   signaling application requirements, and they are also subject to
523	   development and refinement as the protocol design proceeds.  The
524	   authoritative details are contained in the remainder of this
525	   document.

527	4.  GIMPS Processing Overview

529	   This section defines the basic structure and operation of GIMPS.  It
530	   is divided into four parts.  Section 4.1 describes the way in which
531	   GIMPS interacts with (local) signaling applications in the form of an
532	   abstract service interface.  Section 4.2 describes the per-flow and
533	   per-peer state that GIMPS maintains for the purpose of transferring
534	   messages.  Section 4.3 describes how messages are processed in the
535	   case where any necessary messaging associations and associated
536	   routing state already exist; this includes the simple scenario of
537	   pure datagram mode operation, where no messaging associations are
538	   necessary in the first place.  Finally, Section 4.4 describes how
539	   routing state is maintained and how messaging associations are
540	   initiated and terminated.

542	4.1  GIMPS Service Interface

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

558	4.1.1  Message Handling

560	   Fundamentally, GIMPS provides a simple message-by-message transfer
561	   service for use by signaling applications: individual messages are
562	   sent, and individual messages are received.  Messages consist of an
563	   opaque signaling application payload, and control information
564	   expressing the application's requirements about how the message
565	   should be routed.  Additional message transfer attributes control the
566	   specific transport and security properties that the signaling
567	   application desires for the message.

569	   The distinction between GIMPS connection and datagram modes is not
570	   visible at the service interface.  In addition, the invocation of
571	   GIMPS functionality to handle fragmentation and reassembly, bundling
572	   together of small messages (for efficiency), and congestion control
573	   are not directly visible at the service interface; GIMPS will take
574	   whatever action is necessary based on the properties of the messages
575	   and local node state.

577	   Messages for different sessions (i.e.  with different Session IDs,
578	   see Section 4.2.1) are treated entirely independently of each other
579	   by GIMPS.  Messages for the same session which are to be delivered
580	   reliably (see below) to the same peer will be delivered in order.  If
581	   the receiving application delays reading these messages, this will
582	   (eventually) cause a flow-control condition at the sending node.

584	4.1.2  Message Transfer Attributes

586	   Message transfer attributes are used to define certain
587	   performance-related aspects of message processing.  The attributes
588	   available are as follows:

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

599	   Security: This attribute defines the security properties that the
600	      signaling application requires for the message, including the type
601	      of protection required, and what authenticated identities should
602	      be used for the signaling source and destination.  This
603	      information maps onto the corresponding properties of the security
604	      associations established between the peers in connection mode, It
605	      can be specified explicitly by the signaling application, or
606	      reported by GIMPS to the signaling application (either on
607	      receiving a message, or just before sending a message but after
608	      configuring or selecting the messaging association to be used for
609	      it).  Further details are discussed in Appendix D.

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

622	4.2  GIMPS State

624	4.2.1  Message Routing State

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

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

634	   Message Routing Information (MRI): This defines the method to be used
635	      to route the message, and any associated addressing information.
636	      In the commonest case, the message routing method is to follow the
637	      path that is being taken by the data flow, and the associated
638	      addressing is the flow header N-tuple (i.e.  the Flow-Identifier
639	      of [20]).  Other message routing methods are possible, as
640	      described for example in [29].

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

648	   Session Identification (SID): This is a cryptographically random and
649	      (probabilistically) globally unique identifier of the application
650	      layer session that is using the flow.  For a given flow, different
651	      signaling applications may or may not use the same session
652	      identifier.  Often there will only be one flow for a given
653	      session, but in mobility/multihoming scenarios there may be more
654	      than one and they may be differently routed.

656	   For a given MRI and NSLPID the message routing state should not be
657	   SID-dependent.  The SID is included in the key as a barrier to
658	   routing state being corrupted by a malicious upstream node.

660	   The state information for a given key consists of two items, namely
661	   the information needed to send messages to the peers in each
662	   direction respectively.  In each case, the information could be an IP
663	   address and UDP port, or a pointer to a valid messaging association,
664	   either of which can be learned from a prior GIMPS handshake.
665	   Additional information about the number of IP hops to the peer is
666	   also stored in the table for each direction.  An example of a routing
667	   state table for a simple scenario is given in Appendix B.

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

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

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

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

682	   In addition, the SID itself is not actually required for message
683	   processing; in that case, no state information at all needs to be
684	   stored in the table.

686	   Both items of state have associated timers for how long the
687	   identification can be considered accurate; when these timers expire,
688	   the peer identification is purged if it has not been refreshed.
689	   Message routing state is installed and refreshed by the exchange of
690	   GIMPS-Query/Response messages as described in Section 4.4.  For a
691	   given flow, the GIMPS node which initiated the state setup is
692	   responsible for scheduling a Query/Response exchange to refresh it,
693	   and to allow its peer to do likewise.  This should be done while
694	   GIMPS determines the signaling application is still active.  GIMPS
695	   may opportunistically synchronise these 'internal' refresh operations
696	   with those in the signaling application if it wishes.

698	   Note also that the information is described as a table of flows, but
699	   that there is no implied constraint on how the information is stored.
700	   For example, in a network using pure destination address routing
701	   (without load sharing or any form of policy-based forwarding), the
702	   downstream peer information might be possible to store in an
703	   aggregated form in the same manner as the IP forwarding table.  In
704	   addition, many of the per-flow entries may point to the same per-peer
705	   state (e.g.  the same messaging association) if the flows go through
706	   the same adjacent peer.  However, in general, and especially if GIMPS
707	   peers are several IP hops away, there is no way to identify the
708	   correct downstream peer for a flow and signaling application from the
709	   local forwarding table using prefix matching, and the same applies
710	   always to upstream peer state because of the possibility of
711	   asymmetric routing: per-flow routing state has to be stored, just as
712	   for RSVP [9].

714	4.2.2  Messaging Association State

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

722	   o  messages pending transmission while an association is being
723	      established;

725	   o  an inactivity timer for how long the association has been idle.

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

732	4.3  Basic Message Processing

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

744	   Note that the same messages are used both for maintaining internal
745	   GIMPS state and carrying signaling application payloads.  The state
746	   maintenance takes place as a result of processing specific GIMPS
747	   payloads in these messages.  The processing of these payloads is the
748	   subject of Section 4.4.

750	4.3.1  Message Reception

752	   Messages can be received in connection or datagram mode, and from
753	   upstream or downstream peers.

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

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

770	       +---------------------------------------------------------+
771	       |        >>  Signaling Application Processing   >>        |
772	       |                                                         |
773	       +--------^---------------------------------------V--------+
774	                ^                                       V
775	                ^             NSLP Payloads             V
776	                ^                                       V
777	       +--------^---------------------------------------V--------+
778	       |                    >>    GIMPS   >>                     |
779	       |  ^           ^  ^     Processing      V  V           V  |
780	       +--x-----------N--Q---------------------Q--N-----------x--+
781	          x           N  Q                     Q  N           x
782	          x           N  Q>>>>>>>>>>>>>>>>>>>>>Q  N           x
783	          x           N  Q      Bypass at      Q  N           x
784	       +--x-----+  +--N--Q--+  GIMPS level  +--Q--N--+  +-----x--+
785	       | C-mode |  | D-mode |               | D-mode |  | C-mode |
786	       |Handling|  |Handling|               |Handling|  |Handling|
787	       +--x-----+  +--N--Q--+               +--Q--N--+  +-----x--+
788	          x          N   Q                     Q   N          x
789	          x    NNNNNN    Q>>>>>>>>>>>>>>>>>>>>>Q    NNNNNN    x
790	          x   N          Q      Bypass at      Q          N   x
791	       +--x--N--+  +-----Q--+    router     +--Q-----+  +--N--x--+
792	       |IP Host |  |  RAO   |  alert level  |  RAO   |  |IP Host |
793	       |Handling|  |Handling|               |Handling|  |Handling|
794	       +--x--N--+  +-----Q--+               +--Q-----+  +--N--x--+
795	          x  N           Q                     Q           N  x
796	       +--x--N-----------Q--+               +--Q-----------N--x--+
797	       |      IP Layer      |               |      IP Layer      |
798	       |   (Receive Side)   |               |  (Transmit Side)   |
799	       +--x--N-----------Q--+               +--Q-----------N--x--+
800	          x  N           Q                     Q           N  x
801	          x  N           Q                     Q           N  x
802	          x  N           Q                     Q           N  x

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

810	              Figure 3: Message Paths through a GIMPS Node

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

820	4.3.2  Local Processing

822	   Once a message has been received, by any method, it is processed
823	   locally within the GIMPS layer.  The GIMPS processing to be done
824	   depends on the payloads carried; most of the GIMPS-internal payloads
825	   are associated with state maintenance and are covered in Section 4.4.

827	   One GIMPS-internal payload which is carried in each message and
828	   requires processing is the GIMPS hop count.  This is decremented on
829	   input processing, and checked to be greater than zero on output
830	   processing.  The primary purpose of the GIMPS hop count is to prevent
831	   message looping.

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

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

843	4.3.3  Message Transmission

845	   When a message is available for transmission, GIMPS uses internal
846	   policy and the stored routing state to determine how to handle it.
847	   The following processing applies equally to locally generated
848	   messages and messages forwarded from within the GIMPS or signaling
849	   application levels.

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

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

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

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

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

870	   If the use of a messaging association is selected, the message is
871	   queued on the association (found from the upstream or downstream peer
872	   state table), and further output processing is carried out according
873	   to the details of the protocol stack used for the association.  If no
874	   appropriate association exists, the message is queued while one is
875	   created (see Section 4.4).  If no association can be created, this is
876	   an error condition, and should be indicated back to the NSLP.

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

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

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

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

896	4.3.4  Bypass Forwarding

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

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

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

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

918	   In all cases, the role of GIMPS is to forward the message essentially
919	   unchanged.  However, a GIMPS implementation must ensure that the IP
920	   TTL field and GIMPS hop count are managed correctly to prevent
921	   message looping, and this should be done consistently independently
922	   of whether the processing (e.g.  for case (1)) takes place on the
923	   fast path or in GIMPS-specific code.  The rules are that in cases (1)
924	   and (2), the IP TTL is decremented just as if the message was a
925	   normal IP forwarded packet; in cases (2) and (3) the GIMPS hop count
926	   is decremented as in the case of normal input processing.  These
927	   rules are summarised in the following table:

929	   +-------------+-------------+-------------------+-------------------+
930	   |  Match RAO? |    Match    |  IP TTL Handling  |    GHC Handling   |
931	   |             |   NSLPID?   |                   |                   |
932	   +-------------+-------------+-------------------+-------------------+
933	   |      No     | N/A (NSLPID |     Decrement;    |       Ignore      |
934	   |             |     not     |  forward message  |                   |
935	   |             |  examined)  |                   |                   |
936	   |             |             |                   |                   |
937	   |     Yes     |      No     |     Decrement;    |    Decremented    |
938	   |             |             |  forward message  |                   |
939	   |             |             |                   |                   |
940	   |   Message   |      No     |       Reset       |   Decrement and   |
941	   |   directly  |             |                   |  forward at GIMPS |
942	   |  addressed  |             |                   |     level (not    |
943	   |             |             |                   |    possible in    |
944	   |             |             |                   |      current      |
945	   |             |             |                   |   specification)  |
946	   |             |             |                   |                   |
947	   |   Yes, or   |     Yes     | Locally delivered |   N/A (ignored)   |
948	   |   message   |             |                   |                   |
949	   |   directly  |             |                   |                   |
950	   |  addressed  |             |                   |                   |
951	   +-------------+-------------+-------------------+-------------------+

953	4.4  Routing State and Messaging Association Maintenance

955	   The main responsibility of the GIMPS layer is to manage the routing
956	   state and messaging associations which are used in the basic message
957	   processing described above.  Routing state is installed and
958	   maintained by datagram mode messages containing specific GIMPS
959	   payloads.  Messaging associations are dependent on the existence of
960	   routing state, but are actually set up by the normal procedures of
961	   the transport and security protocols that comprise them.  Timers
962	   control routing state and messaging association refresh and
963	   expiration.

965	   There are two different cases for state installation and refresh:

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

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

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

976	4.4.1  State Setup

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

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

994	   In the responding node, the GIMPS level processing of the GIMPS-Query
995	   triggers the generation of a 'GIMPS-Response' message.  This is a
996	   'normally' encapsulated datagram mode message with additional
997	   payloads.  It contains addressing information about the responding
998	   node, it echoes the Query Cookie, and can contain an NSLP payload
999	   (possibly a response to the NSLP payload in the initial message).  In
1000	   case a messaging association was requested, it must also contain a
1001	   Responder Cookie and counter proposal for the stack configuration.
1002	   Otherwise, it may still include a Responder Cookie if the node's
1003	   routing state setup policy requires it (see below).

1005	            +----------+                     +----------+
1006	            | Querying |                     |Responding|
1007	            |   Node   |                     |   Node   |
1008	            +----------+                     +----------+
1009	                             GIMPS-query
1010	                       ---------------------->    .............
1011	                       Router Alert Option        .  Routing  .
1012	                       MRI/SID/NSLPID             .   state   .
1013	                       Q-Node Addressing          . installed .
1014	                       Query Cookie               .    at     .
1015	                       [Q-Stack Proposal]         . R-node(1) .
1016	                       [NSLP Payload]             .............

1018	               ......................................
1019	               .  The responder can use an existing .
1020	               . messaging association if available .
1021	               . from here onwards to short-circuit .
1022	               .     messaging association setup    .
1023	               ......................................

1025	                           GIMPS-response
1026	   .............       <----------------------
1027	   .  Routing  .       MRI/SID/NSLPID
1028	   .   state   .       R-Node Addressing (D Mode only)
1029	   . installed .       Query cookie
1030	   .    at     .       [R-Stack Proposal]
1031	   .  Q-node   .       [Responder Cookie]
1032	   .............       [NSLP Payload]

1034	                ....................................
1035	                . If a messaging association needs .
1036	                . to be created, it is set up here .
1037	                ....................................

1039	                           GIMPS-confirm
1040	                       ---------------------->
1041	                       MRI/SID/NSLPID
1042	                       Q-Node Addressing (D Mode only)
1043	                       Responder Cookie           .............
1044	                       [R-Stack Proposal]         .  Routing  .
1045	                       [NSLP Payload]             .   state   .
1046	                                                  . installed .
1047	                                                  .    at     .
1048	                                                  . R-node(2) .
1049	                                                  .............

1051	               Figure 4: Message Sequence at State Setup

1053	   Setup of a new messaging association begins when both peer addressing
1054	   information is available at the Querying node, and a new messaging
1055	   association is actually needed.  The setup has to be contemporaneous
1056	   with a specific GIMPS-Query/Response exchange, because the addressing
1057	   information used may have a limited lifetime (either because it
1058	   depends on limited lifetime NAT bindings, or because it refers to
1059	   agile destination ports for the transport protocols).  Setup of the
1060	   messaging association always starts from the Querying node, but the
1061	   association itself can be used equally in both directions.

1063	   The GIMPS-Confirm is the first message sent over the association and
1064	   echoes the Responder Cookie and Stack Proposal from the
1065	   GIMPS-Response (the latter is to prevent certain bidding-down attacks
1066	   on messaging association security); the assocation can be used in the
1067	   upstream direction for that flow and NSLPID after the Confirm has
1068	   been received.  The negotiation of what protocols to use for the
1069	   messaging association is controlled by the Stack-Proposal and
1070	   Node-Addressing information exchanged, and the processing of these
1071	   objects is described in more detail in Section 5.5.

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

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

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

1082	   The detailed constraints on precisely when state information is
1083	   installed are driven by local policy driven by security
1084	   considerations on prevention of denial-of-service attacks and state
1085	   poisoning attacks, which are discussed further in Section 7.

1087	4.4.2  Association Re-use

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

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

1105	   Association re-use is controlled by two fields in the Node-Addressing
1106	   object (NAO), which is carried in GIMPS-query and GIMPS-response
1107	   messages.  The NAO includes:

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

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

1122	   By default, a messaging association is associated with the NAO that
1123	   was provided by the peer at the time the assocation was set up.
1124	   There may be more than one association for a given NAO (e.g.  with
1125	   different properties).

1127	   Association re-use is controlled by matching the NAO provided in a
1128	   GIMPS message with those associated with existing associations.  This
1129	   can be done on receiving either a GIMPS-Query or GIMPS-Response (the
1130	   former is more likely):

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

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

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

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

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

1159	      4.  The full NAO matches: this is a degenerate case, where one
1160	          node recognises an existing peer, but wishes to allow the
1161	          option to set up a new association in any case.

1163	4.4.3  Background Maintenance

1165	   Refresh and expiration of all types of state is controlled by timers.
1166	   State in the routing table has a per-flow, per-direction timer, which
1167	   expires after a routing state lifetime.  It is the responsibility of
1168	   the Querying node to generate a GIMPS-Query message before this timer
1169	   expires, if it believes that the flow is still active.  Receipt of
1170	   the message at the responding node will refresh peer addressing state
1171	   for one direction, and receipt of a GIMPS-Response at the querying
1172	   node will refresh it for the other.  Note that responding nodes do
1173	   not control the refresh of routing state themselves, they are
1174	   dependent on their peer for this.

1176	   Messaging associations can be managed by either end; management
1177	   consists of tearing down unneeded associations.  Whether an
1178	   association is needed is a local policy decision, which could take
1179	   into account the cost of keeping the messaging association open, the
1180	   level of past activity on the association, and the likelihood of
1181	   future activity (e.g.  if there are flows still in place which might
1182	   generate messages that would use it).  Messaging associations can
1183	   always be set up on demand, and messaging association status is not
1184	   made directly visible outside the GIMPS layer.  Therefore, even if
1185	   GIMPS tears down and later re-establishes a messaging association,
1186	   signaling applications cannot distinguish this from the case where
1187	   the association is kept permanently open.  (To maintain the transport
1188	   semantics decribed in Section 4.1, GIMPS must close transport
1189	   connections carrying reliable messages gracefully or report an error
1190	   condition, and must not open a new association for a given session
1191	   and peer while messages on a previous association may still be
1192	   outstanding.)

1194	5.  Message Formats and Transport

1196	5.1  GIMPS Messages

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

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

1209	   GIMPS-Message: A message is either a one of the stages in the 3-way
1210	   handshake, or a simple message carrying NSLP data.

1212	       GIMPS-Message = GIMPS-Query / GIMPS-Response /
1213	                       GIMPS-Confirm / GIMPS-Data

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

1221	       GIMPS-Query = Common-Header
1222	                     Message-Routing-Information
1223	                     Session-Identification
1224	                     Node-Addressing
1225	                     Query-Cookie
1226	                     [ Stack-Proposal ]
1227	                     [ Routing-State-Lifetime ]
1228	                     [ NSLP-Data ]

1230	   GIMPS-Response: A GIMPS-Response may be sent in datagram or
1231	   connection mode (if a messaging association is being re-used).  It
1232	   echoes the MRI, SID and Query-Cookie of the Query, and carries its
1233	   own Node-Addresing information; if the message exchange relates to
1234	   setup of a messaging association (which can only take place in
1235	   datagram mode), a Responder cookie is mandatory, and it must also
1236	   contain its own Stack-Proposal.

1238	       GIMPS-Response = Common-Header
1239	                        Message-Routing-Information
1240	                        Session-Identification
1241	                        Node-Addressing
1242	                        Query-Cookie
1243	                        [ Responder-Cookie [ Stack-Proposal ] ]
1244	                        [ Routing-State-Lifetime ]
1245	                        [ NSLP-Data ]

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

1255	       GIMPS-Confirm = Common-Header
1256	                       Message-Routing-Information
1257	                       Session-Identification
1258	                       Node-Addressing
1259	                       Responder-Cookie
1260	                       [ Stack-Proposal ]
1261	                       [ Routing-State-Lifetime ]
1262	                       [ NSLP-Data ]

1264	   GIMPS-Data: A plain data message contains no control objects, but
1265	   only the MRI and SID assocated with the NSLP data being transferred.
1266	   Node-Addressing information is only carried in the datagram mode
1267	   case.

1269	       GIMPS-Data = Common-Header
1270	                    Message-Routing-Information
1271	                    Session-Identification
1272	                    [ Node-Addressing ]
1273	                    NSLP-Data

1275	5.2  Information Elements

1277	   This section describes the content of the various information
1278	   elements that can be present in each GIMPS message, both the common
1279	   header, and the individual TLVs.  The format description in terms of
1280	   bit patterns is provided in Appendix C.

1282	5.2.1  The Common Header

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

1287	   Version: The version number of the GIMPS protocol.

1289	   Length: The number of words in the message following the common
1290	      header.

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

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

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

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

1306	5.2.2  TLV Objects

1308	   All data following the common header is encoded as a sequence of
1309	   type-length-value objects.  Currently, each object can occur at most
1310	   once; the set of required and permitted objects is determined by the
1311	   message type and further information in the common header.

1313	   These items are contained in each GIMPS message:

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

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

1321	       The format of the method-specific-information depends on the
1322	      message-routing-method requested by the signaling application.  In
1323	      the basic path-coupled case, it is just the Flow Identifier as in
1324	      [20].  Minimally, this could just be the flow destination address;
1325	      however, to account for policy based forwarding and other issues a
1326	      more complete set of header fields should be used (see Section 6.2
1327	      and Section 6.3 for further discussion).

1329	      The MRI is essentially a read only object for GIMPS processing.
1330	      It is set by the NSLP in the message sender and used by GIMPS to
1331	      select the message addressing, but not otherwise modified.  Note
1332	      that every message routing method must implicitly define a
1333	      directionality (upstream vs.  downstream), corresponding to the
1334	      two directions in the routing state table, and the MRI must
1335	      include control information which says in which direction this
1336	      message is being sent.

1338	       Flow-Identifier = network-layer-version
1339	                         source-address prefix-length
1340	                         destination-address prefix-length
1341	                         IP-protocol
1342	                         traffic-class
1343	                         [ flow-label ]
1344	                         [ ipsec-SPI / L4-ports]

1346	      Additional control information defines whether the flow-label, SPI
1347	      and port information are present, the direction of the message
1348	      relative to this flow, and whether the IP-protocol and
1349	      traffic-class fields should be interpreted as significant.

1351	   Session-Identification (SID): The GIMPS session identifier is a long,
1352	      cryptographically random identifier chosen by the node which
1353	      originates the signaling exchange.  The length is open, but 128
1354	      bits should be more than sufficient to make the probability of
1355	      collisions orders of magnitude lower than other failure reasons.
1356	      The session identifier should be considered immutable end-to-end
1357	      along the flow path (GIMPS never changes it, and signaling
1358	      applications should propagate it unchanged on messages for the
1359	      same session).

1361	   The following items are optional:

1363	   Node addressing: This can include a peer identity and IP address for
1364	      the sending node, as well as higher layer addressing information
1365	      for the negotiation of messaging association protocols.  It also
1366	      includes IP TTL information to allow the hop count between GIMPS
1367	      peers to be measured and reported.

1369	       Node-Addressing = peer-identity
1370	                         IP-TTL
1371	                         [ interface-address ]
1372	                         [ *higher-layer-addressing ]

1374	       The peer-identity and interface-address are used for matching
1375	      existing associations, as discussed in Section 4.4.2.  Any
1376	      technique may be used to generate it, so long as it is stable.
1377	      The interface-address should be a routable address where the
1378	      sending node can be reached over UDP or messaging association
1379	      protocols.  Where this object is used in a GIMPS-Query, it should
1380	      specifically be set to the address of the interface that will be
1381	      used for the outbound flow, to allow its use in route change
1382	      handling, see Section 6.1.  The purpose and structure of the
1383	      higher-layer-addressing fields is described in Section 5.5.  Note
1384	      that the higher-layer-addressing fields are only present in
1385	      datagram encapsulated messages; when this object is carried in
1386	      connection mode, these information elements are neither necessary
1387	      or meaningful.

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

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

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

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

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

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

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

1419	       Stack-Proposal = *stack-profile

1421	       stack-profile = *protocol-layer

1423	       Each protocol-layer field identifies a protocol with a unique
1424	      tag; any address-related (mutable) information associated with the
1425	      protocol will be carried in a higher-layer-addressing field in the
1426	      Node-Addressing TLV (see above).

1428	   Query-Cookie/Responder-Cookie: A query-cookie is contained in a
1429	      GIMPS-Query message and must be echoed in a GIMPS-Response; a
1430	      response-cookie is optional in a GIMPS-Response message, and if
1431	      present must be echoed in the following GIMPS-Confirm message.
1432	      Cookies are variable length (chosen by the cookie generator) and
1433	      need to be designed so that a node can determine the validity of a
1434	      cookie without keeping state.  A future version of this
1435	      specification will include references to techniques for generating
1436	      such cookies.

1438	   Routing-State-Lifetime: The lifetime of GIMPS routing state in the
1439	      absence of refreshes, measured in seconds.  Defaults to 30
1440	      seconds.

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

1445	5.3  Datagram Mode Transport

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

1458	5.3.1  Normal Encapsulation

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

1472	5.3.2  Query Encapsulation

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

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

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

1497	5.3.2.1  Intermediate Node Bypass and Router Alert Values

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

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

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

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

1518	   Conversely, note that a node might wish to process a number of
1519	   different signaling applications, either because it was genuinely
1520	   multifunctional or because it processed several versions of the same
1521	   application.  (Note from Appendix C.1 that different versions are
1522	   distinguished by different NSLP identifiers.)
1523	   Some or all of this information can be encoded in the RAO value
1524	   field, which then allows messages to be filtered on the fast path.
1525	   There is a tradeoff between two approaches here, whose evaluation
1526	   depends on whether the processing node is specialised or general
1527	   purpose:

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

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

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

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

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

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

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

1574	5.3.2.2  Query Encapsulation for the Path-Coupled Message Routing Method

1576	   For the case of the path-coupled message routing method, where the
1577	   message is travelling in the same ('downstream') direction as the
1578	   flow defined by the MRI, the IP addressing for Query messages is as
1579	   follows:

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

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

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

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

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

1611	   It is vital that the Query message truly mimics the actual data flow,
1612	   since this is the basis of how the signaling message is attached to
1613	   the data path.  To this end, GIMPS may set the traffic class and (for
1614	   IPv6) flow label to match the values in the Flow-Identifier if this
1615	   would be needed to ensure correct routing.

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

1626	5.3.3  Retransmission and Rate-Control

1628	   Datagram mode is built on top of UDP, and hence has no automatic
1629	   reliability or congestion control capabilities.  Signaling
1630	   applications requiring reliability should be serviced using C-mode,
1631	   which should also carry the bulk of signaling traffic.  However, some
1632	   form of messaging reliability is required for the GIMPS control
1633	   messages themselves, as is rate control to handle retransmissions and
1634	   also bursts of unreliable signaling or state setup requests from the
1635	   signaling applications.

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

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

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

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

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

1673	   The second (which is probably the more commonplace one where Confirm
1674	   messages are wanted at all), a retransmission timer should not be
1675	   required.  However, we can assume that the next signaling message
1676	   will be in the direction Querying Node -> Responding Node (if there
1677	   is no 'next signaling message' the fact that the Confirm has been
1678	   lost is moot).  In this case, the responding node will start to
1679	   receive messages at the GIMPS level for a flow/NSLP combination for
1680	   which there is no stored routing state (since this state is only
1681	   created on receipt of a Confirm).

1683	   The consequence of this is that the error condition is detected at
1684	   the Responding node when such a message arrives without the need for
1685	   a specific timer.  Recovery requires a Confirm to be retransmitted
1686	   and successfully received.  The ideal mechanism to cause this would
1687	   be for the Responding node to be able to reject the incoming message
1688	   with an error "No Routing State Exists" back to the Querying node,
1689	   which would interpret this as caused by a lost Confirm; the Querying
1690	   node needs to be able to regenerate the Confirm from local state
1691	   without getting a Response (e.g.  in particular it needs to remember
1692	   the Responder Cookie value).

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

1705	5.4  Connection Mode Transport

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

1712	5.4.1  Choice of Transport Protocol

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

1719	   SCTP [6] satisfies all requirements.

1721	   DCCP [7] is message based but does not provide bundling or
1722	      fragmentation.  Bundling can be carried out by the GIMPS layer
1723	      sending multiple messages in a single datagram; because the common
1724	      header includes length information (number of TLVs), the message
1725	      boundaries within the datagram can be discovered during parsing.
1726	      Fragmentation of GIMPS messages over multiple datagrams should be
1727	      avoided, because of amplification of message loss rates that this
1728	      would cause.

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

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

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

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

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

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

1763	5.4.2  Encapsulation Format

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

1772	      +---------------------------------------------+
1773	      |                  L2 Header                  |
1774	      +---------------------------------------------+
1775	      |                  IP Header                  |   ^
1776	      |      Source address = signaling source      |   ^
1777	      | Destination address = signaling destination |   .
1778	      +---------------------------------------------+   .
1779	      |                  L4 Header                  |   . ^
1780	      |     (Standard TCP/SCTP/DCCP/UDP header)     |   . ^
1781	      +---------------------------------------------+   . .
1782	      |                GIMPS Message                |   . . ^
1783	      | (Common header and TLVs as in section 5.1)  |   . . ^  Scope of
1784	      +---------------------------------------------+   . . .  security
1785	      | Additional GIMPS messages, each with its    |   . . . protection
1786	      | own common header, either as a continuous   |   . . . (depending
1787	      |   stream, or continuing to the next L4      |   . . . on channel
1788	      .             message boundary                .   . . .  security
1789	      .                                             .   V V V  mechanism
1790	      .                                             .   V V V   in use)

1792	                Figure 5: Connection Mode Encapsulation

1794	5.5  Messaging Association Negotiation

1796	5.5.1  Overview

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

1809	   Protocol negotiation is carried out in GIMPS-Query/Response messages,
1810	   using Stack-Proposal and Node-Addressing objects.  If a new messaging
1811	   association is required it is then set up, followed by a
1812	   GIMPS-Confirm.  Messaging association re-use is achieved by
1813	   short-circuiting this exchange by sending the GIMPS-Response or
1814	   GIMPS-Confirm messages on an existing association (Section 4.4.2);
1815	   whether to do this is a matter of local policy at the querying or
1816	   responding node.  It is always possible for a node to restrict itself
1817	   to a single messaging association between two peers.  If multiple
1818	   associations exist, it is a matter of local policy how to distribute
1819	   messages over them, subject to respecting the transfer attributes
1820	   requested.

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

1826	   o  A Protocol-Identifier, a 1-byte IANA assigned value.

1828	   o  A specification of the (non-negotiable) policies about how the
1829	      protocol should be used (for example, connection open direction).

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

1837	   A Stack-Proposal object is simply a list of profiles; each profile is
1838	   a sequence of Protocol-Identifiers.  Stack-Proposals are generally
1839	   accompanied by Node-Addressing objects; as well as a Peer-Identity
1840	   and Interface-Address, this carries a higher-layer-addressing
1841	   information element for every protocol listed in the Stack-Proposal.
1842	   A node generating a Node-Addressing object is committed to honouring
1843	   the implied protocol configuration; in particular, it must be
1844	   prepared to accept incoming datagrams or connections at the
1845	   Interface-Address/protocol/port combinations advertised.  However,
1846	   the object contents should be retained only for the duration of the
1847	   Query/Response exchange and any following association setup and
1848	   afterwards discarded.  (They may become invalid because of expired
1849	   bindings at intermediate NATs, or because the advertising node is
1850	   using agile ports.)

1852	   A GIMPS-Query requesting association setup always contains a
1853	   Stack-Proposal and Node-Addressing object, and unless re-use occurs,
1854	   the GIMPS-Response does so also.  For a GIMPS-Response, the
1855	   Stack-Proposal must be invariant for the combination of outgoing
1856	   interface and NSLPID (it must not depend on the GIMPS-Query).  Once
1857	   the messaging association is set up, the querying node repeats the
1858	   responder's Stack-Proposal over it in the GIMPS-confirm.  The
1859	   resonding node can verify this to ensure that no bidding-down attack
1860	   has occurred.  Where the Response or Confirm is being sent in
1861	   connection mode (either because of re-use or because messaging
1862	   association setup has actually completed), the Node-Addressing object
1863	   is sent in an abbreviated form, omitting the higher layer information
1864	   fields.  The Interface-Address is retained in the Confirm, to allow
1865	   matching the messaging association against subsequent Query messages.

1867	5.5.2  Protocol Definition: Forwards-TCP

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

1876	   o  downstream: no additional data (just the Protocol-Identifier)

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

1881	5.5.3  Additional Protocol Options

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

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

1891	   o  SigComp [17] for message compression.

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

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

1898	6.  Advanced Protocol Features

1900	6.1  Route Changes and Local Repair

1902	6.1.1  Introduction

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

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

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

1930	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1931	               x  +--+        +--+        +--+  x      Initial
1932	              x  .|B1|_.......|C1|_.......|D1|   x     Configuration
1933	             x  . +--+.      .+--+.      .+--+\.  x
1934	            x  .       .    .      .    .       .  x
1935	    >>xxxxxx  .         .  .        .  .         .  xxxxxx>>
1936	         +-+ .           ..          ..           . +-+
1937	    .....|A|/            ..          ..            .|E|_....
1938	         +-+ .          .  .        .  .          . +-+
1939	              .        .    .      .    .        .
1940	               .      .      .    .      .      .
1941	                . +--+        +--+        +--+ .
1942	                 .|B2|_.......|C2|_.......|D2|/
1943	                  +--+        +--+        +--+

1945	                  +--+        +--+        +--+         Configuration
1946	                 .|B1|........|C1|........|D1|         after failure
1947	                . +--+       .+--+        +--+         of D1-E link
1948	               .      \.    .     \.    ./
1949	              .         .  .        .  .
1950	         +-+ .           ..          ..             +-+
1951	    .....|A|.            ..          ..            .|E|_....
1952	         +-+\.          .  .        .  .          . +-+
1953	    >>xxxxxx  .        .    .      .    .        .  xxxxxx>>
1954	            x  .      .      .    .      .      .  x
1955	             x  . +--+        +--+        +--+ .  x
1956	              x  .|B2|_.......|C2|_.......|D2|/  x
1957	               x  +--+        +--+        +--+  x
1958	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

1962	               >>xxxxxxx>> = flow direction

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

1968	                      Figure 6: A Re-Routing Event

1970	6.1.2  Route Change Detection

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

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

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

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

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

1989	   Peer: The adjacent peer may change.

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

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

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

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

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

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

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

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

2049	   +----------------------+----------------------+---------------------+
2050	   | Method               | Query direction      | Response direction  |
2051	   +----------------------+----------------------+---------------------+
2052	   | Local Trigger        | Discovers new        | Not applicable      |
2053	   |                      | interface (and peer  |                     |
2054	   |                      | if local)            |                     |
2055	   |                      |                      |                     |
2056	   | Extended Trigger     | Discovers new        | May determine that  |
2057	   |                      | interface and may    | route from peer     |
2058	   |                      | determine new peer   | will have changed   |
2059	   |                      |                      |                     |
2060	   | C-Mode Monitoring    | Provides hint that   | Provides hint that  |
2061	   |                      | change has occurred  | change has occurred |
2062	   |                      |                      |                     |
2063	   | Data Plane           | Not applicable       | NSLP informs GIMPS  |
2064	   | Monitoring           |                      | that a change may   |
2065	   |                      |                      | have occurred       |
2066	   |                      |                      |                     |
2067	   | Probing              | Discovers changed    | Discovers changed   |
2068	   |                      | Node-Addressing in   | Node-Addressing in  |
2069	   |                      | GIMPS-Response       | GIMPS-Query         |
2070	   +----------------------+----------------------+---------------------+

2072	6.1.3  Local Repair

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

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

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

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

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

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

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

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

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

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

2128	6.1.4  Local Signaling Application State Removal

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

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

2151	6.1.5  Operation with Heterogeneous NSLPs

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

2164	   The converse problem is that the ability of GIMPS to detect route
2165	   changes by purely local monitoring of forwarding tables is more
2166	   limited.  (This is probably an appropriate limitation of GIMPS
2167	   functionality.  If we need a protocol for distributing notifications
2168	   about local changes in forwarding table state, a flow signaling
2169	   protocol is probably not the right starting point.)

2171	6.2  Policy-Based Forwarding and Flow Wildcarding

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

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

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

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

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

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

2204	   The current Message-Routing-Information format allows a limited
2205	   degree of 'wildcarding', for example by applying a prefix length to
2206	   the source or destination address, or by leaving certain fields
2207	   unspecified.  A GIMPS-aware node must verify that all flows matching
2208	   the Message-Routing-Information would be routed identically in the
2209	   downstream direction, or else reject the message with an error.

2211	6.3  NAT Traversal

2213	   As already noted, GIMPS messages must carry packet addressing and
2214	   higher layer information as payload data in order to define the flow
2215	   signalled for.  (This applies to all GIMPS messages, regardless of
2216	   how they are encapsulated or which direction they are travelling in.)
2217	   At an addressing boundary the data flow packets will have their
2218	   headers translated; if the signaling payloads are not likewise
2219	   translated, the signaling messages will refer to incorrect (and
2220	   probably meaningless) flows after passing through the boundary.  In
2221	   addition, some GIMPS messages (those used in the discovery process)
2222	   carry addressing information about the GIMPS nodes themselves, and
2223	   this must also be processed appropriately when traversing a NAT.

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

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

2238	   2.  Create bindings for subsequent C-mode signaling (based on the
2239	       information in the Node-Addressing field).

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

2244	   4.  Create a new Node-Addressing payload with fields to force
2245	       upstream D-mode messages through the NAT, and to allow C-mode
2246	       exchanges using the C-mode signaling bindings.

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

2252	   6.  Forward the message with these new payloads.

2254	   The original Message-Routing-Information payload is retained in the
2255	   message, but encapsulated in the new TLV type.  Further information
2256	   can be added corresponding to the Node-Addressing payload, either the
2257	   original payload itself or, in the case of a GIMPS node that wished
2258	   to do topology hiding, opaque tokens (or it could be omitted
2259	   altogether).  In the case of a sequence of NATs, this part of the
2260	   NAT-Traversal object would become a list.  Note that a consequence of
2261	   this approach is that the routing state tables at the actual
2262	   signaling application peers (either side of the NAT) are no longer
2263	   directly compatible.  In particular, the values of
2264	   Message-Routing-Information are different, which is why the
2265	   unmodified MRI is propagated in the NAT-Traversal payload to allow
2266	   subsequent C-mode messages to be interpreted correctly..

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

2278	6.4  Interaction with IP Tunnelling

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

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

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

2312	6.5  IPv4-IPv6 Transition and Interworking

2314	   GIMPS itself is essentially IP version neutral (version dependencies
2315	   are isolated in the formats of the Message-Routing-Information and
2316	   Node-Addressing TLVs, and GIMPS also depends on the version
2317	   independence of the protocols that support messaging associations).
2318	   In mixed environments, GIMPS operation will be influenced by the IP
2319	   transition mechanisms in use.  This section provides a high level
2320	   overview of how GIMPS is affected, considering only the currently
2321	   predominant mechanisms.

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

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

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

2348	   Packet Translation: (Applicable to SIIT [5] and NAT-PT [12].) Some
2349	      transition mechanisms allow IPv4 and IPv6 nodes to communicate by
2350	      placing packet translators between them.  From the GIMPS
2351	      perspective, this should be treated essentially the same way as
2352	      any other NAT operation (e.g.  between 'public' and 'private'
2353	      addresses) as described in Section 6.3.  In other words, the
2354	      translating node needs to be GIMPS-aware; it will run GIMPS with
2355	      IPv4 on some interfaces and with IPv6 on others, and will have to
2356	      translate the Message-Routing-Information payload between IPv4 and
2357	      IPv6 formats for flows which cross between the two.  The
2358	      translation rules for the fields in the payload (including e.g.
2359	      traffic class and flow label) are as defined in [5].

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

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

2381	7.  Security Considerations

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

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

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

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

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

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

2424	7.1  Message Confidentiality and Integrity

2426	   GIMPS can use messaging association functionality, such as TLS or
2427	   IPsec, to ensure message confidentiality and integrity.  In many
2428	   cases, confidentiality of GIMPS information itself is not likely to
2429	   be a prime concern, in particular since messages are often sent to
2430	   parties which are unknown ahead of time, although the content visible
2431	   even at the GIMPS level gives significant opportunities for traffic
2432	   analysis.  Signaling applications may have their own mechanism for
2433	   securing content as necessary; however, they may find it convenient
2434	   to rely on protection provided by messaging associations, since it
2435	   runs unbroked between signaling application peers.

2437	7.2  Peer Node Authentication

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

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

2461	   It is open whether peer node authentication should be made signaling
2462	   application dependent; for example, whether successful authentication
2463	   could be made dependent on presenting authorisation to act in a
2464	   particular signaling role (e.g.  signaling for QoS).  The abstract
2465	   API of Appendix D allows GIMPS to forward such policy and
2466	   authentication decisions to the NSLP it is serving.

2468	7.3  Routing State Integrity

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

2474	   In the case where the message routing method is path-coupled
2475	   signaling, the messages need to be routed identically to the data
2476	   flow described by the Flow Identifier, and the routing state table is
2477	   the GIMPS view of how these flows are being routed through the
2478	   network in the immediate neighbourhood of the node.  Routes are only
2479	   weakly secured (e.g.  there is usually no cryptographic binding of a
2480	   flow to a route), and there is no other authoritative information
2481	   about flow routes than the current state of the network itself.
2482	   Therefore, consistency between GIMPS and network routing state has to
2483	   be ensured by directly interacting with the routing mechanisms to
2484	   ensure that the signaling peers are the appropriate ones for any
2485	   given flow.  A good overview of security issues and techniques in
2486	   this sort of context is provided in [27].

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

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

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

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

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

2527	7.4  Denial of Service Prevention

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

2534	   However, GIMPS can still be subjected to denial-of-service attacks
2535	   where an attacker using forged source addresses forces a node to
2536	   establish state without return routability, causing a problem similar
2537	   to TCP SYN flood attacks.  In addition to vulnerabilities of a next
2538	   peer discovery an unprotected path discovery procedure might
2539	   introduce more denial of service attacks since a number of nodes
2540	   could possibly be forced to allocate state.  Furthermore, an
2541	   adversary might modify or replay unprotected signaling messages.
2542	   There are two types of state attacks and one computational resource
2543	   attack.  In the first state attack, an attacker floods a node with
2544	   messages that the node has to store until it can determine the next
2545	   hop.  If the destination address is chosen so that there is no
2546	   GIMPS-capable next hop, the node would accumulate messages for
2547	   several seconds until the discovery retransmission attempt times out.
2548	   The second type of state-based attack causes GIMPS state to be
2549	   established by bogus messages.  A related
2550	   computational/network-resource attack uses unverified messages to
2551	   cause a node to make AAA queries or attempt to cryptographically
2552	   verify a digital signature.  (RSVP is vulnerable to this type of
2553	   attack.) Relying only on upper layer security, for example based on
2554	   CMS, might open a larger door for denial of service attacks since the
2555	   messages are often only one-shot-messages without utilizing multiple
2556	   roundtrips and DoS protection mechanisms.

2558	   We use a combination of two defences against these attacks:

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

2569	   2.  The Response to the Query message contains a cookie.  The
2570	       previous hop repeats the cookie in the Confirm.  State is only
2571	       established for messages that contain a valid cookie.  The setup
2572	       delay is also 1.5 round-trip times.  (This mechanism is similar
2573	       to that in SCTP [6] and other modern protocols.)

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

2584	8.  IANA Considerations

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

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

2592	   GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a
2593	      1 byte message type field (initially distinguishing Query,
2594	      Response, Confirm and Data messages).

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

2603	   Object Types: There is an TBD-bit field in the generic object header
2604	      (Appendix C.3.1).  Distinguish different ranges for different
2605	      allocation styles (standards action, expert review etc.) and
2606	      different applicability scopes (experimental/private,
2607	      NSLP-specific); by default, object types are public and shared
2608	      between all NSLPs.  When a new object type is defined, the
2609	      extensibility bits (A/B, see Appendix C.3.2) must also be defined.

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

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

2620	   Protocol Indicators: The GIMPS design allows the set of possible
2621	      protocols to be used in a messaging association to be extended, as
2622	      discussed in Section 5.5.  Every new mode of using a protocol is
2623	      given a single byte Protocol Indicator, which is used as a tag in
2624	      the Node Addressing and Stack Proposal objects (Appendix C.4.3 and
2625	      Appendix C.4.4).  Allocating a new protocol indicator requires
2626	      defining the higher layer addressing information (if any) in the
2627	      Node Addressing Object that is needed to define its configuration.

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

2636	   Error Codes: There is a 3 byte error code in the Value field of the
2637	      generic Error object (Appendix C.5.1).  Error codes are shared
2638	      across all NSLPs.  When a new error code is allocated, the Error
2639	      Class and the format of any associated error-specific information
2640	      must also be defined.

2642	9.  Open Issues

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

2651	9.1  Additional Discovery Mechanisms

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

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

2675	9.2  Alternative Message Routing Requirements

2677	   The initial assumption of GIMPS is that signaling messages are to be
2678	   routed identically to data flow messages.  For this case of
2679	   path-coupled signaling, the MRI and upstream/downstream flag (in the
2680	   Common-Header) define the flow and the relationship of the signaling
2681	   to it sufficiently for GIMPS to route its messages correctly.
2682	   However, some additional modes of routing signaling messages have
2683	   been identified:

2685	   Predictive Routing: Here, the intent is to send signaling along a
2686	      path that the data flow may or will follow in the future.
2687	      Possible cases are pre-installation of state on the backup path
2688	      that would be used in the event of a link failure; and predictive
2689	      installation of state on the path that will be used after a mobile
2690	      node handover.  It is currently unclear whether these cases can be
2691	      met using the existing GIMPS routing capabilities (and if they
2692	      cannot, whether they are in the initial scope of the work).

2694	   NAT Address Reservations: This applies to the case where a node
2695	      behind a NAT wishes to use NSIS signaling to reserve an address
2696	      from which it can be reached by a sender on the other side.  This
2697	      requires a message to be sent outbound from what will be the flow
2698	      receiver although no reverse routing state exists.  A possible
2699	      solution is described in [29], where the Query is sent towards a
2700	      configured address in the 'public' Internet, and intercepted at
2701	      the private network boundary.

2703	   In the current structure of the protocol definition, the way to
2704	   handle these requirements (if they are needed) is to define a new
2705	   message routing method which replaces the basic path-coupled version.
2706	   The requirements for defining a new routing method include the
2707	   following:

2709	   o  Defining the format of the MRI for the new message routing method
2710	      type.

2712	   o  Defining how Query messages should be encapsulated and routed
2713	      corresponding to this MRI.

2715	   o  Defining any filtering or other security mechanisms that should be
2716	      used to validate the MRI in a message.

2718	   o  Defining how the MRI format is processed on passing through a NAT.

2720	9.3  Message Format Issues

2722	   NSIS message formats are defined as a set of objects (see
2723	   Appendix C.1). Some aspects are left open:

2725	   Ordering: Traditionally, Internet protocols require a node to be able
2726	      to process a message with objects in any order.  However, this has
2727	      some costs in parser complexity, testing interoperability, ease of
2728	      compression; there is a special issue with GIMPS that for
2729	      efficiency, the NSLP-Data object (which may be large) should come
2730	      last.  Should object order be fixed or unspecified?

2732	   NSLP Versioning: The current working assumption is that if an NSLP
2733	      for a particular signaling application is changed so radically
2734	      that it is no longer backwards compatible, an entirely new NSLPID
2735	      will be allocated.  However, this leads to a problem when a node
2736	      supporting both variants needs to discover its downstream peer.

2738	      If it probes for the 'early' NSLPID it will not detect the case
2739	      where the downstream peer supports the later one; if it probes for
2740	      the 'later' NSLPID, a downstream peer supporting only the early
2741	      variant will bypass the message altogether.  The implication is
2742	      that a single NSLPID should be used even in this case, with
2743	      demultiplexing based on a separate version number (which could be
2744	      carried in the common header, or within the NSLP payload).

2746	10.  Change History

2748	10.1  Changes In Version -05

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

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

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

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

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

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

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

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

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

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

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

2800	10.2  Changes In Version -04

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

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

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

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

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

2833	   5.  Added an outline for the future content of an IANA considerations
2834	        section (Section 8).  Currently, this is restricted to
2835	        identifying the registries and allocations required, without
2836	        defining the allocation policies and other considerations
2837	        involved.

2839	   6.  Shortened the background design discussion in Section 3.

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

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

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

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

2860	10.3  Changes In Version -03

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

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

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

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

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

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

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

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

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

2898	   9.  Expanded the open issue discussion in Section 9.3 to include an
2899	       outline set of extensibility flags.

2901	10.4  Changes In Version -02

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

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

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

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

2922	   4.  Extended Appendix C with a general discussion of rules for
2923	        message and object formats across GIMPS and other NSLPs.  Some
2924	        remaining open issues are noted in Section 9.3.

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

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

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

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

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

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

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

2960	10.5  Changes In Version -01

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

2975	   The full set of changes is as follows:

2977	   1.  Added a worked example in Section 3.2.

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

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

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

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

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

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

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

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

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

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

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

3031	   13.  Removed old open issues on Connection Mode Encapsulation
3032	        (section 8.7); added new open issues on Message Routing
3033	        (Section 9.2) and Datagram Mode congestion control.

3035	   14.  Added this change history.

3037	11.  References

3039	11.1  Normative References

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

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

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

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

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

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

3059	   [7]  Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
3060	        Internet-Draft draft-ietf-dccp-spec-09, November 2004.

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

3066	11.2  Informative References

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

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

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

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

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

3084	   [14]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
3085	         RFC 3068, June 2001.

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

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

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

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

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

3107	   [20]  Hancock, R., "Next Steps in Signaling: Framework",
3108	         Internet-Draft draft-ietf-nsis-fw-07, December 2004.

3110	   [21]  Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
3111	         Internet-Draft draft-ietf-nsis-threats-06, October 2004.

3113	   [22]  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
3114	         (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October
3115	         2004.

3117	   [23]  Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
3118	         Quality-of-Service signaling",
3119	         Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004.

3121	   [24]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
3122	         IPv6 Hosts and Routers",
3123	         Internet-Draft draft-ietf-v6ops-mech-v2-06, September 2004.

3125	   [25]  Lonvick, C., "SSH Protocol Architecture",
3126	         Internet-Draft draft-ietf-secsh-architecture-21, February 2005.

3128	   [26]  Moskowitz, R., "Host Identity Protocol",
3129	         Internet-Draft draft-ietf-hip-base-01, October 2004.

3131	   [27]  Nikander, P., "Mobile IP version 6 Route Optimization Security
3132	         Design Background", Internet-Draft draft-ietf-mip6-ro-sec-02,
3133	         October 2004.

3135	   [28]  Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
3136	         (DSTM)", Internet-Draft draft-bound-dstm-exp-02, January 2005.

3138	   [29]  Stiemerling, M., "Loose End Message Routing Method for NATFW
3139	         NSLP", Internet-Draft draft-stiemerling-nsis-natfw-mrm-01,
3140	         February 2005.

3142	Authors' Addresses

3144	   Henning Schulzrinne
3145	   Columbia University
3146	   Department of Computer Science
3147	   450 Computer Science Building
3148	   New York, NY  10027
3149	   US

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

3155	   Robert Hancock
3156	   Siemens/Roke Manor Research
3157	   Old Salisbury Lane
3158	   Romsey, Hampshire  SO51 0ZN
3159	   UK

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

3164	Appendix A.  Acknowledgements

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

3182	Appendix B.  Example Message Routing State Table

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

3189	       A                        B          C          D           E
3190	   +------+                  +-----+    +-----+    +-----+    +--------+
3191	   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
3192	   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
3193	   |      |    +-+    +-+    |GIMPS|    |GIMPS|    |GIMPS|    |        |
3194	   +------+                  +-----+    +-----+    +-----+    +--------+

3196	                     ------------------------------>>
3197	                              Flow Direction

3199	                     Figure 7: A Signaling Scenario

3201	   The routing state table at node B is as follows:

3203	   +--------------------+----------+----------+-------------+----------+
3204	   |   Message Routing  |  Session |  NSLP ID |   Response  |   Query  |
3205	   |     Information    |    ID    |          |  Direction  | Directio |
3206	   |                    |          |          |             | n        |
3207	   +--------------------+----------+----------+-------------+----------+
3208	   |    Method = Path   |  0xABCD  |   NSLP1  |    IP-#A    |  (null)  |
3209	   | Coupled; Flow ID = |          |          |             |          |
3210	   |   {IP-#A, IP-#E,   |          |          |             |          |
3211	   |  protocol, ports}  |          |          |             |          |
3212	   |                    |          |          |             |          |
3213	   |    Method = Path   |  0x1234  |   NSLP2  |    IP-#A    |  Pointer |
3214	   | Coupled; Flow ID = |          |          |             |  to B-D  |
3215	   |   {IP-#A, IP-#E,   |          |          |             | messagin |
3216	   |  protocol, ports}  |          |          |             | g        |
3217	   |                    |          |          |             |  associa |
3218	   |                    |          |          |             | ti   on  |
3219	   +--------------------+----------+----------+-------------+----------+

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

3233	Appendix C.  Bit-Level Formats

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

3241	   In addition, this appendix includes some general rules for the format
3242	   of messages and message objects across all protocols in the NSIS
3243	   protocol suite (i.e.  the current and future NSLPs as well as GIMPS
3244	   itself).  The intention of these common rules is to encourage
3245	   commonality in implementations, ease of testing and debugging, and
3246	   sharing of object definitions across different applications.

3248	C.1  General NSIS Formatting Guidelines

3250	   Each NSIS message consists of a header and a sequence of objects.  An
3251	   NSLP message is one object within a GIMPS message.  The GIMPS header
3252	   has a specific format, described in more detail in Appendix C.2
3253	   below; the NSLP header format is common to all signaling applications
3254	   and includes simply a message type (which may be structured into a
3255	   type field and some processing flags, depending on the application).
3256	   Note that GIMPS provides the message length information and signaling
3257	   application identification.

3259	   Note that there is no version information at the NSLP level.  It is
3260	   assumed that minor protocol extensions can be implemented by adding
3261	   extra objects (see Appendix C.3.2); if an NSLP has to be extended so
3262	   much that backwards compatibity is no longer possible, a new
3263	   signaling application identifier is allocated instead.  An open issue
3264	   on this subject is discussed in Section 9.3.

3266	   Every object has the following general format:

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

3270	   o  By default, assignments for the Type field are common across all
3271	      NSIS protocols (i.e.  there is a single registry).  This is to
3272	      facilitate the sharing of common objects across different
3273	      signaling applications.  The allocation of control flags to define
3274	      how unknown types should be handled is also common across
3275	      signaling applications; this is discussed in Appendix C.3.2.

3277	   o  Part of the object type space can be set aside for TLVs which for
3278	      some reason should only be used within a single signaling
3279	      application, see Section 8.

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

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

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

3293	   Error messages are identified by containing an error object (i.e.  an
3294	   object with Type='Error').  The error object format is given in
3295	   Appendix C.5.1; its Value field includes an error class, an error
3296	   code, and optionally additional error-specific information.  Again,
3297	   the error code space is common across all protocols.

3299	C.2  The GIMPS Common Header

3301	   This header precedes all GIMPS messages.  It has a fixed format, as
3302	   shown below.  Note that (unlike NSLP messages) the GIMPS header does
3303	   include a version number, since allocating new lower layer
3304	   identifiers to demultiplex a new GIMPS version will be significantly
3305	   harder than allocating a new NSLP identifier.

3307	    0                   1                   2                   3
3308	    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
3309	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3310	   |    Version    |  GIMPS hops   |        Message length         |
3311	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3312	   |   Signaling Application ID    |   Type        |S|  Reserved   |
3313	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3315	   Message length = the total number of words in the message after
3316	                    the common header itself
3317	   Type           = the GIMPS message type (Query, Response, etc.)
3318	   S flag         = set if the IP source address is the signaling
3319	                    source address, clear if it was derived from the
3320	                    MRI

3322	C.3  General Object Characteristics

3324	C.3.1  TLV Header

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

3330	    0                   1                   2                   3
3331	    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
3332	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3333	   |A|B|r|r|         Type          |r|r|r|r|        Length         |
3334	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3336	C.3.2  Object Extensibility

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

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

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

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

3354	   AB=11 ("Refresh"): If the object is not understood, it should be
3355	      incorporated into the locally stored signaling application state
3356	      for this flow/session, forwarded in any resulting message, and
3357	      also used in any refresh or repair message which is generated
3358	      locally.

3360	   For objects used within the NSLP-Data payload, the precise usage of
3361	   these flags must be defined for each signaling application.  In
3362	   particular, signaling applications must define how to indicate
3363	   errors, and what it means to forward or refresh 'state'; they may
3364	   also restrict whether particular flag combinations can be used.

3366	C.4  GIMPS Specific TLV Objects

3368	   The objects defined in this section are expected to be used mainly by
3369	   GIMPS rather than signaling applications.

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

3375	C.4.1  Message-Routing-Information

3377	   Type: Message-Routing-Information

3379	   Length: Variable (depends on message routing method)

3381	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3382	   | Message-Routing-Method        |                               |
3383	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
3384	   //     Method-specific addressing information (variable)       //
3385	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3390	                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3391	                                   |IP-Ver |P|T|F|I|A|B|D|Reserved |
3392	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3393	   //                       Source Address                        //
3394	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3395	   //                      Destination Address                    //
3396	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3397	   | Source Prefix |  Dest Prefix  |   Protocol    | Traffic Class |
3398	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3399	   :       Reserved        |              Flow Label               :
3400	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3401	   :                              SPI                              :
3402	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3403	   :          Source Port          :       Destination Port        :
3404	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3406	   The flags are:
3407	   P - Protocol
3408	   T - Traffic Class
3409	   F - Flow Label
3410	   I - SPI
3411	   A - Source Port
3412	   B - Destination Port
3413	   I/A/B can only be set if P is set.
3414	   D - Direction of message relative to MRI

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

3419	   If only one of S, D is set, both Port fields are included in the
3420	   message.  However, the contents of the field are only interpreted if
3421	   the corresponding flag is set.  If the flag is not set, Port values
3422	   will be ignored as part of the flow definition; the MRI matches all
3423	   packets regardless of port.  If the flag is set and Port=0x0000, the
3424	   MRI will apply to a specific port, whose value is not yet known.

3426	C.4.2  Session Identification

3428	   Type: Session-Identification

3430	   Length: Fixed (TBD 4 32-bit words)

3432	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3433	   |                                                               |
3434	   +                                                               +
3435	   |                                                               |
3436	   +                          Session ID                           +
3437	   |                                                               |
3438	   +                                                               +
3439	   |                                                               |
3440	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3442	C.4.3  Node Addressing

3444	   Type: Node-Addressing

3446	   Length: Variable (depends on length of Peer-Identity and number of
3447	      higher-layer-protocol fields present)

3449	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3450	   | PI-Length     | HL-Count      |    IP-TTL     |IP-Ver | Rsvd  |
3451	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3452	   //                       Peer Identity                         //
3453	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3454	   //                     Interface Address                       //
3455	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3456	   //                Higher-Layer-Information 1                   //
3457	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3458	   :                                                               :
3459	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3460	   //                Higher-Layer-Information N                   //
3461	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3463	   PI-Length = the byte length of the Peer-Identity field
3464	               (note that the Peer-Identity field itself is padded
3465	               to a whole number of words)
3466	   HL-Count  = the number of higher-layer-information fields
3467	               (these contain their own length information);
3468	               0 if this object is carried in connection mode
3469	   IP-TTL    = initial or reported IP-TTL
3470	   IP-Ver    = the IP version for the Interface-Address field

3472	   The higher layer information fields are formatted as follows:

3474	   o  There is a 1-byte Protocol Indicator, as described in Section 5.5.

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

3479	   o  There is a variable length of configuration data.

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

3484	   Note that the contents of the configuration data may differ depending
3485	   on whether the NAO is in a GIMPS-query or GIMPS-response.

3487	C.4.4  Stack Proposal

3489	   Type: Stack-Proposal

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

3494	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3495	   |  Prof-Count   |     Reserved                                  |
3496	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3497	   //                    Profile 1                                //
3498	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3499	   :                                                               :
3500	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3501	   //                    Profile 2                                //
3502	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3504	   Prof-Count = The number of profiles in the proposal

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

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

3511	   o  This is followed by a sequence of 1-byte Protocol Indicators as
3512	      described in Section 5.5.

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

3517	C.4.5  Query Cookie

3519	   Type: Query-Cookie

3521	   Length: Variable (selected by querying node)

3523	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3524	   |                                                               |
3525	   //                        Query Cookie                         //
3526	   |                                                               |
3527	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3529	   Note that the querying node uses the value of the query cookie in the
3530	   GIMPS-response message on an existing messaging association to match
3531	   with the corresponding GIMPS-query.  This imposes certain uniqueness
3532	   requirements on the cookie contents.

3534	C.4.6  Responder Cookie

3536	   Type: Responder-Cookie

3538	   Length: Variable (selected by responding node)

3540	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3541	   |                                                               |
3542	   //                      Responder Cookie                       //
3543	   |                                                               |
3544	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3546	   Note that the responding node uses the value of the responder cookie
3547	   in the GIMPS-confirm message to match a new messaging association
3548	   with the corresponding GIMPS-query/response exchange.  This imposes
3549	   certain uniqueness requirements on the cookie contents.

3551	C.4.7  Lifetime

3553	   Type: Lifetime

3555	   Length: Fixed - 1 32-bit word
3556	   Value: Routing state lifetime in seconds

3558	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3559	   |                           Lifetime                            |
3560	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3562	C.4.8  NAT Traversal

3564	   Type: NAT-Traversal

3566	   Length: Variable (depends on length of contained fields)

3568	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3569	   | MRI-Length    | Type-Count    | NAT-Count    |  Reserved      |
3570	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3571	   //            Original Message-Routing-Information             //
3572	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3573	   //                 List of translated objects                  //
3574	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3575	   | Length of opaque NAO info.    |                               |
3576	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3577	   //            NAO information replaced by NAT #1                |
3578	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3579	   :                                                               :
3580	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3581	   | Length of opaque NAO info.    |                               |
3582	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3583	   //            NAO information replaced by NAT #N                |
3584	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3594	C.4.9  NSLP Data

3596	   Type: NSLP-Data
3597	   Length: Variable (depends on NSLP)

3599	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3600	   |                                                               |
3601	   //                          NSLP Data                          //
3602	   |                                                               |
3603	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3605	C.5  Generic NSIS TLV Objects

3607	   The objects defined in this section are general purpose objects,
3608	   which will be used by both GIMPS and signaling applications in
3609	   general.

3611	C.5.1  Error Object

3613	   Type: Error

3615	   Length: Variable (depends on error)

3617	   Value: Contains a 1 byte error class and 3 byte error code, an error
3618	      source identifier and optionally variable length error-specific
3619	      information.

3621	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3622	   |   Error Class |                   Error Code                  |
3623	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3624	   |   ESI-Length  |                    Reserved                   |
3625	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3626	   //                   Error Source Identifier                   //
3627	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3628	   //             Optional error-specific information             //
3629	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

3651	   Additional error class values are reserved.

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

3659	   The Error Source Identifier can be generated in an
3660	   implementation-specific manner.  It is suggested that the same method
3661	   is used as for the Peer Identity in the Node Addressing object.

3663	   ESI-Length is given in bytes (excluding padding).  The Error Source
3664	   Identifier MUST be padded to make it a whole number of 32-bit words
3665	   in length.  The optional additional error-specific information fills
3666	   the rest of the object up to the length given in the object header.

3668	   The Error object may be carried either at the GIMPS level to indicate
3669	   GIMPS errors, or at the NSLP level (inside the NSLP-Data object) to
3670	   indicate NSLP errors.  However, the format and error code assignments
3671	   are common to both uses.

3673	Appendix D.  API between GIMPS and NSLP

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

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

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

3695	D.1  SendMessage

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

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

3705	   The following arguments are mandatory.

3707	   NSLP-Data: The NSLP message itself.

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

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

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

3720	   Session-ID: The NSIS session identifier.  Note that it is assumed
3721	      that the signaling application provides this to GIMPS rather than
3722	      GIMPS providing a value itself; often, this will be a value
3723	      associated with an existing session, for example received in an
3724	      incoming message.  In the case of an entirely new session, a GIMPS
3725	      implementation might provide library functionality to generate a
3726	      new, cryptographically random SID which is guaranteed not to
3727	      collide with any existing session.

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

3736	   The following arguments are optional.

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

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

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

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

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

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

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

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

3782	D.2  RecvMessage

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

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

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

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

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

3798	   Session-ID: The NSIS session identifier.

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

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

3811	   Transfer-Attributes: The reliability and security attributes that
3812	      were associated with the reception of this particular message.

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

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

3821	D.3  MessageStatus

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

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

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

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

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

3842	D.4  NetworkNotification

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

3847	   NetworkNotification ( MRI, Network-Notification-Type )

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

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

3856	D.5  SetStateLifetime

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

3863	   SetStateLifetime ( MRI, Direction, State-Lifetime )

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

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

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

3875	D.6  InvalidateRoutingState

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

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

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

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

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

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

3897	Intellectual Property Statement

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

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

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

3921	Disclaimer of Validity

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

3931	Copyright Statement

3933	   Copyright (C) The Internet Society (2005).  This document is subject
3934	   to the rights, licenses and restrictions contained in BCP 78, and
3935	   except as set forth therein, the authors retain all their rights.

3937	Acknowledgment

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