idnits 2.17.1 

draft-ietf-nsis-ntlp-04.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 3924.

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

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

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

  ** 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 :
  ----------------------------------------------------------------------------

     No issues found here.

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

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

  == Line 734 has weird spacing: '... uuuuuu    d>>...'

  -- 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 (October 24, 2004) is 7121 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 223

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

  -- Looks like a reference, but probably isn't: 'Message' on line 275

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

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

  == Unused Reference: '18' is defined on line 3110, 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-07

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

  -- 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 (-07) exists of draft-ietf-nsis-fw-06

  == Outdated reference: A later version (-06) exists of
     draft-ietf-nsis-threats-05

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

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

  == 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-16

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

  == 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-01


     Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 15 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: April 24, 2005                                       R. Hancock
5	                                                             Siemens/RMR
6	                                                        October 24, 2004

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

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 April 24, 2005.

38	Copyright Notice

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

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  . . . . . . . . . . . . . . . . .  13
66	     4.1  GIMPS Service Interface  . . . . . . . . . . . . . . . . .  13
67	     4.2  GIMPS State  . . . . . . . . . . . . . . . . . . . . . . .  14
68	     4.3  Basic Message Processing . . . . . . . . . . . . . . . . .  17
69	     4.4  Routing State and Messaging Association Maintenance  . . .  21
70	   5.   Message Formats and Transport  . . . . . . . . . . . . . . .  27
71	     5.1  GIMPS Messages . . . . . . . . . . . . . . . . . . . . . .  27
72	     5.2  Information Elements . . . . . . . . . . . . . . . . . . .  28
73	     5.3  Datagram Mode Transport  . . . . . . . . . . . . . . . . .  31
74	     5.4  Connection Mode Transport  . . . . . . . . . . . . . . . .  33
75	     5.5  Messaging Association Negotiation  . . . . . . . . . . . .  34
76	   6.   Advanced Protocol Features . . . . . . . . . . . . . . . . .  37
77	     6.1  Route Changes and Local Repair . . . . . . . . . . . . . .  37
78	     6.2  Policy-Based Forwarding and Flow Wildcarding . . . . . . .  43
79	     6.3  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  43
80	     6.4  Interaction with IP Tunnelling . . . . . . . . . . . . . .  45
81	     6.5  IPv4-IPv6 Transition and Interworking  . . . . . . . . . .  46
82	   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  48
83	     7.1  Message Confidentiality and Integrity  . . . . . . . . . .  48
84	     7.2  Peer Node Authentication . . . . . . . . . . . . . . . . .  49
85	     7.3  Routing State Integrity  . . . . . . . . . . . . . . . . .  49
86	     7.4  Denial of Service Prevention . . . . . . . . . . . . . . .  51
87	   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  53
88	   9.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  55
89	     9.1  Protocol Naming  . . . . . . . . . . . . . . . . . . . . .  55
90	     9.2  General IP Layer Issues  . . . . . . . . . . . . . . . . .  55
91	     9.3  Encapsulation and Addressing for Datagram Mode . . . . . .  56
92	     9.4  Intermediate Node Bypass and Router Alert Values . . . . .  57
93	     9.5  IP TTL Management  . . . . . . . . . . . . . . . . . . . .  58
94	     9.6  GIMPS Support for Message Scoping  . . . . . . . . . . . .  59
95	     9.7  Additional Discovery Mechanisms  . . . . . . . . . . . . .  59
96	     9.8  Alternative Message Routing Requirements . . . . . . . . .  60
97	     9.9  Message Format Issues  . . . . . . . . . . . . . . . . . .  61
98	     9.10   Inter-Layer Security Coordination  . . . . . . . . . . .  61
99	     9.11   Protocol Design Details  . . . . . . . . . . . . . . . .  62
100	   10.  Change History . . . . . . . . . . . . . . . . . . . . . . .  64
101	     10.1   Changes In Version -04 . . . . . . . . . . . . . . . . .  64
102	     10.2   Changes In Version -03 . . . . . . . . . . . . . . . . .  65
103	     10.3   Changes In Version -02 . . . . . . . . . . . . . . . . .  66
104	     10.4   Changes In Version -01 . . . . . . . . . . . . . . . . .  67
105	   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  69
106	   11.1   Normative References . . . . . . . . . . . . . . . . . . .  69
107	   11.2   Informative References . . . . . . . . . . . . . . . . . .  69
108	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  71
109	   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  72
110	   B.   Example Message Routing State Table  . . . . . . . . . . . .  73
111	   C.   Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . .  74
112	     C.1  General NSIS Formatting Guidelines . . . . . . . . . . . .  74
113	     C.2  The GIMPS Common Header  . . . . . . . . . . . . . . . . .  75
114	     C.3  General Object Characteristics . . . . . . . . . . . . . .  75
115	     C.4  GIMPS Specific TLV Objects . . . . . . . . . . . . . . . .  76
116	     C.5  Generic NSIS TLV Objects . . . . . . . . . . . . . . . . .  82
117	   D.   API between GIMPS and NSLP . . . . . . . . . . . . . . . . .  84
118	     D.1  SendMessage  . . . . . . . . . . . . . . . . . . . . . . .  84
119	     D.2  RecvMessage  . . . . . . . . . . . . . . . . . . . . . . .  86
120	     D.3  MessageDeliveryError . . . . . . . . . . . . . . . . . . .  87
121	     D.4  NetworkNotification  . . . . . . . . . . . . . . . . . . .  87
122	     D.5  SecurityProtocolAttributesRequest  . . . . . . . . . . . .  87
123	     D.6  SetStateLifetime . . . . . . . . . . . . . . . . . . . . .  88
124	     D.7  InvalidateRoutingState . . . . . . . . . . . . . . . . . .  88
125	        Intellectual Property and Copyright Statements . . . . . . .  89

127	1.  Introduction

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

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

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

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

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

175	1.1  Restrictions on Scope

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

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

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

193	2.  Requirements Notation and Terminology

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

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

203	   Source                GIMPS (adjacent) peer nodes         Destination

205	   IP address              IP addresses = Signaling          IP address
206	   = Flow                Source/Destination Addresses        = Flow
207	   Source             (depending on signaling direction)     Destination
208	   Address                  |                   |            Address
209	                            V                   V
210	   +--------+           +------+  Data Flow  +------+         +--------+
211	   |  Flow  |-----------|------|-------------|------|-------->|  Flow  |
212	   | Sender |           |      |             |      |         |Receiver|
213	   +--------+           |GIMPS |============>|GIMPS |         +--------+
214	                        | Node |<============| Node |
215	                        +------+  Signaling  +------+
216	                          GN1       Flow       GN2

218	                  >>>>>>>>>>>>>>>>>  =  Downstream direction
219	                  <<<<<<<<<<<<<<<<<  =  Upstream direction

221	                      Figure 1: Basic Terminology

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

227	   Session: A single application layer flow of information for which
228	      some network control state information is to be manipulated or
229	      monitored.  IP mobility may cause the mapping between sessions and
230	      flows to change, and IP multihoming may mean there is more than
231	      one flow for a given session.

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

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

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

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

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

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

254	   Datagram mode: A mode of sending GIMPS messages between nodes without
255	      using any transport layer state or security protection.  Upstream
256	      messages are sent UDP encapsulated directly to the signaling
257	      destination; downstream messages are typically sent towards the
258	      flow receiver with a router alert option.

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

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

275	   [Message] Transfer Attributes: A formal description of the
276	      requirements which a signaling application has for the delivery of
277	      a particular message towards its signaling application peer; for
278	      example, whether the message should be delivered reliably.  See
279	      Section 4.1.2.

281	3.  Design Overview

283	3.1  Overall Design Approach

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

289	   "Routing": Determine how to reach the adjacent signaling node along
290	      the data path (the GIMPS peer);

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

294	   To meet the routing requirement, for downstream signaling the node
295	   can either use local state information (e.g.  gathered during
296	   previous signaling exchanges) to determine the identity of the GIMPS
297	   peer explicitly, or it can just send the signaling towards the flow
298	   destination address and rely on the peer to intercept it.  For
299	   upstream signaling, only the first technique is possible.

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

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

321	   Internally, GIMPS has two modes of operation:

323	   Datagram mode: for small, infrequent messages with modest delay
324	      constraints; and

326	   Connection mode: for larger data objects or where fast state setup in
327	      the face of packet loss is desirable, or where channel security is
328	      required.

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

369	           Figure 2: Protocol Stacks for Signaling Transport

371	   The datagram mode uses an unreliable unsecured datagram transport
372	   mechanism, with UDP as the initial choice.  The connection mode can
373	   in principal use any stream or message-oriented transport protocol;
374	   this specification currently defines the use of TCP as the initial
375	   choice.  It may employ specific network layer security associations
376	   (such as IPsec), or an internal transport layer security association
377	   (such as TLS).

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

387	   It must be understood that the routing and transport decisions made
388	   by GIMPS are not totally independent.  If the message transfer has
389	   requirements that enforce the use of connection mode (e.g.  the
390	   message is so large that fragmentation is required), this can only be
391	   used between explicitly identified nodes.  In such cases, the GIMPS
392	   node must carry out signaling in datagram mode to identify the peer
393	   and then set up the necessary transport connection.  The datagram
394	   mode option of sending the message in the direction of the flow
395	   receiver and relying on interception is not available.  In any case,
396	   it must also be understood that the signaling application does not
397	   make the datagram vs.  connection mode selection directly; rather,
398	   this decision is made by GIMPS on the basis of the message transfer
399	   attributes stated by the application, and the distinction between the
400	   modes is not visible at the GIMPS service interface.

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

410	3.2  Example of Operation

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

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

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

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

444	   3.  GN1 therefore constructs a UDP datagram with the signaling
445	       application payload, and additional payloads at the GIMPS level
446	       to be used to initiate the setup of a messaging association (a
447	       "GIMPS-query").  This datagram is injected into the network,
448	       addressed towards the flow destination and with a Router Alert
449	       Option included.

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

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

466	   6.  In parallel, the GIMPS instance in GN2 recognises that GN1 is
467	       attempting to discover GN2 in order to set up a messaging
468	       association for future signaling for the flow.  There are two
469	       possible cases (in either case the resulting message is referred
470	       to as a "GIMPS-response"):

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

478	       B.  No messaging association exists.  Again, GN2 records the
479	           identity of GN1 as before, but sends an upstream D-mode
480	           message to GN1, identifying itself and agreeing to the
481	           association setup.  The protocol exchanges needed to complete
482	           this will proceed in the background, controlled by GN1.

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

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

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

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

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

524	4.  GIMPS Processing Overview

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

539	4.1  GIMPS Service Interface

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

555	4.1.1  Message Handling

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

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

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

581	4.1.2  Message Transfer Attributes

583	   Message transfer attributes are used to define certain
584	   performance-related aspects of message processing.  The attributes
585	   available are as follows:

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

596	   Security: This attribute defines the security properties that the
597	      signaling application requires for the message, including the type
598	      of protection and identity information about the peer.  Details
599	      are for further study (see Section 9.10).

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

612	4.2  GIMPS State

614	4.2.1  Message Routing State

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

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

624	   Message Routing Information (MRI): This defines the method to be used
625	      to route the message, and any associated addressing information.
626	      In the simplest case, the message routing method is to follow the
627	      path that is being taken by the data flow, and the associated
628	      addressing is the flow header N-tuple (i.e.  the Flow-Identifier
629	      of [20]).

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

637	   Session Identification (SID): This is a cryptographically random and
638	      (probabilistically) globally unique identifier of the application
639	      layer session that is using the flow.  For a given flow, different
640	      signaling applications may or may not use the same session
641	      identifier.  Often there will only be one flow for a given
642	      session, but in mobility/multihoming scenarios there may be more
643	      than one and they may be differently routed.

645	   For a given MRI and NSLPID the message routing state should not be
646	   SID-dependent.  The SID is included in the key to prevent upstream
647	   routing state for a given MRI being corrupted by a malicious upstream
648	   node.

650	   The state information for a given key is as follows:

652	   Upstream peer: the adjacent peer closer to the flow source.  This
653	      could be an IP address and UDP port (learned from previous
654	      signaling) or a pointer to a valid messaging association.  It
655	      could also be null, if this node is not storing reverse routing
656	      state or if it is the last upstream node (including the sender).

658	   Downstream peer: the adjacent peer closer to the flow destination.
659	      This could be a pointer to a valid messaging association, or it
660	      could be null, if this node is only sending downstream datagram
661	      mode messages for this flow and signaling application, or if it is
662	      the last downstream node (including the receiver).

664	   Note that both the upstream and downstream peer state may be null,
665	   and that the session identifier information is not actually required
666	   for message processing; in that case, no state information at all
667	   needs to be stored in the table.  Both items of state have associated
668	   timers for how long the identification can be considered accurate;
669	   when these timers expire, the peer identification is purged if it has
670	   not been refreshed.  Message routing state is installed and refreshed
671	   by the exchange of specific GIMPS messages as described in Section
672	   4.4.  For a given flow, a GIMPS node is responsible for scheduling
673	   the messages which refresh its own downstream peer state and allow
674	   its downstream peer to refresh its upstream peer state, and this
675	   should be done while GIMPS determines the signaling application is
676	   still active.  GIMPS may opportunistically synchronise these
677	   'internal' refresh operations with those in the signaling application
678	   if it wishes.  An example of a routing state table for a simple
679	   scenario is given in Appendix B.

681	   Note also that the information is described as a table of flows, but
682	   that there is no implied constraint on how the information is stored.
683	   For example, in a network using pure destination address routing
684	   (without load sharing or any form of policy-based forwarding), the
685	   downstream peer information might be possible to store in an
686	   aggregated form in the same manner as the IP forwarding table.  In
687	   addition, many of the per-flow entries may point to the same per-peer
688	   state (e.g.  the same messaging association) if the flows go through
689	   the same adjacent peer.  However, in general, and especially if GIMPS
690	   peers are several IP hops away, there is no way to identify the
691	   correct downstream peer for a flow and signaling application from the
692	   local forwarding table using prefix matching, and the same applies
693	   always to upstream peer state because of the possibility of
694	   asymmetric routing: per-flow routing state has to be stored, just as
695	   for RSVP [9].

697	4.2.2  Messaging Association State

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

705	   o  messages pending transmission while an association is being
706	      established;

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

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

715	       +---------------------------------------------------------+
716	       |        >>  Signaling Application Processing   >>        |
717	       |                                                         |
718	       +--------^---------------------------------------V--------+
719	                ^                                       V
720	                ^             NSLP Payloads             V
721	                ^                                       V
722	       +--------^---------------------------------------V--------+
723	       |                    >>    GIMPS   >>                     |
724	       |  ^           ^  ^     Processing      V  V           V  |
725	       +--x-----------u--d---------------------d--u-----------x--+
726	          x           u  d                     d  u           x
727	          x           u  d>>>>>>>>>>>>>>>>>>>>>d  u           x
728	          x           u  d      Bypass at      d  u           x
729	       +--x-----+  +--u--d--+  GIMPS level  +--d--u--+  +-----x--+
730	       | C-mode |  | D-mode |               | D-mode |  | C-mode |
731	       |Handling|  |Handling|               |Handling|  |Handling|
732	       +--x-----+  +--u--d--+               +--d--u--+  +-----x--+
733	          x          u   d                     d   u          x
734	          x    uuuuuu    d>>>>>>>>>>>>>>>>>>>>>d    uuuuuu    x
735	          x   u          d      Bypass at      d          u   x
736	       +--x--u--+  +-----d--+    router     +--d-----+  +--u--x--+
737	       |IP Host |  |  RAO   |  alert level  |  RAO   |  |IP Host |
738	       |Handling|  |Handling|               |Handling|  |Handling|
739	       +--x--u--+  +-----d--+               +--d-----+  +--u--x--+
740	          x  u           d                     d           u  x
741	       +--x--u-----------d--+               +--d-----------u--x--+
742	       |      IP Layer      |               |      IP Layer      |
743	       |   (Receive Side)   |               |  (Transmit Side)   |
744	       +--x--u-----------d--+               +--d-----------u--x--+
745	          x  u           d                     d           u  x
746	          x  u           d                     d           u  x
747	          x  u           d                     d           u  x

749	            uuuuuuuuuuuuuu = upstream datagram mode messages
750	            dddddddddddddd = downstream datagram mode messages
751	            xxxxxxxxxxxxxx = connection mode messages
752	                       RAO = Router Alert Option

754	              Figure 3: Message Paths through a GIMPS Node

756	4.3  Basic Message Processing

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

768	   Note that the same messages are used for maintaining internal GIMPS
769	   state and carrying signaling application payloads.  The state
770	   maintenance takes place as a result of processing specific GIMPS
771	   payloads in these messages.  The processing of these payloads is the
772	   subject of Section 4.4.

774	4.3.1  Message Reception

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

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

787	   Reception in datagram mode depends on the message direction.
788	   Upstream messages (from a downstream peer) will arrive UDP
789	   encapsulated and addressed directly to the receiving signaling node.
790	   Each datagram contains a single complete message which is passed to
791	   the GIMPS layer for further processing, just as in the connection
792	   mode case.

794	   Downstream datagram mode messages are UDP encapsulated with an IP
795	   router alert option to cause interception.  The signaling node will
796	   therefore 'see' all such messages.  The case where the NSLPID does
797	   not match a local signaling application is considered below in
798	   Section 4.3.4; otherwise, it is passed up to the GIMPS layer for
799	   further processing as in the other cases.

801	4.3.2  Local Processing

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

808	   One GIMPS-internal payload which is carried in each message and
809	   requires processing is the GIMPS hop count.  This is decremented on
810	   input processing, and checked to be greater than zero on output
811	   processing.  The primary purpose of the GIMPS hop count is to prevent
812	   message looping.

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

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

824	4.3.3  Message Transmission

826	   When a message is available for transmission, GIMPS uses internal
827	   policy and the stored routing state to determine how to handle it.
828	   The following processing applies equally to locally generated
829	   messages and messages forwarded from within the GIMPS or signaling
830	   application levels.

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

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

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

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

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

851	   If the use of a messaging association is selected, the message is
852	   queued on the association (found from the upstream or downstream peer
853	   state table), and further output processing is carried out according
854	   to the details of the protocol stack used for the association.  If no
855	   appropriate association exists, the message is queued while one is
856	   created (see Section 4.4).  If no association can be created, this is
857	   again an error condition, and should be indicated back to the NSLP.

859	   If a messaging association is not required, the message is sent in
860	   datagram mode.  The processing in this case depends on whether the
861	   message is directed upstream or downstream.

863	   o  If the upstream peer IP address is available from the per-flow
864	      routing table, the message is UDP encapsulated and sent directly
865	      to that address.  Otherwise, the message cannot be forwarded (i.e.
866	      this is again an error condition).

868	   o  In the downstream direction, messages can always be sent.  They
869	      are simply UDP encapsulated and IP addressed using information
870	      from the MRI, with the appropriate router alert option.

872	4.3.4  Bypass Forwarding

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

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

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

889	   3.  A message is delivered directly (e.g.  in C-mode) to the node for
890	       which there is no corresponding signaling application.
891	       (According to the rules of the current specification, this should
892	       never happen.  However, future versions might find a use for such
893	       a feature.)

895	   In all cases, the role of GIMPS is to forward the message essentially
896	   unchanged.  However, a GIMPS implementation must ensure that the IP
897	   TTL field and GIMPS hop count are managed correctly to prevent
898	   message looping, and this should be done consistently independently
899	   of whether the processing (e.g.  for case (1)) takes place on the
900	   fast path or in GIMPS-specific code.  The rules are that in cases (1)
901	   and (2), the IP TTL is decremented just as if the message was a
902	   normal IP forwarded packet; in cases (2) and (3) the GIMPS hop count
903	   is decremented as in the case of normal input processing.  These
904	   rules are summarised in the following table:

906	   +-------------+-------------+-------------------+-------------------+
907	   |  Match RAO? |    Match    |  IP TTL Handling  |    GHC Handling   |
908	   |             |   NSLPID?   |                   |                   |
909	   +-------------+-------------+-------------------+-------------------+
910	   |      No     | N/A (NSLPID |     Decrement;    |       Ignore      |
911	   |             |     not     |  forward message  |                   |
912	   |             |  examined)  |                   |                   |
913	   |             |             |                   |                   |
914	   |     Yes     |      No     |     Decrement;    |    Decremented    |
915	   |             |             |  forward message  |                   |
916	   |             |             |                   |                   |
917	   |   Message   |      No     |       Reset       |   Decrement and   |
918	   |   directly  |             |                   |  forward at GIMPS |
919	   |  addressed  |             |                   |     level (not    |
920	   |             |             |                   |    possible in    |
921	   |             |             |                   |      current      |
922	   |             |             |                   |   specification)  |
923	   |             |             |                   |                   |
924	   |   Yes, or   |     Yes     | Locally delivered |   N/A (ignored)   |
925	   |   message   |             |                   |                   |
926	   |   directly  |             |                   |                   |
927	   |  addressed  |             |                   |                   |
928	   +-------------+-------------+-------------------+-------------------+

930	4.4  Routing State and Messaging Association Maintenance

932	   The main responsibility of the GIMPS layer is to manage the routing
933	   state and messaging associations which are used in the basic message
934	   processing described above.  Routing state is installed and
935	   maintained by datagram mode messages containing specific GIMPS
936	   payloads.  Messaging associations are dependent on the existence of
937	   routing state, but are actually set up by the normal procedures of
938	   the transport and security protocols that comprise them.  Timers
939	   control routing state and messaging association refresh and
940	   expiration.

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

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

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

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

953	4.4.1  State Setup

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

959	   The initial message in any routing state maintenance operation is a
960	   downstream datagram mode message, sent from the querying node and
961	   intercepted at the responding node.  This is encapsulated and
962	   addressed just as in the normal case; in particular, it has
963	   addressing and other identifiers appropriate for the flow and
964	   signaling application that state maintenance is being done for, its
965	   own addressing information, and it is allowed to contain an NSLP
966	   payload.  Processing at the querying and responding nodes is also
967	   essentially the same.  However, the querying node can include
968	   additional payloads: a Query Cookie, and optionally a proposal for
969	   possible messaging association protocol stacks.  This message is
970	   informally referred to as a 'GIMPS-query'.  The role of the cookies
971	   in this and subsequent messages is to protect against certain denial
972	   of service attacks and to correlate the various events in the message
973	   sequence.

975	   In the responding node, the GIMPS level processing of the GIMPS-Query
976	   triggers the generation of a 'GIMPS-Response' message.  This is also
977	   a normally encapsulated and addressed datagram mode message with
978	   particular payloads, this time in the upstream direction.  It
979	   contains addressing information and echoes the Query Cookie, and can
980	   contain an NSLP payload (possibly a response to the NSLP payload in
981	   the initial message).  In case a messaging association was requested,
982	   it must also contain a Responder Cookie and counter proposal for the
983	   stack configuration.  Otherwise, it may still include a Responder
984	   Cookie if the node's routing state setup policy requires it (see
985	   below).

987	   Setup of a new messaging association begins when both downstream peer
988	   addressing information is available and a new messaging association
989	   is actually needed.  The setup has to be contemporaneous with a
990	   specific GIMPS-Query/Response exchange, because the addressing
991	   information used may have a limited lifetime (either because it
992	   depends on limited lifetime NAT bindings, or because it refers to
993	   agile destination ports for the transport protocols).  Setup of the
994	   messaging association always starts from the upstream node, but the
995	   association itself can be used equally in both directions.

997	            +----------+                     +----------+
998	            | Querying |                     |Responding|
999	            |   Node   |                     |   Node   |
1000	            +----------+                     +----------+
1001	                             GIMPS-query
1002	                       ---------------------->    .............
1003	                       Router Alert Option        .  Routing  .
1004	                       MRI/SID/NSLPID             .   state   .
1005	                       Q-Node Addressing          . installed .
1006	                       Query Cookie               .    at     .
1007	                       [Q-Stack Proposal]         . R-node(1) .
1008	                       [NSLP Payload]             .............

1010	               ......................................
1011	               .  The responder can use an existing .
1012	               . messaging association if available .
1013	               . from here onwards to short-circuit .
1014	               .     messaging association setup    .
1015	               ......................................

1017	                           GIMPS-response
1018	   .............       <----------------------
1019	   .  Routing  .       MRI/SID/NSLPID
1020	   .   state   .       R-Node Addressing (D Mode only)
1021	   . installed .       Query cookie
1022	   .    at     .       [R-Stack Proposal]
1023	   .  Q-node   .       [Responder Cookie]
1024	   .............       [NSLP Payload]

1026	                ....................................
1027	                . If a messaging association needs .
1028	                . to be created, it is set up here .
1029	                ....................................

1031	                           GIMPS-confirm
1032	                       ---------------------->
1033	                       MRI/SID/NSLPID
1034	                       Q-Node Addressing (D Mode only)
1035	                       Responder Cookie           .............
1036	                       [R-Stack Proposal]         .  Routing  .
1037	                       [NSLP Payload]             .   state   .
1038	                                                  . installed .
1039	                                                  .    at     .
1040	                                                  . R-node(2) .
1041	                                                  .............

1043	               Figure 4: Message Sequence at State Setup

1045	   The GIMPS-confirm is the first message sent over the association and
1046	   echoes the Responder Cookie and Stack Proposal from the
1047	   GIMPS-response (the latter is to prevent certain bidding-down attacks
1048	   on messaging association security); the assocation can be used in the
1049	   upstream direction after it has been received.  The negotiation of
1050	   what protocols to use for the messaging association is controlled by
1051	   the Stack Proposal and Node-Addressing information exchanged, and the
1052	   processing of these objects is described in more detail in Section
1053	   5.5.

1055	   The querying node installs the responder address as downstream peer
1056	   state information after verifying the Query Cookie in the
1057	   GIMPS-response.  The responding node can install the querying address
1058	   as upstream peer state information at two points in time:

1060	   1.  after the receipt of the initial GIMPS-query, or

1062	   2.  after a GIMPS-confirm message in the downstream direction
1063	       containing the Responder Cookie.

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

1070	4.4.2  Association Re-use

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

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

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

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

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

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

1110	   Association re-use is controlled by matching the NAO provided in the
1111	   current GIMPS D mode message with those associated with existing
1112	   associations.  This can be done on receiving either the GIMPS-query
1113	   or GIMPS-response message (the former is more likely):

1115	   o  If there is a perfect match to the NAO of an existing association,
1116	      that association can be re-used (provided it has the appropriate
1117	      properties in other respects).  This is indicated by sending the
1118	      following messages in the setup sequence over that association,
1119	      omitting the NAO information.  This will only fail (i.e.  lead to
1120	      re-use of an assocation to the 'wrong' node) if signaling nodes
1121	      have colliding Peer-Identities, and one is reachable at the same
1122	      Interface-Address as another.  (This could be done by an on-path
1123	      attacker.)

1125	   o  In all other cases, the usual D mode setup procedure is executed.
1126	      There are in fact four cases:

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

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

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

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

1146	4.4.3  Background Maintenance

1148	   Refresh and expiration of all types of state is controlled by timers.
1149	   State in the routing table has a per-flow, per-direction timer, which
1150	   expires after a routing state lifetime.  It is the responsibility of
1151	   the querying node to generate a GIMPS-query message before this timer
1152	   expires, if it believes that the flow is still active.  Receipt of
1153	   the message at the responding node will refresh upstream peer
1154	   addressing state, and receipt of a GIMPS-response at the querying
1155	   node will refresh any downstream peer addressing state if it exists.
1156	   Note that nodes do not control the refresh of upstream peer state
1157	   themselves, they are dependent on their upstream peer for this.

1159	   Messaging associations can be managed by either end; management
1160	   consists of tearing down unneeded associations.  Whether an
1161	   association is needed is a local policy decision, which could take
1162	   into account the cost of keeping the messaging association open, the
1163	   level of past activity on the association, and the likelihood of
1164	   future activity (e.g.  if there are flows still in place which might
1165	   generate messages that would use it).  Messaging associations can
1166	   always be set up on demand, and messaging association status is not
1167	   made directly visible outside the GIMPS layer.  Therefore, even if
1168	   GIMPS tears down and later re-establishes a messaging association,
1169	   signaling applications cannot distinguish this from the case where
1170	   the association is kept permanently open.  (To maintain the transport
1171	   semantics decribed in Section 4.1, GIMPS must close transport
1172	   connections carrying reliable messages gracefully or report an error
1173	   condition, and must not open a new association for a given session
1174	   and peer while messages on a previous association may still be
1175	   outstanding.)

1177	5.  Message Formats and Transport

1179	5.1  GIMPS Messages

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

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

1192	   GIMPS-message: A message is either a datagram mode message or a
1193	   connection mode message.  GIMPS can detect which by the encapsulation
1194	   the message arrives over.

1196	       GIMPS-message = D-message / C-message

1198	   D-message: A datagram mode message may carry simply NSLP data, or may
1199	   be used for control operations also, in which case the allowed
1200	   objects depend on the message direction (slightly different contents
1201	   are allowed); the common header contains a flag to say which.

1203	       D-message = Common-Header
1204	                   Message-Routing-Information
1205	                   Session-Identification
1206	                   Node-Addressing
1207	                   NSLP-Data / D-control-ds / D-control-us

1209	   D-control-ds: A downstream control message requires extra payloads
1210	   for the GIMPS-query or GIMPS-confirm functions.  The type can be
1211	   inferred from which type of cookie is carried.  A stack proposal is
1212	   mandatory if the message exchange relates to setup of a messaging
1213	   association.

1215	       D-control-ds = Query-Cookie / Responder-Cookie
1216	                      [ Stack-Proposal ]
1217	                      [ Routing-State-Lifetime ]
1218	                      [ NSLP-Data ]

1220	   D-control-us: An upstream control message requires extra payloads for
1221	   the GIMPS-response function.  A stack proposal is mandatory if the
1222	   message exchange relates to setup of a messaging association, in
1223	   which case a Responder cookie is also mandatory.

1225	       D-control-us = Query-Cookie
1226	                      [ Responder-Cookie [ Stack-Proposal ] ]
1227	                      [ Routing-State-Lifetime ]
1228	                      [ NSLP-Data ]

1230	   C-message: Again, a connection mode message may carry simply NSLP
1231	   data, or may be used for control operations also.  Connection mode
1232	   messages do not carry node addressing, since this can be inferred
1233	   from the messaging association.

1235	       C-message = Common-Header
1236	                   Message-Routing-Information
1237	                   Session-Identification
1238	                   NSLP-Data / C-control-ds / C-control-us

1240	   C-control-ds: A downstream control message requires extra payloads
1241	   for the GIMPS-confirm function.  A stack proposal is mandatory here.

1243	       C-control-ds = Responder-Cookie
1244	                      Stack-Proposal
1245	                      [ Routing-State-Lifetime ]
1246	                      [ NSLP-Data ]

1248	   C-control-us: An upstream control message requires extra payloads for
1249	   the GIMPS-response function.  In C-mode, this is short-circuiting the
1250	   messaging association setup, so no additional cookies or stack
1251	   proposals are needed.

1253	       C-control-us = Query-Cookie
1254	                      [ Routing-State-Lifetime ]
1255	                      [ NSLP-Data ]

1257	5.2  Information Elements

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

1264	5.2.1  The Common Header

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

1269	   Version: The version number of the GIMPS protocol.

1271	   Length: The number of words in the message following the common
1272	      header.

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

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

1281	   U/D flag: A bit to indicate if this message is to propagate upstream
1282	      or downstream relative to the flow.

1284	5.2.2  TLV Objects

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

1291	   These items are contained in each GIMPS message:

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

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

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

1307	      The MRI is essentially a read only object for GIMPS processing.
1308	      It is set by the NSLP in the message sender and used by GIMPS to
1309	      select the message addressing, but not otherwise modified.

1311	       Flow-Identifier = network-layer-version
1312	                         source-address prefix-length
1313	                         destination-address prefix-length
1314	                         IP-protocol
1315	                         traffic-class
1316	                         [ flow-label ]
1317	                         [ ipsec-SPI / L4-ports]

1319	      Additional control information defines whether the flow-label, SPI
1320	      and port information are present, and whether the IP-protocol and
1321	      traffic-class fields should be interpreted as significant.

1323	   Session-Identification (SID): The GIMPS session identifier is a long,
1324	      cryptographically random identifier chosen by the node which
1325	      originates the signaling exchange.  The length is open, but 128
1326	      bits should be more than sufficient to make the probability of
1327	      collisions orders of magnitude lower than other failure reasons.
1328	      The session identifier should be considered immutable end-to-end
1329	      along the flow path (GIMPS never changes it, and signaling
1330	      applications should propagate it unchanged on messages for the
1331	      same session).

1333	   The following items are optional:

1335	   Node addressing: This includes an IP address and peer identity for
1336	      the sending node, as well as higher layer addressing information
1337	      for the negotiation of messaging association protocols.

1339	       Node-Addressing = peer-identity
1340	                         interface-address
1341	                         *higher-layer-addressing

1343	       The peer-identity is used for matching existing associations, as
1344	      discussed in Section 4.4.2.  Any technique may be used to generate
1345	      it, so long as it is stable.  The interface-address should be a
1346	      routable address where the sending node can be reached over UDP or
1347	      messaging association protocols.  Where this object is used in a
1348	      GIMPS-query, it should specifically be set to the address of the
1349	      interface that will be used for the outbound flow, to allow its
1350	      use in route change handling, see Section 6.1.  The purpose and
1351	      structure of the higher-layer-addressing fields is described in
1352	      Section 5.5.

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

1359	       Stack-Proposal = *stack-profile

1361	       stack-profile = *protocol-layer

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

1368	   Query-Cookie/Responder-Cookie: A query-cookie is contained in a
1369	      GIMPS-query message and must be echoed in a GIMPS-response; a
1370	      response-cookie is optional in a GIMPS-response message, and if
1371	      present must be echoed in the following GIMPS-confirm message.
1372	      Cookies are variable length (chosen by the cookie generator) and
1373	      need to be designed so that a node can determine the validity of a
1374	      cookie without keeping state.  A future version of this
1375	      specification will include references to techniques for generating
1376	      such cookies.

1378	   Routing-State-Lifetime: The lifetime of GIMPS routing state in the
1379	      absence of refreshes, measured in seconds.  Defaults to 30
1380	      seconds.

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

1385	5.3  Datagram Mode Transport

1387	5.3.1  Encapsulation

1389	   Encapsulation in datagram mode is simple.  The complete set of GIMPS
1390	   payloads for a single message is concatenated together with the
1391	   common header, and placed in the data field of a UDP datagram.  UDP
1392	   checksums should be enabled.  Upstream messages are IP addressed
1393	   directly to the adjacent peer.  Downstream messages are IP addressed
1394	   using the flow destination address from the
1395	   Message-Routing-Information and encapsulated with a Router Alert
1396	   Option.  Open issues about alternative encapsulations, IP addressing
1397	   possibilities, and router alert option value-field setting are
1398	   discussed in Section 9.2, Section 9.3 and Section 9.4 respectively.

1400	   For downstream messages, the source UDP port is selected by the
1401	   message sender as the port at which it is prepared to receive
1402	   upstream UDP messages in reply, and a destination UDP port should be
1403	   allocated by IANA.  Note that GIMPS may send messages addressed as
1404	   {flow sender, flow receiver} which could make their way to the flow
1405	   receiver even if that receiver were GIMPS-unaware.  This should be
1406	   rejected (with an ICMP message) rather than delivered to the user
1407	   application (which would be unable to use the source address to
1408	   identify it as not being part of the normal data flow).  Therefore, a
1409	   "well-known" port would seem to be required.  Upstream messages are
1410	   sent with the source and destination ports from the downstream
1411	   message reversed (as for normal UDP traffic).

1413	   For the case of basic path-coupled signaling where the MRI
1414	   information is the Flow Identifier, it is vital that the D-mode
1415	   message truly mimics the actual data flow, since this is the basis of
1416	   how the signaling message is attached to the data path.  To this end,
1417	   GIMPS may set the traffic class and (for IPv6) flow label to match
1418	   the values in the Flow-Identifier if this would be needed to ensure
1419	   correct routing.  Similar considerations may apply to other message
1420	   routing methods if defined.

1422	5.3.2  Retransmission and Rate-Control

1424	   Datagram mode is built on top of UDP, and hence has no automatic
1425	   reliability or congestion control capabilities.  Signalling
1426	   applications requiring reliability should be serviced using C-mode,
1427	   which should also carry the bulk of signaling traffic.  However, some
1428	   form of messaging reliability is required for the GIMPS control
1429	   messages themselves, as is rate control to handle retransmissions and
1430	   also bursts of unreliable signaling or state setup requests from the
1431	   signaling applications.

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

1448	   Other datagram mode messages are not retransmitted.  In particular,
1449	   GIMPS-responses do not need reliability; if they are lost, the
1450	   initiating query will eventually be resent.  There is an open issue
1451	   on how to handle lost GIMPS-confirms, see Section 9.11.

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

1464	5.4  Connection Mode Transport

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

1471	5.4.1  Choice of Transport Protocol

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

1478	   SCTP [6] satisfies all requirements.

1480	   DCCP [7] is message based but does not provide bundling or
1481	      fragmentation.  Bundling can be carried out by the GIMPS layer
1482	      sending multiple messages in a single datagram; because the common
1483	      header includes length information (number of TLVs), the message
1484	      boundaries within the datagram can be discovered during parsing.
1485	      Fragmentation of GIMPS messages over multiple datagrams should be
1486	      avoided, because of amplification of message loss rates that this
1487	      would cause.

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

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

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

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

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

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

1522	5.4.2  Encapsulation Format

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

1531	      +---------------------------------------------+
1532	      |                  L2 Header                  |
1533	      +---------------------------------------------+
1534	      |                  IP Header                  |   ^
1535	      |      Source address = signaling source      |   ^
1536	      | Destination address = signaling destination |   .
1537	      +---------------------------------------------+   .
1538	      |                  L4 Header                  |   . ^
1539	      |     (Standard TCP/SCTP/DCCP/UDP header)     |   . ^
1540	      +---------------------------------------------+   . .
1541	      |                GIMPS Message                |   . . ^
1542	      | (Common header and TLVs as in section 5.1)  |   . . ^  Scope of
1543	      +---------------------------------------------+   . . .  security
1544	      | Additional GIMPS messages, each with its    |   . . . protection
1545	      | own common header, either as a continuous   |   . . . (depending
1546	      |   stream, or continuing to the next L4      |   . . . on channel
1547	      .             message boundary                .   . . .  security
1548	      .                                             .   V V V  mechanism
1549	      .                                             .   V V V   in use)

1551	                Figure 5: Connection Mode Encapsulation

1553	5.5  Messaging Association Negotiation

1555	5.5.1  Overview

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

1568	   Protocol negotiation is carried out in GIMPS-query/response messages,
1569	   using Stack-Proposal and Node-Addressing objects.  If a new messaging
1570	   association is required it is then set up, followed by a
1571	   GIMPS-confirm.  Messaging association re-use is achieved by
1572	   short-circuiting this exchange by sending the GIMPS-response or
1573	   GIMPS-confirm messages on an existing association (Section 4.4.2);
1574	   whether to do this is a matter of local policy at the querying or
1575	   responding node.  It is always possible for a node to restrict itself
1576	   to a single messaging association between two peers.  If multiple
1577	   assocations exist, it is a matter of local policy how to distribute
1578	   messages over them, subject to respecting the transfer attributes
1579	   requested.

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

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

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

1590	   o  Formats for carrying the protocol addressing and other
1591	      configuration information in higher-layer-addressing information
1592	      elements.  There are different formats depending on whether the
1593	      information is being sent upstream or downstream.

1595	   A Stack-Proposal object is simply a list of profiles; each profile is
1596	   a sequence of Protocol-Identifiers.  Stack-Proposals are generally
1597	   accompanied by Node-Addressing objects; as well as a Peer-Identity
1598	   and Interface-Address, this carries a higher-layer-addressing
1599	   information element for every protocol listed in the Stack-Proposal.
1600	   A node generating a Node-Addressing object is committed to honouring
1601	   the implied protocol configuration; in particular, it must be
1602	   prepared to accept incoming datagrams or connections at the
1603	   Interface-Address/protocol/port combinations advertised.  However,
1604	   the object contents should be retained only for the duration of the
1605	   query/response exchange and any following association setup and
1606	   afterwards discarded.  (They may become invalid because of expired
1607	   bindings at intermediate NATs, or because the advertising node is
1608	   using agile ports.)

1610	   A GIMPS-query requesting association setup always contains a
1611	   Stack-Proposal and Node-Addressing object, and unless re-use occurs,
1612	   the GIMPS-response does so also.  For a GIMPS-response, the
1613	   Stack-Proposal must be invariant for the combination of outgoing
1614	   interface and NSLPID (it must not depend on the GIMPS-query).  Once
1615	   the messaging association is set up, the querying node repeats only
1616	   the responder's Stack-Proposal over it in the GIMPS-confirm.  The
1617	   resonding node can verify this to ensure that no bidding-down attack
1618	   has occurred.

1620	5.5.2  Protocol Definition: Forwards-TCP

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

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

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

1634	5.5.3  Additional Protocol Options

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

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

1644	   o  SigComp [17] for message compression.

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

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

1651	6.  Advanced Protocol Features

1653	6.1  Route Changes and Local Repair

1655	6.1.1  Introduction

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

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

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

1683	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1684	               x  +--+        +--+        +--+  x      Initial
1685	              x  .|B1|_.......|C1|_.......|D1|   x     Configuration
1686	             x  . +--+.      .+--+.      .+--+\.  x
1687	            x  .       .    .      .    .       .  x
1688	    >>xxxxxx  .         .  .        .  .         .  xxxxxx>>
1689	         +-+ .           ..          ..           . +-+
1690	    .....|A|/            ..          ..            .|E|_....
1691	         +-+ .          .  .        .  .          . +-+
1692	              .        .    .      .    .        .
1693	               .      .      .    .      .      .
1694	                . +--+        +--+        +--+ .
1695	                 .|B2|_.......|C2|_.......|D2|/
1696	                  +--+        +--+        +--+

1698	                  +--+        +--+        +--+         Configuration
1699	                 .|B1|........|C1|........|D1|         after failure
1700	                . +--+       .+--+        +--+         of D1-E link
1701	               .      \.    .     \.    ./
1702	              .         .  .        .  .
1703	         +-+ .           ..          ..             +-+
1704	    .....|A|.            ..          ..            .|E|_....
1705	         +-+\.          .  .        .  .          . +-+
1706	    >>xxxxxx  .        .    .      .    .        .  xxxxxx>>
1707	            x  .      .      .    .      .      .  x
1708	             x  . +--+        +--+        +--+ .  x
1709	              x  .|B2|_.......|C2|_.......|D2|/  x
1710	               x  +--+        +--+        +--+  x
1711	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

1715	               >>xxxxxxx>> = flow direction

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

1721	                      Figure 6: A Re-Routing Event

1723	6.1.2  Route Change Detection

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

1727	   o  Detecting that the downstream path has (or may have) changed.

1729	   o  Detecting that the upstream path has (or may have) changed (in
1730	      which case the node may no longer be on the path at all).

1732	   At a single node, these processes are largely independent, although
1733	   clearly a change in downstream path at a node corresponds to a change
1734	   in upstream path at the downstream peer.  Note that there are two
1735	   possible aspects of route change:

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

1740	   Peer: The adjacent upstream peer or downstream peer may change.

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

1746	   There are five mechanisms for a GIMPS node to detect that a route
1747	   change has occurred, which are listed below.  They apply differently
1748	   depending on whether the change is in the upstream or downstream
1749	   path, and these differences are summarised in the following table.

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

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

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

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

1780	   GIMPS D-mode Probing: In probing mode, each GIMPS node periodically
1781	      repeats the discovery (GIMPS-query/GIMPS-response) operation.  The
1782	      querying node will discover the route change by a modification in
1783	      the Node-Addressing information in the GIMPS-response.  This is
1784	      similar to RSVP behavior, except that there is an extra degree of
1785	      freedom since not every message needs to repeat the discovery,
1786	      depending on the likely stability of routes.  All indications are
1787	      that, leaving mobility aside, routes are stable for hours and
1788	      days, so this may not be necessary on a 30-second interval,
1789	      especially if the other techniques listed above are available.

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

1799	   +----------------------+----------------------+---------------------+
1800	   | Method               | Downstream           | Upstream            |
1801	   +----------------------+----------------------+---------------------+
1802	   | Local Trigger        | Discovers new        | Not applicable      |
1803	   |                      | downstream interface |                     |
1804	   |                      | (and peer if local)  |                     |
1805	   |                      |                      |                     |
1806	   | Extended Trigger     | Discovers new        | May determine that  |
1807	   |                      | downstream interface | route from upstream |
1808	   |                      | and may determine    | peer will have      |
1809	   |                      | new downstream peer  | changed             |
1810	   |                      |                      |                     |
1811	   | C-Mode Monitoring    | Provides hint that   | Provides hint that  |
1812	   |                      | change has occurred  | change has occurred |
1813	   |                      |                      |                     |
1814	   | Data Plane           | Not applicable       | NSLP informs GIMPS  |
1815	   | Monitoring           |                      | that a change may   |
1816	   |                      |                      | have occurred       |
1817	   |                      |                      |                     |
1818	   | D-Mode Probing       | Discovers changed    | Discovers changed   |
1819	   |                      | Node-Addressing in   | Node-Addressing in  |
1820	   |                      | GIMPS-response       | GIMPS-query         |
1821	   +----------------------+----------------------+---------------------+

1823	6.1.3  Local Repair

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

1828	   1.  Only an upstream change is indicated.  There is nothing that can
1829	       be done locally; GIMPS must propagate a notification to its
1830	       upstream peer.

1832	   2.  A downstream change has been detected and an upstream change
1833	       cannot be ruled out.  Although some local repair may be
1834	       appropriate, it is difficult to decide what, since the path
1835	       change may actually have taken place upstream of the detecting
1836	       node (so that this node is no longer on the path at all).

1838	   3.  A downstream change has been detected, but there is no upstream
1839	       change.  In this case, the detecting node is the true crossover
1840	       router, i.e.  the point in the network where old and new paths
1841	       diverge.  It is the correct node to initiate the local repair
1842	       process.

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

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

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

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

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

1870	   One possible technique to address this problem is that a GIMPS node
1871	   that detects case (3) locally, rather than initiating local repair
1872	   immediately, still sends a route change notification upstream, just
1873	   in case (2) actually applies.  If the upstream peer locally detects
1874	   no downstream route change, it can signal this to the downstream node
1875	   (e.g.  by setting another flag in the Common-Header of a GIMPS
1876	   message).  This acts to damp the possibility of a 'local repair
1877	   storm', at the cost of an additional peer-peer round trip time.

1879	6.1.4  Local Signaling Application State Removal

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

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

1902	6.1.5  Operation with Heterogeneous NSLPs

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

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

1922	6.2  Policy-Based Forwarding and Flow Wildcarding

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

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

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

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

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

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

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

1962	6.3  NAT Traversal

1964	   As already noted, GIMPS messages must carry packet addressing and
1965	   higher layer information as payload data in order to define the flow
1966	   signalled for.  (This applies to all GIMPS messages, regardless of
1967	   how they are encapsulated or which direction they are travelling in.)
1968	   At an addressing boundary the data flow packets will have their
1969	   headers translated; if the signaling payloads are not likewise
1970	   translated, the signaling messages will refer to incorrect (and
1971	   probably meaningless) flows after passing through the boundary.  In
1972	   addition, some GIMPS messages (those used in the discovery process)
1973	   carry addressing information about the GIMPS nodes themselves, and
1974	   this must also be processed appropriately when traversing a NAT.

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

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

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

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

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

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

2003	   6.  Forward the message with these new payloads.

2005	   The original Message-Routing-Information payload is retained in the
2006	   message, but encapsulated in the new TLV type.  Further information
2007	   can be added corresponding to the Node-Addressing payload, either the
2008	   original payload itself or, in the case of a GIMPS node that wished
2009	   to do topology hiding, opaque tokens (or it could be omitted
2010	   altogether).  In the case of a sequence of NATs, this part of the
2011	   NAT-Traversal object would become a list.  Note that a consequence of
2012	   this approach is that the routing state tables at the actual
2013	   signaling application peers (either side of the NAT) are no longer
2014	   directly compatible.  In particular, the values of
2015	   Message-Routing-Information are different, which is why the
2016	   unmodified MRI is propagated in the NAT-Traversal payload to allow
2017	   subsequent C-mode messages to be interpreted correctly..

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

2029	6.4  Interaction with IP Tunnelling

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

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

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

2063	6.5  IPv4-IPv6 Transition and Interworking

2065	   GIMPS itself is essentially IP version neutral (version dependencies
2066	   are isolated in the formats of the Message-Routing-Information and
2067	   Node-Addressing TLVs, and GIMPS also depends on the version
2068	   independence of the protocols that support messaging associations).
2069	   In mixed environments, GIMPS operation will be influenced by the IP
2070	   transition mechanisms in use.  This section provides a high level
2071	   overview of how GIMPS is affected, considering only the currently
2072	   predominant mechanisms.

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

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

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

2099	   Packet Translation: (Applicable to SIIT [5] and NAT-PT [12].) Some
2100	      transition mechanisms allow IPv4 and IPv6 nodes to communicate by
2101	      placing packet translators between them.  From the GIMPS
2102	      perspective, this should be treated essentially the same way as
2103	      any other NAT operation (e.g.  between 'public' and 'private'
2104	      addresses) as described in Section 6.3.  In other words, the
2105	      translating node needs to be GIMPS aware; it will run GIMPS with
2106	      IPv4 on some interfaces and with IPv6 on others, and will have to
2107	      translate the Message-Routing-Information payload between IPv4 and
2108	      IPv6 formats for flows which cross between the two.  The
2109	      translation rules for the fields in the payload (including e.g.
2110	      traffic class and flow label) are as defined in [5].

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

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

2132	7.  Security Considerations

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

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

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

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

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

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

2175	7.1  Message Confidentiality and Integrity

2177	   GIMPS can use messaging association functionality, such as TLS or
2178	   IPsec, to ensure message confidentiality and integrity.  In many
2179	   cases, confidentiality of GIMPS information itself is not likely to
2180	   be a prime concern, in particular since messages are often sent to
2181	   parties which are unknown ahead of time, although the content visible
2182	   even at the GIMPS level gives significant opportunities for traffic
2183	   analysis.  Signaling applications may have their own mechanism for
2184	   securing content as necessary; however, they may find it convenient
2185	   to rely on protection provided by messaging associations,
2186	   particularly if this is provided efficiently and if it runs unbroken
2187	   between signaling application peers.

2189	7.2  Peer Node Authentication

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

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

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

2220	7.3  Routing State Integrity

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

2227	   In the case where the message routing method is path-coupled
2228	   signaling, the messages need to be routed identically to the data
2229	   flow described by the Flow Identifier, and the routing state table is
2230	   the GIMPS view of how these flows are being routed through the
2231	   network in the immediate neighbourhood of the node.  Routes are only
2232	   weakly secured (e.g.  there is usually no cryptographic binding of a
2233	   flow to a route), and there is no other authoritative information
2234	   about flow routes than the current state of the network itself.
2235	   Therefore, consistency between GIMPS and network routing state has to
2236	   be ensured by directly interacting with the routing mechanisms to
2237	   ensure that the upstream and downstream signaling peers are the
2238	   appropriate ones for any given flow.  A good overview of security
2239	   issues and techniques in this sort of context is provided in [27].

2241	   Downstream peer identification is installed and refreshed only on
2242	   receiving a GIMPS-reponse message (compare Figure 4).  This must echo
2243	   the cookie from a previous GIMPS-query message, which will have been
2244	   sent downstream along the flow path (in datagram mode, i.e.
2245	   end-to-end addressed).  Hence, only the true next peer or an on-path
2246	   attacker will be able to generate such a message, provided freshness
2247	   of the cookie can be checked at the querying node.

2249	   Upstream peer identification can be installed directly on receiving a
2250	   GIMPS-query message containing addressing information for the
2251	   upstream peer.  However, any node in the network could generate such
2252	   a message (indeed, almost any node in the network could be the
2253	   genuine upstream peer for a given flow).  To protect against this,
2254	   two strategies are possible:

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

2267	   Authentication (weak or strong): the receiving node may refuse to
2268	      install upstream state until it has handshaked by some means with
2269	      the upstream peer.  This handshaking could be as simple as
2270	      requesting the upstream peer to echo the response cookie in the
2271	      discover-response payload of a GIMPS-response message (to
2272	      discourage nodes impersonating upstream peers from using forged
2273	      source addresses); or, it could be full peer authentication within
2274	      the messaging association, the reasoning being that an
2275	      authenticated peer can be trusted not to pretend that it is on
2276	      path when it is not.

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

2282	7.4  Denial of Service Prevention

2284	   GIMPS is designed so that each connectionless discovery message only
2285	   generates at most one response, so that a GIMPS node cannot become
2286	   the source of a denial of service amplification attack.

2288	   However, GIMPS can still be subjected to denial-of-service attacks
2289	   where an attacker using forged source addresses forces a node to
2290	   establish state without return routability, causing a problem similar
2291	   to TCP SYN flood attacks.  In addition to vulnerabilities of a next
2292	   peer discovery an unprotected path discovery procedure might
2293	   introduce more denial of service attacks since a number of nodes
2294	   could possibly be forced to allocate state.  Furthermore, an
2295	   adversary might modify or replay unprotected signaling messages.
2296	   There are two types of state attacks and one computational resource
2297	   attack.  In the first state attack, an attacker floods a node with
2298	   messages that the node has to store until it can determine the next
2299	   hop.  If the destination address is chosen so that there is no
2300	   GIMPS-capable next hop, the node would accumulate messages for
2301	   several seconds until the discovery retransmission attempt times out.
2302	   The second type of state-based attack causes GIMPS state to be
2303	   established by bogus messages.  A related
2304	   computational/network-resource attack uses unverified messages to
2305	   cause a node to make AAA queries or attempt to cryptographically
2306	   verify a digital signature.  (RSVP is vulnerable to this type of
2307	   attack.) Relying only on upper layer security, for example based on
2308	   CMS, might open a larger door for denial of service attacks since the
2309	   messages are often only one-shot-messages without utilizing multiple
2310	   roundtrips and DoS protection mechanisms.

2312	   There are at least three defenses against these attacks:

2314	   1.  The responding node does not establish a session or discover its
2315	       next hop on receiving the GIMPS-query message, but can wait for a
2316	       setup message on a reliable channel.  If the reliable channel
2317	       exists, the additional delay is a one one-way delay and the total
2318	       is no more than the minimal theoretically possible delay of a
2319	       three-way handshake, i.e., 1.5 node-to-node round-trip times.
2320	       The delay gets significantly larger if a new connection needs to
2321	       be established first.

2323	   2.  The response to the initial discovery message contains a cookie.

2325	       The previous hop repeats the discovery with the cookie included.
2326	       State is only established for messages that contain a valid
2327	       cookie.  The setup delay is also 1.5 round-trip times.  (This
2328	       mechanism is similar to that in SCTP [6] and other modern
2329	       protocols.)

2331	   3.  If there is a chance that the next-hop node shares a secret with
2332	       the previous hop, the sender could include a hash of the session
2333	       ID and the sender's secret.  The receiver can then verify that
2334	       the message was likely sent by the purported source.  This does
2335	       not scale well, but may work if most nodes tend to communicate
2336	       with a small peer clique of nodes.  (In that case, however, they
2337	       might as well establish more-or-less permanent transport sessions
2338	       with each other.)

2340	   These techniques are complementary; we chose a combination of the
2341	   first and second method.

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

2352	8.  IANA Considerations

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

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

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

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

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

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

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

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

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

2406	9.  Open Issues

2408	9.1  Protocol Naming

2410	   Alternate names:
2411	   GIST: General Internet Signaling Transport
2412	   GIMPS: General Internet Messaging Protocol for Signaling
2413	   LUMPS: Lightweight Universal Messaging for Path associated Signaling

2415	   There is a danger of some ambiguity as to whether the protocol name
2416	   refers to the complete transport stack below the signaling
2417	   applications, or only to the additional protocol functionality above
2418	   the standard transport protocols (UDP, TCP etc.) The NSIS framework
2419	   uses the term NTLP for the first, but this specification uses the
2420	   GIST/variants names for the second (see Figure 2 in Section 3.1).  In
2421	   other words, this specification proposes to meet the requirements for
2422	   NTLP functionality by layering GIMPS/...  over existing standard
2423	   transport protocols.  It isn't clear if additional terminological
2424	   surgery is needed to make this clearer.

2426	9.2  General IP Layer Issues

2428	   Some NSIS messages have to be addressed end-to-end but intercepted at
2429	   intermediate routers, and this imposes some special constraints on
2430	   how they can be encapsulated.  RSVPv1 [9] primarily uses raw IP with
2431	   a specific protocol number (46); a UDP encapsulation is also possible
2432	   for hosts unable to perform raw network i/o.  RSVP aggregation [15]
2433	   uses an additional protocol number (134) to bypass certain interior
2434	   nodes.

2436	   The critical requirements for the encapsulation at this level are
2437	   that routers should be able to identify signaling packets for
2438	   processing, and that they should not mis-identify packets for
2439	   'normal' end-to-end user data flows as signaling packets.  The
2440	   current assumption is that UDP encapsulation can be used for such
2441	   messages, by allocating appropriate (new) value codes for the router
2442	   alert option (RAO) [1][4] to identify NSIS messages.  Specific open
2443	   issues about how to allocate such values are discussed in Section
2444	   9.4.

2446	   An alternative approach would be to use raw IP with the RSVP protocol
2447	   numbers and a new RSVP version number.  Although this would provide
2448	   some more commonality with existing RSVP implementations, the NAT
2449	   traversal problems for such an encapsulation seem much harder to
2450	   solve.  Specifically, any unmodified NAT (which performed address
2451	   sharing) would be unable to process any such traffic since they need
2452	   to understand a higher-layer field (such as TCP or UDP port) to use
2453	   as a demultiplexer.

2455	9.3  Encapsulation and Addressing for Datagram Mode

2457	   The discussion in Section 4 essentially assumes that datagram mode
2458	   messages are UDP encapsulated.  This leaves open the question of
2459	   whether other encapsulations are possible, and exactly how these
2460	   messages should be addressed.

2462	   As well as UDP/IP (and raw IP as discussed and temporarily ruled out
2463	   in Section 9.2), DCCP/IP and UDP/IPsec could also be considered as
2464	   'datagram' encapsulations.  However, they still require explicit
2465	   addressing between GIMPS peer nodes and some per-peer state to be set
2466	   up and maintained.  Therefore, it seems more appropriate to consider
2467	   these encapsulation options as possible messaging association types,
2468	   for use where there is a need for congestion control or security
2469	   protection but without reliability.  This would leave UDP/IP as the
2470	   single encapsulation allowed for all datagram mode messages.

2472	   Addressing for upstream datagram mode messages is simple: the IP
2473	   source address is the signaling source address, and the IP
2474	   destination address is the signaling destination address (compare
2475	   Figure 1).  For downstream datagram mode messages, the IP destination
2476	   address will be the flow destination address, but the IP source
2477	   address could be either of the flow source address or signaling
2478	   source address.  Some of the relative merits of these options are as
2479	   follows:

2481	   o  Using the flow source address makes it more likely that the
2482	      message will be correctly routed through any intermediate
2483	      NSIS-unaware region which is doing load sharing or policy routing
2484	      on the {source, destination} address pair.  If the signaling
2485	      source address is used, the message will be intercepted at some
2486	      node closer to the flow destination, but it may not be the same as
2487	      the next node for the data flow packets.

2489	   o  Conversely, using the signaling source address means that ICMP
2490	      error messages (specifically, unreachable port or address) will be
2491	      correctly delivered to the message originator, rather than being
2492	      sent back to the flow source.  Without seeing these messages, it
2493	      is very difficult for the querying node to recognise that it is
2494	      the last NSIS node on the path.  In addition, using the signaling
2495	      source address may make it possible to exchange messages through
2496	      GIMPS unaware NATs (although it isn't clear how useful the
2497	      resulting messages will be, see Section 6.3).

2499	   It is not clear which of these situations it is more important to
2500	   handle correctly and hence which source addressing option to use.
2501	   (RSVP uses the flow source address, although this is primarily for
2502	   multicast routing reasons.) A conservative approach would be to allow
2503	   both, possibly even in parallel (although this might open up the
2504	   protocol to amplification attacks).

2506	9.4  Intermediate Node Bypass and Router Alert Values

2508	   We assume that the primary mechanism for intercepting messages is the
2509	   use of the RAO.  The RAO contains a 16 bit value field, within which
2510	   35 values have currently been assigned by IANA.  It is open how to
2511	   assign values for use by GIMPS messages to optimise protocol
2512	   processing, i.e.  to minimise the amount of slow-path processing that
2513	   nodes have to carry out for messages they are not actually interested
2514	   in the content of.

2516	   There are two basic reasons why a GIMPS node might wish to ignore a
2517	   message:

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

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

2527	   Conversely, note that a node might wish to process a number of
2528	   different signaling applications, either because it was genuinely
2529	   multifunctional or because it processed several versions of the same
2530	   application.  (Note from Appendix C.1 that different versions are
2531	   distinguished by different NSLP identifiers.)

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

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

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

2553	   These considerations imply that the RAO value should not be tied
2554	   directly to the NSLP id, but should be selected for the application
2555	   on broader considerations of likely deployment scenarios.  Note that
2556	   the exact NSLP is given in the GIMPS common header, and some
2557	   implementations may still be able to process it on the fast path.
2558	   The semantics of the node dropping out of the signaling path are the
2559	   same however the filtering is done.

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

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

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

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

2584	9.5  IP TTL Management

2586	   The GIMPS API contains a primitive to allow GIMPS to report what is
2587	   equivalent to the number of IP hops between the receiving node and
2588	   the GIMPS peer that sent a signaling message (see Appendix D.2).
2589	   This could be required to emulate RSVP-like functionality in support
2590	   of IntServ where the existence of non-IntServ capable hops needs to
2591	   be discovered.  However, the GIMPS protocol itself does not currently
2592	   contain functionality to support this aspect of the API.

2594	   The protocol functionality required for this is logically quite
2595	   simple: a sending node inserts the IP TTL used in the GIMPS message,
2596	   and the reciever compares this with the IP TTL in the received
2597	   signaling message.  A value > 1 indicates a non-GIMPS node between.
2598	   However, there are some subtleties to make it possible to report this
2599	   consistently to signaling applications:

2601	   o  The basic approach only provides a meaningful answer for
2602	      downstream query messages.  For upstream messages, because of
2603	      asymmetric routing, it would be necessary for the sending node to
2604	      insert the 'non-GIMPS-capable hop count' value it has learned
2605	      directly in the message, which would be used directly at the
2606	      receiver without comparing with the received TTL at the IP layer.

2608	   o  It is not usually possible to extract IP layer TTL information for
2609	      data arriving over transport protocols such as TCP, and strictly
2610	      it is not meaningful to do so.  Therefore, rather than reporting a
2611	      fresh value for every message, the incapable hop count would have
2612	      to be calculated by GIMPS on query/response exchanges and then
2613	      stored in the routing state table so it can be reported to
2614	      signaling applications for each message regardless of which mode
2615	      was actually used for that message.

2617	   It needs to be evaluated whether this degree of protocol and
2618	   implementation complexity is justified by the value of the
2619	   information obtained.

2621	9.6  GIMPS Support for Message Scoping

2623	   Many signaling applications are interested in sending messages over a
2624	   specific region of the network.  Message scoping of this nature seems
2625	   to be hard to achieve in a topologically robust way, because such
2626	   region boundaries are not well defined in the network layer.

2628	   It may be that the GIMPS layer can assist such scoping, by detecting
2629	   and counting different types of nodes in the signaling plane.  The
2630	   simplest solution would be to count GIMPS nodes supporting the
2631	   relevant signaling application - this is already effectively done by
2632	   the GIMPS hop count.  A more sophisticated approach would be to track
2633	   the crossing of aggregation region boundaries, as introduced in
2634	   Section 9.4.  Whether this is plausible depends on the willingness of
2635	   operators to configure such boundary information in their routers.

2637	9.7  Additional Discovery Mechanisms

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

2644	   As well as the GIMPS-query/response discovery mechanism, other
2645	   techniques may sometimes also be possible.  For example, in many
2646	   environments, a host has a single access router, i.e.  the downstream
2647	   peer (for outgoing flows) and the upstream peer (for incoming ones)
2648	   are known a priori.  More generally, a link state routing protocol
2649	   database can be analysed to determine downstream peers in more
2650	   complex topologies, and maybe upstream ones if strict ingress
2651	   filtering is in effect.  More radically, much of the GIMPS protocol
2652	   is unchanged if we consider off-path signaling nodes, although there
2653	   are significant differences in some of the security analysis (Section
2654	   7.3).  However, none of these possibilities are considered further in
2655	   this specification.

2657	9.8  Alternative Message Routing Requirements

2659	   The initial assumption of GIMPS is that signaling messages are to be
2660	   routed identically to data flow messages.  For this case of
2661	   path-coupled signaling, the MRI and upstream/downstream flag (in the
2662	   Common-Header) define the flow and the relationship of the signaling
2663	   to it sufficiently for GIMPS to route its messages correctly.
2664	   However, some additional modes of routing signaling messages have
2665	   been identified:

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

2676	   NAT Address Reservations: This applies to the case where a node
2677	      behind a NAT wishes to use NSIS signaling to reserve an address
2678	      from which it can be reached by a sender on the other side.  This
2679	      requires a message to be sent outbound from what will be the flow
2680	      receiver although no reverse routing state exists.  One possible
2681	      solution (assumed in [22]) is to construct a message with the
2682	      Flow-Routing-Information matching the possible senders and send it
2683	      as though it was downstream signaling.  It is not clear whether
2684	      signaling for the 'wrong direction' in this way will always be
2685	      treated consistently by GIMPS, especially if routing policies and
2686	      encapsulations for inbound and outbound traffic are treated very
2687	      differently within the rest of the network.

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

2695	   o  Defining the format of the MRI for the new message routing method
2696	      type.

2698	   o  Defining how D-mode messages should be encapsulated and routed
2699	      corresponding to this MRI.

2701	   o  Defining any filtering or other security mechanisms that should be
2702	      used to validate the MRI in a D-mode message.

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

2706	9.9  Message Format Issues

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

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

2718	   NSLP Versioning: The current working assumption is that if an NSLP
2719	      for a particular signaling application is changed so radically
2720	      that it is no longer backwards compatible, an entirely new NSLPID
2721	      will be allocated.  However, this leads to a problem when a node
2722	      supporting both variants needs to discover its downstream peer.
2723	      If it probes for the 'early' NSLPID it will not detect the case
2724	      where the downstream peer supports the later one; if it probes for
2725	      the 'later' NSLPID, a downstream peer supporting only the early
2726	      variant will bypass the message altogether.  The implication is
2727	      that a single NSLPID should be used even in this case, with
2728	      demultiplexing based on a separate version number (which could be
2729	      carried in the common header, or within the NSLP payload).

2731	9.10  Inter-Layer Security Coordination

2733	   GIMPS is able to provide channel security protection between adjacent
2734	   signaling application peers, and it is efficient if signaling
2735	   applications themselves can rely on this protection for their
2736	   messages.  Ideally, to enable a consistent security analysis of the
2737	   signaling application, the properties and mode of use of the
2738	   underlying security protocol would be analysed jointly with signaling
2739	   application itself; however, for layering reasons, the operation of
2740	   the security protocol itself must be largely hidden below the GIMPS
2741	   layer.

2743	   This presents a challenge, mainly for the GIMPS service interface
2744	   specification (Section 4.1), which ideally would be able to expose
2745	   the relevant properties of the security protocol in use to the
2746	   signaling application depending on it, including allowing the
2747	   application to take part in the protocol operation (e.g.  selecting
2748	   which identity to use and verifying the identity of the peer).
2749	   Currently, the description is limited to the identification of a
2750	   transfer attribute called 'Security' in Section 4.1.2; more detailed
2751	   design may require this attribute to be an object with non-trivial
2752	   processing capabilities, rather than simply an enumerated value.
2753	   Details are for further study.

2755	9.11  Protocol Design Details

2757	   Clearly, not all details of GIMPS operation have been defined so far.
2758	   This section provides a list of slightly non-trivial areas where more
2759	   detail is need, where these have not been mentioned elsewhere in the
2760	   text.

2762	   o  Receiver initiated signaling applications need to have reverse
2763	      path state set up in the network, before the signaling application
2764	      itself can originate any messages.  Should this be done by GIMPS
2765	      carrying out the discovery for the specific signaling application
2766	      (which requires the flow sender to know what signaling
2767	      applications are going to be used), or should the discovery
2768	      attempt to find every GIMPS node and the signaling applications
2769	      they support?

2771	   o  How should GIMPS handle a lost GIMPS-confirm? The naive approach
2772	      of requiring retransmission of the GIMPS-response that requested
2773	      it would impose a processing and state maintenance burden on the
2774	      responding node at an early stage of the message exchange, which
2775	      could lead to denial of service problems and also an amplification
2776	      attack where a query is sent from a forged address.  Note that the
2777	      problem only arises in the case where no reliable messaging
2778	      association is being set up; otherwise, GIMPS-confirm is delivered
2779	      reliably in C-mode.

2781	   o  The GIMPS API for sending a message (Appendix D.1) allows a
2782	      signaling application to generate a message as though it came from
2783	      a previous node along the path from which an incoming message was
2784	      received, by providing a value for the Source-SII-Handle
2785	      parameter.  Reasons for doing this might be to allow the node to
2786	      process the message without handling path state, or to allow it to
2787	      drop out of the messaging chain based on the content of NSLP-Data.
2788	      A simpler way of modelling such processing would be to modify
2789	      RecvMessage so as to allow an NSLP to request that a message be
2790	      forwarded (possibly with a modified payload) rather than accepting
2791	      it for local processing.  However, while this is relatively easy
2792	      to handle for messages that arrive in D-mode, it would violate the
2793	      defined protocol behaviour for messages arriving in C-mode, where
2794	      the transfer attributes set by the original sender could no longer
2795	      be guaranteed.

2797	   o  Where messaging association protocol negotation (Section 5.5)
2798	      involves stacking protocols without a built-in unambiguous service
2799	      demultiplexing capability, it isn't clear how to handle cases such
2800	      as TCP vs.  TCP/TLS.  Multiple higher-layer-addressing fields in
2801	      the Node-Addressing object for different TCP configurations would
2802	      lead to a more complicated message format; defining a new
2803	      Protocol-Identifier for the TCP/TLS combination (with its own port
2804	      number) would lead to a large number of protocol configurations;
2805	      requiring the responding node to identify upper layers based on
2806	      the received TCP data would require a careful case by case
2807	      analysis.

2809	10.  Change History

2811	10.1  Changes In Version -04

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

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

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

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

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

2844	   5.  Added an outline for the future content of an IANA considerations
2845	        section (Section 8).  Currently, this is restricted to
2846	        identifying the registries and allocations required, without
2847	        defining the allocation policies and other considerations
2848	        involved.

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

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

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

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

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

2871	10.2  Changes In Version -03

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

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

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

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

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

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

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

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

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

2909	   9.  Expanded the open issue discussion in Section 9.9 to include an
2910	       outline set of extensibility flags.

2912	10.3  Changes In Version -02

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

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

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

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

2933	   4.  Extended Appendix C with a general discussion of rules for
2934	        message and object formats across GIMPS and other NSLPs.  Some
2935	        remaining open issues are noted in Section 9.9.

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

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

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

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

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

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

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

2971	10.4  Changes In Version -01

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

2986	   The full set of changes is as follows:

2988	   1.  Added a worked example in Section 3.2.

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

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

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

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

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

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

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

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

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

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

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

3041	   13.  Removed old open issues on Connection Mode Encapsulation
3042	        (section 8.7); added new open issues on Message Routing (Section
3043	        9.8) and Datagram Mode congestion control.

3045	   14.  Added this change history.

3047	11.  References

3049	11.1  Normative References

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

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

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

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

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

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

3069	   [7]  Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
3070	        draft-ietf-dccp-spec-07 (work in progress), July 2004.

3072	   [8]  Conta, A. and S. Deering, "Internet Control Message Protocol
3073	        (ICMPv6)for the Internet Protocol Version  6 (IPv6)
3074	        Specification", draft-ietf-ipngwg-icmp-v3-05 (work in progress),
3075	        October 2004.

3077	11.2  Informative References

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

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

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

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

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

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

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

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

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

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

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

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

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

3124	   [22]  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
3125	         (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July
3126	         2004.

3128	   [23]  Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
3129	         Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04
3130	         (work in progress), July 2004.

3132	   [24]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
3133	         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 (work in
3134	         progress), September 2004.

3136	   [25]  Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
3137	         draft-ietf-secsh-architecture-16 (work in progress), June 2004.

3139	   [26]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00
3140	         (work in progress), June 2004.

3142	   [27]  Nikander, P., "Mobile IP version 6 Route Optimization Security
3143	         Design Background", draft-ietf-mip6-ro-sec-02 (work in
3144	         progress), October 2004.

3146	   [28]  Bound, J., "Dual Stack Transition Mechanism",
3147	         draft-bound-dstm-exp-01 (work in progress), April 2004.

3149	Authors' Addresses

3151	   Henning Schulzrinne
3152	   Columbia University
3153	   Department of Computer Science
3154	   450 Computer Science Building
3155	   New York, NY  10027
3156	   US

3158	   Phone: +1 212 939 7042
3159	   EMail: hgs+nsis@cs.columbia.edu
3160	   URI:   http://www.cs.columbia.edu

3162	   Robert Hancock
3163	   Siemens/Roke Manor Research
3164	   Old Salisbury Lane
3165	   Romsey, Hampshire  SO51 0ZN
3166	   UK

3168	   EMail: robert.hancock@roke.co.uk
3169	   URI:   http://www.roke.co.uk

3171	Appendix A.  Acknowledgements

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

3188	Appendix B.  Example Message Routing State Table

3190	   Figure 7 shows a signaling scenario for a single flow being managed
3191	   by two signaling applications.  The flow sender and receiver and one
3192	   router support both, two other routers support one each.

3194	       A                        B          C          D           E
3195	   +------+                  +-----+    +-----+    +-----+    +--------+
3196	   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
3197	   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
3198	   |      |    +-+    +-+    |GIMPS|    |GIMPS|    |GIMPS|    |        |
3199	   +------+                  +-----+    +-----+    +-----+    +--------+

3201	                     ------------------------------>>
3202	                              Flow Direction

3204	                     Figure 7: A Signaling Scenario

3206	   Routing state table at node B for the flow from A to E:

3208	   +--------------------+----------+----------+----------+-------------+
3209	   |   Message Routing  |  Session |  NSLP ID | Upstream |  Downstream |
3210	   |     Information    |    ID    |          |   Peer   |     Peer    |
3211	   +--------------------+----------+----------+----------+-------------+
3212	   |    Method = Path   |  0xABCD  |   NSLP1  |   IP-#A  |    (null)   |
3213	   | Coupled; Flow ID = |          |          |          |             |
3214	   |   {IP-#A, IP-#E,   |          |          |          |             |
3215	   |  protocol, ports}  |          |          |          |             |
3216	   |                    |          |          |          |             |
3217	   |    Method = Path   |  0x1234  |   NSLP2  |   IP-#A  |  Pointer to |
3218	   | Coupled; Flow ID = |          |          |          |     B-D     |
3219	   |   {IP-#A, IP-#E,   |          |          |          |  messaging  |
3220	   |  protocol, ports}  |          |          |          | association |
3221	   +--------------------+----------+----------+----------+-------------+

3223	   The upstream state is just the same address for each application.
3224	   For the downstream case, NSLP1 only requires datagram mode messages
3225	   and so no explicit routing state towards C is needed.  NSLP2 requires
3226	   a messaging association for its messages towards node D, and node C
3227	   does not process NSLP2 at all, so the downstream peer state for NSLP2
3228	   is a pointer to a messaging association that runs directly from B to
3229	   D.  Note that E is not visible in the state table (except implicitly
3230	   in the address in the message routing information); routing state is
3231	   stored only for adjacent peers.

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

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	   |   Signalling Application ID   |D|         Reserved            |
3313	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3315	   Message length = the total number of words in the message after
3316	                    the common header itself
3317	   The flag is:
3318	   D - Direction (Set for "Upstream", Unset for "Downstream")

3320	C.3  General Object Characteristics

3322	C.3.1  TLV Header

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

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

3334	C.3.2  Object Extensibility

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

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

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

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

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

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

3364	C.4  GIMPS Specific TLV Objects

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

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

3373	C.4.1  Message-Routing-Information

3375	   Type: Message-Routing-Information

3377	   Length: Variable (depends on message routing method)

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

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

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

3404	   The flags are:
3405	   P - Protocol
3406	   T - Traffic Class
3407	   F - Flow Label
3408	   I - SPI
3409	   S - Source Port
3410	   D - Destination Port
3411	   I/S/D can only be set if P is set.

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

3420	C.4.2  Session Identification

3422	   Type: Session-Identification

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

3426	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3427	   |                                                               |
3428	   +                                                               +
3429	   |                                                               |
3430	   +                          Session ID                           +
3431	   |                                                               |
3432	   +                                                               +
3433	   |                                                               |
3434	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3436	C.4.3  Node Addressing

3438	   Type: Node-Addressing

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

3443	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3444	   | PI-Length     | HL-Count      |IP-Ver |    Reserved           |
3445	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3446	   //                       Peer Identity                         //
3447	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3448	   //                     Interface Address                       //
3449	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3450	   //                Higher-Layer-Information 1                   //
3451	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3452	   :                                                               :
3453	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3454	   //                Higher-Layer-Information N                   //
3455	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3457	   PI-Length = the byte length of the Peer-Identity field
3458	               (note that the Peer-Identity field itself is padded
3459	               to a whole number of words)
3460	   HL-Count  = the number of higher-layer-information fields
3461	               (these contain their own length information)
3462	   IP-Ver    = the IP version for the Interface-Address field

3464	   The higher layer information fields are formatted as follows:

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

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

3471	   o  There is a variable length of configuration data.

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

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

3479	C.4.4  Stack Proposal

3481	   Type: Stack-Proposal

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

3486	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3487	   |  Prof-Count   |     Reserved                                  |
3488	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3489	   //                    Profile 1                                //
3490	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3491	   :                                                               :
3492	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3493	   //                    Profile 2                                //
3494	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

3509	C.4.5  Query Cookie
3510	   Type: Query-Cookie

3512	   Length: Variable (selected by querying node)

3514	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3515	   |                                                               |
3516	   //                        Query Cookie                         //
3517	   |                                                               |
3518	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3520	   Note that the querying node uses the value of the query cookie in the
3521	   GIMPS-response message on an existing messaging association to match
3522	   with the corresponding GIMPS-query.  This imposes certain uniqueness
3523	   requirements on the cookie contents.

3525	C.4.6  Responder Cookie

3527	   Type: Responder-Cookie

3529	   Length: Variable (selected by responding node)

3531	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3532	   |                                                               |
3533	   //                      Responder Cookie                       //
3534	   |                                                               |
3535	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3542	C.4.7  Lifetime

3544	   Type: Lifetime

3546	   Length: Fixed - 1 32-bit word

3548	   Value: Routing state lifetime in seconds

3550	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3551	   |                           Lifetime                            |
3552	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3554	C.4.8  NAT Traversal

3556	   Type: NAT-Traversal

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

3560	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3561	   | MRI-Length    | Type-Count    | NAT-Count    |  Reserved      |
3562	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3563	   //            Original Message-Routing-Information             //
3564	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3565	   //                 List of translated objects                  //
3566	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3567	   | Length of opaque NAO info.    |                               |
3568	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3569	   //            NAO information replaced by NAT #1                |
3570	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3571	   :                                                               :
3572	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3573	   | Length of opaque NAO info.    |                               |
3574	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3575	   //            NAO information replaced by NAT #N                |
3576	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3586	C.4.9  NSLP Data

3588	   Type: NSLP-Data

3590	   Length: Variable (depends on NSLP)

3592	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3593	   |                                                               |
3594	   //                          NSLP Data                          //
3595	   |                                                               |
3596	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3598	C.5  Generic NSIS TLV Objects

3600	   The objects defined in this section are general purpose objects,
3601	   which will be used by both GIMPS and signaling applications in
3602	   general.

3604	C.5.1  Error Object

3606	   Type: Error

3608	   Length: Variable (depends on error)

3610	   Value: Contains a 1 byte error class and 3 byte error code, an error
3611	      source identifier and optionally variable length error-specific
3612	      information.

3614	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3615	   |   Error Class |                   Error Code                  |
3616	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3617	   |   ESI-Length  |                    Reserved                   |
3618	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3619	   //                   Error Source Identifier                   //
3620	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3621	   //             Optional error-specific information             //
3622	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

3644	   Additional error class values are reserved.

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

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

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

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

3666	Appendix D.  API between GIMPS and NSLP

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

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

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

3688	D.1  SendMessage

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

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

3698	   The following arguments are mandatory.

3700	   NSLP-Data: The NSLP message itself.

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

3704	   NSLP-Message-Handle: A handle for this message, that can be used
3705	      later by GIMPS to reference it in error messages, etc.  A NULL
3706	      handle may be supplied if the NSLP is not interested in receiving
3707	      MessageDeliveryError notifications for this message.

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

3711	   Session-ID: The NSIS session identifier.  Note that it is assumed
3712	      that the signaling application provides this to GIMPS rather than
3713	      GIMPS providing a value itself; often, this will be a value
3714	      associated with an existing session, for example received in an
3715	      incoming message.  In the case of an entirely new session, a GIMPS
3716	      implementation might provide library functionality to generate a
3717	      new, cryptographically random SID which is guaranteed not to
3718	      collide with any existing session.

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

3726	   Direction: A flag indicating whether the message is to be sent in the
3727	      upstream or downstream direction (in relation to the MRI).

3729	   The following arguments are optional.

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

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

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

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

3749	      Security: Values for further refinement.

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

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

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

3763	D.2  RecvMessage

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

3770	   RecvMessage ( NSLP-Data, NSLP-Data-Size,
3771	                 NSLP-Id, Session-ID, MRI, Direction,
3772	                 SII-Handle, Transfer-Attributes, IP-TTL, Original-TTL )

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

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

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

3780	   Session-ID: The NSIS session identifier.

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

3788	   Direction: A flag indicating whether the message was received going
3789	      in the upstream or downstream direction (in relation to the MRI).

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

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

3798	   IP-TTL: The value of the IP TTL (or Hop Limit) associated with this
3799	      message.

3801	   Original-TTL: The value of the IP TTL (or Hop Limit) at the time of
3802	      sending of the packet that contained this message.

3804	D.3  MessageDeliveryError

3806	   This primitive is passed from GIMPS to an NSLP.  It is used to notify
3807	   the NSLP that a message that it requested to be sent has failed to be
3808	   dispatched.

3810	   MessageDeliveryError ( NSLP-Message-Handle, Error-Type )

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

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

3818	D.4  NetworkNotification

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

3823	   NetworkNotification ( MRI, Network-Notification-Type )

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

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

3832	D.5  SecurityProtocolAttributesRequest

3834	   This primitive is passed from GIMPS to an NSLP.  It is sent when
3835	   GIMPS requires the NSLP to make decisions (e.g.  check policy) or
3836	   provide information for authentication parameters to be used when
3837	   setting up a messaging association.

3839	   SecurityProtocolAttributesRequest ( Peer-Info,
3840	                                       Security-Protocol,
3841	                                       Request-Type )

3843	   Peer-Info: Information identifying the GIMPS peer and interface

3845	   Security-Protocol: A value indicating the security protocol being
3846	      used (TLS, IPsec, etc).

3848	   Request-Type: An indication of the type of information required (e.g.
3849	      client certificate)

3851	D.6  SetStateLifetime

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

3858	   SetStateLifetime ( MRI, Direction, State-Lifetime )

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

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

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

3870	D.7  InvalidateRoutingState

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

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

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

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

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

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

3892	Intellectual Property Statement

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

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

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

3916	Disclaimer of Validity

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

3926	Copyright Statement

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

3932	Acknowledgment

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