idnits 2.17.1 

draft-ietf-nsis-ntlp-02.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 3667, Section 5.1 on line 16.

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

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

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

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

  ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
     3238), which is fine, but *also* found old RFC 2026, Section 10.4C,
     paragraph 1 text on line 38.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

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

        By submitting this Internet-Draft, I certify that any applicable patent
        or other IPR claims of which I am aware have been disclosed, or
        will be disclosed, and any of which I become aware will be
        disclosed, in accordance with RFC 3668.


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

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

  == The page length should not exceed 58 lines per page, but there was 71
     longer pages, the longest (page 61) being 73 lines

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 76 pages


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

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 2 instances of too long lines in the document, the longest one
     being 11 characters in excess of 72.


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

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

  == Line 701 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 (May 30, 2004) is 7270 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 218

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

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

  == Unused Reference: '19' is defined on line 2685, 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-06

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

  -- Obsolete informational reference (is this intentional?): RFC 2463 (ref.
     '11') (Obsoleted by RFC 4443)

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

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

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

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

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

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

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

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

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


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

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

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


2	Next Steps in Signaling                                   H. Schulzrinne
3	Internet-Draft                                               Columbia U.
4	Expires: November 28, 2004                                    R. Hancock
5	                                                             Siemens/RMR
6	                                                            May 30, 2004

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

11	Status of this Memo

13	   By submitting this Internet-Draft, I certify that any applicable
14	   patent or other IPR claims of which I am aware have been disclosed,
15	   and any of which I become aware will be disclosed, in accordance with
16	   RFC 3668.

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

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

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

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

34	   This Internet-Draft will expire on November 28, 2004.

36	Copyright Notice

38	   Copyright (C) The Internet Society (2004).  All Rights Reserved.

40	Abstract

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

55	Table of Contents

57	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
58	     1.1  Restrictions on Scope  . . . . . . . . . . . . . . . . . .   5
59	   2.   Requirements Notation and Terminology  . . . . . . . . . . .   6
60	   3.   Design Methodology . . . . . . . . . . . . . . . . . . . . .   8
61	     3.1  Overall Approach . . . . . . . . . . . . . . . . . . . . .   8
62	     3.2  Design Attributes  . . . . . . . . . . . . . . . . . . . .  10
63	     3.3  Example of Operation . . . . . . . . . . . . . . . . . . .  12
64	   4.   GIMPS Processing Overview  . . . . . . . . . . . . . . . . .  15
65	     4.1  GIMPS State  . . . . . . . . . . . . . . . . . . . . . . .  15
66	     4.2  Basic Message Processing . . . . . . . . . . . . . . . . .  17
67	     4.3  Routing State and Messaging Association Maintenance  . . .  21
68	   5.   Message Formats and Encapsulations . . . . . . . . . . . . .  25
69	     5.1  GIMPS Messages . . . . . . . . . . . . . . . . . . . . . .  25
70	     5.2  Information Elements . . . . . . . . . . . . . . . . . . .  26
71	     5.3  Encapsulation in Datagram Mode . . . . . . . . . . . . . .  29
72	     5.4  Encapsulation in Connection Mode . . . . . . . . . . . . .  29
73	   6.   Advanced Protocol Features . . . . . . . . . . . . . . . . .  32
74	     6.1  Route Changes and Local Repair . . . . . . . . . . . . . .  32
75	     6.2  Policy-Based Forwarding and Flow Wildcarding . . . . . . .  38
76	     6.3  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  38
77	     6.4  Interaction with IP Tunnelling . . . . . . . . . . . . . .  40
78	     6.5  IPv4-IPv6 Transition and Interworking  . . . . . . . . . .  40
79	     6.6  Messaging Association Protocol Negotiation . . . . . . . .  42
80	   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  44
81	     7.1  Message Confidentiality and Integrity  . . . . . . . . . .  44
82	     7.2  Peer Node Authentication . . . . . . . . . . . . . . . . .  45
83	     7.3  Routing State Integrity  . . . . . . . . . . . . . . . . .  45
84	     7.4  Denial of Service Prevention . . . . . . . . . . . . . . .  47
85	   8.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  49
86	     8.1  Protocol Naming  . . . . . . . . . . . . . . . . . . . . .  49
87	     8.2  General IP Layer Issues  . . . . . . . . . . . . . . . . .  49
88	     8.3  Encapsulation and Addressing for Datagram Mode . . . . . .  50
89	     8.4  Intermediate Node Bypass and Router Alert Values . . . . .  51
90	     8.5  Messaging Association Flexibility  . . . . . . . . . . . .  52
91	     8.6  Messaging Association Setup Message Sequences  . . . . . .  53
92	     8.7  GIMPS Support for Message Scoping  . . . . . . . . . . . .  54
93	     8.8  Additional Discovery Mechanisms  . . . . . . . . . . . . .  54
94	     8.9  Alternative Message Routing Requirements . . . . . . . . .  55
95	     8.10   Congestion Control in Datagram Mode  . . . . . . . . . .  56
96	     8.11   Message Format Issues  . . . . . . . . . . . . . . . . .  56
97	     8.12   Protocol Design Details  . . . . . . . . . . . . . . . .  57

99	   9.   Change History . . . . . . . . . . . . . . . . . . . . . . .  58
100	     9.1  Changes In Version -02 . . . . . . . . . . . . . . . . . .  58
101	     9.2  Changes In Version -01 . . . . . . . . . . . . . . . . . .  59
102	   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  61
103	   10.1   Normative References . . . . . . . . . . . . . . . . . . .  61
104	   10.2   Informative References . . . . . . . . . . . . . . . . . .  61
105	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  63
106	   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  64
107	   B.   Example Message Routing State Table  . . . . . . . . . . . .  65
108	   C.   Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . .  66
109	     C.1  General NSIS Formatting Guidelines . . . . . . . . . . . .  66
110	     C.2  The GIMPS Common Header  . . . . . . . . . . . . . . . . .  67
111	     C.3  GIMPS TLV Objects  . . . . . . . . . . . . . . . . . . . .  67
112	   D.   API between GIMPS and NSLP . . . . . . . . . . . . . . . . .  71
113	     D.1  SendMessage  . . . . . . . . . . . . . . . . . . . . . . .  71
114	     D.2  RecvMessage  . . . . . . . . . . . . . . . . . . . . . . .  72
115	     D.3  MessageReceived  . . . . . . . . . . . . . . . . . . . . .  73
116	     D.4  MessageDeliveryError . . . . . . . . . . . . . . . . . . .  73
117	     D.5  NetworkNotification  . . . . . . . . . . . . . . . . . . .  74
118	     D.6  SecurityProtocolAttributesRequest  . . . . . . . . . . . .  74
119	     D.7  SetStateLifetime . . . . . . . . . . . . . . . . . . . . .  74
120	        Intellectual Property and Copyright Statements . . . . . . .  76

122	1.  Introduction

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

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

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

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

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

170	1.1  Restrictions on Scope

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

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

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

188	2.  Requirements Notation and Terminology

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

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

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

213	                  >>>>>>>>>>>>>>>>>  =  Downstream direction
214	                  <<<<<<<<<<<<<<<<<  =  Upstream direction

216	                      Figure 1: Basic Terminology

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

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

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

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

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

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

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

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

249	   Datagram mode: A mode of sending GIMPS messages between nodes without
250	      using any transport layer state or security protection.  Upstream
251	      messages are sent UDP encapsulated directly to the signaling
252	      destination; downstream messages are sent towards the flow
253	      receiver with a router alert option.

255	   Connection mode: A mode of sending GIMPS messages directly between
256	      nodes using point to point "messaging associations" (see below),
257	      i.e.  transport protocols and security associations.

259	   Messaging association: A single connection between two explicitly
260	      identified GIMPS adjacent peers, i.e.  between a given signaling
261	      source and destination address.  A messaging association uses a
262	      specific transport protocol and known ports, and may be run over
263	      specific network layer security associations, or use a transport
264	      layer security association internally.  A messaging association is
265	      bidirectional.

267	3.  Design Methodology

269	3.1  Overall Approach

271	   The generic requirements identified in [22] for transport of
272	   path-coupled signaling messages are essentially two-fold:

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

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

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

286	   Once the routing decision has been made, the node has to select a
287	   mechanism for transport of the message to the peer.  GIMPS divides
288	   the transport problems into two categories, the easy and the
289	   difficult ones.  It handles the easy cases within GIMPS itself,
290	   avoiding complexity and latency, while drawing on the services of
291	   well-understood reliable transport protocols for the harder cases.
292	   Here, with details discussed later, "easy" messages are those that
293	   are sized well below the lowest MTU along a path, are infrequent
294	   enough not to cause concerns about congestion and flow control, and
295	   do not need transport or network-layer security protection.

297	   However, in many cases, signaling information needs to be delivered
298	   between GIMPS peers with additional transport or security properties.
299	   For example, signaling applications could implement their own
300	   reliability mechanism, but experience with RSVP has shown [14] that
301	   relying solely on soft-state refreshes may yield unsatisfactory
302	   performance if signaling messages are lost even occasionally.  The
303	   provision of this type of reliability is therefore also the
304	   responsibility of the underlying transport protocols.

306	   In [22] all of these routing and transport requirements are assigned
307	   to a single notional protocol, the 'NSIS Transport Layer Protocol'
308	   (NTLP).  The strategy of splitting the transport problem leads to a
309	   layered structure for the NTLP, as a specialised GIMPS 'messaging'
310	   layer running over standard transport and security protocols, as
311	   shown in Figure 2.

313	   GIMPS offers two modes of transport operation:

315	   Datagram mode: for small, infrequent messages with modest delay
316	      constraints; and

318	   Connection mode: for larger data objects or where fast setup in the
319	      face of packet loss is desirable, or where channel security is
320	      required.

322	          ^^                       +-------------+
323	          ||                       |  Signaling  |
324	          ||          +------------|Application 2|
325	          ||          |  Signaling +-------------+
326	         NSIS         |Application 1|         |
327	       Signaling      +-------------+         |
328	      Application         |   +-------------+ |
329	         Level            |   |  Signaling  | |
330	          ||              |   |Application 3| |
331	          ||              |   +-------------+ |
332	          VV              |          |        |
333	   =======================|==========|========|======================
334	          ^^        +------------------------------------------------+
335	          ||        |+-----------------------+      +--------------+ |
336	          ||        ||         GIMPS         |      |    GIMPS     | |
337	          ||        ||     Encapsulation     |      |Internal State| |
338	          ||        ||                       |<<<>>>| Maintenance  | |
339	          ||        |+-----------------------+      +--------------+ |
340	          ||        |GIMPS: Messaging Layer                          |
341	          ||        +------------------------------------------------+
342	         NSIS               |       |       |       |
343	       Transport          .............................
344	         Level            . Transport Layer Security  .
345	       ("NTLP")           .............................
346	          ||                |       |       |       |
347	          ||              +----+  +----+  +----+  +----+
348	          ||              |UDP |  |TCP |  |SCTP|  |DCCP|....
349	          ||              +----+  +----+  +----+  +----+
350	          ||                |       |       |       |
351	          ||              .............................
352	          ||              .     IP Layer Security     .
353	          ||              .............................
354	          VV                |       |       |       |
355	   =========================|=======|=======|=======|==============
356	                            |       |       |       |
357	                    +----------------------------------------------+
358	                    |                      IP                      |
359	                    +----------------------------------------------+

361	           Figure 2: Protocol Stacks for Signaling Transport

363	   The datagram mode uses an unreliable unsecured datagram transport
364	   mechanism, with UDP as the initial choice.  The connection mode can
365	   use any stream or message-oriented transport protocol.  It may employ
366	   specific network layer security associations (e.g.  IPsec), or an
367	   internal transport layer security association (e.g.  TLS).

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

377	   It must be understood that the routing and transport decisions made
378	   by GIMPS are not totally independent.  If the message transfer has
379	   requirements that enforce the use of connection mode (e.g.  because
380	   fragmentation is required), this can only be used between explicitly
381	   identified nodes.  In such cases, the GIMPS node must carry out
382	   signaling in datagram mode to identify the peer and then set up the
383	   necessary transport connection.  The datagram mode option of sending
384	   the message in the direction of the flow receiver and relying on
385	   interception is not available.

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

395	3.2  Design Attributes

397	   Soft state: All parts of GIMPS state are subject to time-out
398	      ("soft-state").  'State' here includes the messaging associations
399	      managed by GIMPS.

401	   Application-neutral: GIMPS is designed to support the largest range
402	      of signaling applications.  While a number of such applications
403	      have been identified, it appears likely that new ones will emerge.

405	   Mobility support: End systems can change their network attachment
406	      point and network address during a session.  GIMPS minimises the
407	      use of IP addresses as identifiers for non-topological information
408	      (e.g.  authentication state).

410	   Efficient: Signaling often occurs before an application such as an IP
411	      telephone conversation can commence, so that any signaling delay
412	      becomes noticeable to the application.  Signaling delays are
413	      incurred by the delay in finding signaling nodes along the path
414	      (peer discovery), in retransmitting lost signaling messages and in
415	      setting up security associations between nodes, among other
416	      factors.  GIMPS attempts to minimise these delays by several
417	      mechanisms, such as the use of high performance transport
418	      protocols to circumvent message loss, and the re-use of messaging
419	      associations to avoid setup latency.  If explicit discovery is
420	      needed it is a lightweight process which only probes local
421	      topology, and GIMPS also allows it to be bypassed completely for
422	      downstream datagram mode messages.

424	   IP version neutral: GIMPS supports both IPv4 and IPv6: it can use
425	      either for transport, largely as a result of their support in the
426	      underlying transport protocols, and can signal for either type of
427	      flow.  In addition, GIMPS is able to operate on dual-stack nodes
428	      (to bridge between v4 and v6 regions) and also to operate across
429	      v4/v6 boundaries and other addressing boundaries.  Specific
430	      transition issues are considered in Section 6.5.

432	   Transport neutral: GIMPS can operate over any message or
433	      stream-oriented transport layer, including UDP, DCCP, TCP and
434	      SCTP.  Messages sent over protocols that do not offer a native
435	      fragmentation service, such as UDP or DCCP, are strictly limited
436	      in size to avoid loss-amplification; in the case of UDP, they must
437	      also be limited in rate to avoid network congestion.

439	   Proxy support: The end systems in a session may not be capable of
440	      handling either the signaling transport or the application and may
441	      instead rely on proxies to initiate and terminate signaling
442	      sessions.  Proxy support is limited to nodes that are actually on
443	      the data path (for example, access routers for stub networks);
444	      signaling from a 3rd party node not associated with the data path
445	      is not considered.  GIMPS decouples the operation of the messaging
446	      functions from the flow source and destination addresses, treating
447	      these primarily as data.

449	   Scaleable: As will be discussed in Section 4.3, up to one messaging
450	      association is generally kept for each adjacent GIMPS peer and
451	      thus association state scales better than the number of sessions.
452	      (Many peers may not have association state at all, if there are no
453	      messages for sessions visiting those nodes that warrant such
454	      treatment.) Messaging associations are managed based on policy at
455	      each node, depending on trade-offs between fast peer-to-peer
456	      communication and state overhead.  Messaging association state can
457	      be removed immediately after the last signaling session to a
458	      particular next-hop is removed, after some delay to wait for new
459	      sessions, or only if resource demands warrant it.

461	3.3  Example of Operation

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

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

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

483	   2.  The message payload is passed to the GIMPS layer in GN1, along
484	       with a definition of the flow and description of the transfer
485	       requirements {downstream, unsecured, unreliable}.  GIMPS
486	       determines that this particular message does not require
487	       fragmentation and that it has no knowledge of the next peer for
488	       this flow and signaling application; however, it also determines
489	       that this application is likely to require secured upstream and
490	       downstream transport of large messages in the future.  This
491	       determination is a function of node-local policy, and some
492	       options for how it may be communicated between NSLP and GIMPS
493	       implementations within a node are indicated in Appendix D.

495	   3.  GN1 therefore constructs a UDP datagram with the signaling
496	       application payload, and additional payloads at the GIMPS level
497	       to be used to initiate the possible setup of a messaging
498	       association.  This datagram is injected into the network,
499	       addressed towards the flow destination and with a Router Alert
500	       Option included.

502	   4.  This D-mode message passes through the network towards the flow
503	       receiver, and is seen by each router in turn.  GIMPS-unaware
504	       routers will not recognise the RAO value and will forward the
505	       message unchanged; GIMPS-aware routers which do not support the
506	       signaling application in question will also forward the message
507	       unchanged, although they may need to process more of the message
508	       to decide this.

510	   5.  The message is finally intercepted at GN2.  The GIMPS layer
511	       identifies that the message is relevant to a local signaling
512	       application, and passes the signaling application payload and
513	       flow description to upwards to it.  From there, the signaling
514	       application in GN2 can continue to process this message as in GN1
515	       (compare step 1), and this will eventually result in the message
516	       reaching the flow receiver.

518	   6.  In parallel, the GIMPS instance in GN2 recognises that GN1 is
519	       attempting to discover GN2 in order to set up a messaging
520	       association for future signaling for the flow.  There are two
521	       possible cases:

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

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

535	   7.  Eventually, another signaling application message works its way
536	       upstream from the receiver to GN2.  This message contains a
537	       description of the actual resources requested, along with
538	       authorisation and other security information.  The signaling
539	       application in GN2 passes this payload to the GIMPS level, along
540	       with the flow definition and transfer requirements {upstream,
541	       secured, reliable}.

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

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

556	   It should be understood that many of these details of GIMPS
557	   operations can be varied, either by local policy or according to
558	   signaling application requirements, and they are also subject to
559	   development and refinement as the protocol design proceeds.  The
560	   authoritative details are contained in the remainder of this
561	   document.

563	4.  GIMPS Processing Overview

565	   This section defines the basic structure and operation of GIMPS.  It
566	   is divided into three parts.  Section 4.1 gives an overview of the
567	   per-flow and per-peer state that GIMPS maintains for the purpose of
568	   transferring messages.  Section 4.2 describes how messages are
569	   processed in the case where any necessary messaging associations and
570	   associated routing state already exist; this includes the simple
571	   scenario of pure datagram mode operation, where no messaging
572	   associations are necessary in the first place (equivalent to the
573	   transport functionality of base RSVP as defined in [9]).  Section 4.3
574	   describes how routing state is maintained and how messaging
575	   associations are initiated and terminated.

577	4.1  GIMPS State

579	4.1.1  Message Routing State

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

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

589	   Message Routing Information (MRI): This defines the method to be used
590	      to route the message, and any associated addressing information.
591	      In the simplest case, the message routing method is to follow the
592	      path that is being taken by the data flow, and the associated
593	      addressing is the flow header N-tuple (i.e.  the Flow-Identifier
594	      of [22]).

596	   Session Identification (SID): This is a cryptographically random and
597	      (probabilistically) globally unique identifier of the application
598	      layer session that is using the flow.  For a given flow, different
599	      signaling applications may or may not use the same session
600	      identifier.  Often there will only be one flow for a given
601	      session, but in mobility/multihoming scenarios there may be more
602	      than one and they may be differently routed.

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

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

612	   Upstream peer: the adjacent GIMPS peer closer to the flow source.
613	      This could be an IP address (learned from previous signaling) or a
614	      pointer to a messaging association.  It could also be null, if
615	      this node is the flow sender or this node is not storing reverse
616	      routing state, or a special value to indicate that this node is
617	      the last upstream node (but not the sender).

619	   Downstream peer: the adjacent GIMPS peer closer to the flow
620	      destination.  This could be a pointer to a messaging association,
621	      or it could be null, if this node is the flow receiver or this
622	      node is only sending downstream datagram mode messages for this
623	      flow and signaling application, or a special value to indicate
624	      that this node is the last downstream node (but not the receiver).

626	   Note that both the upstream and downstream peer state may be null,
627	   and that the session identifier information is not actually required
628	   for message processing; in that case, no state information at all
629	   needs to be stored in the table.  Both items of peer identification
630	   state have associated timers for how long the identification can be
631	   considered accurate; when these timers expire, the peer
632	   identification (IP address or messaging association pointer) is
633	   purged if it has not been refreshed.  An example of a routing state
634	   table for a simple scenario is given in Appendix B.

636	   Note also that the information is described as a table of flows, but
637	   that there is no implied constraint on how the information is stored.
638	   For example, in a network using pure destination address routing
639	   (without load sharing or any form of policy-based forwarding), the
640	   downstream peer information might be possible to store in an
641	   aggregated form in the same manner as the IP forwarding table.  In
642	   addition, many of the per-flow entries may point to the same per-peer
643	   state (e.g.  the same messaging association) if the flows go through
644	   the same adjacent peer.  However, in general, and especially if GIMPS
645	   peers are several IP hops away, there is no way to identify the
646	   correct downstream peer for a flow and signaling application from the
647	   local forwarding table using prefix matching, and the same applies
648	   always to upstream peer state because of the possibility of
649	   asymmetric routing.  Per-flow routing state has to be stored, just as
650	   for RSVP [9].

652	4.1.2  Messaging Association State

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

660	   o  messages pending transmission while an association is being
661	      established;

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

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

670	4.2  Basic Message Processing

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

682	       +---------------------------------------------------------+
683	       |        >>  Signaling Application Processing   >>        |
684	       |                                                         |
685	       +--------^---------------------------------------V--------+
686	                ^                                       V
687	                ^             NSLP Payloads             V
688	                ^                                       V
689	       +--------^---------------------------------------V--------+
690	       |                    >>    GIMPS   >>                     |
691	       |  ^           ^  ^     Processing      V  V           V  |
692	       +--x-----------u--d---------------------d--u-----------x--+
693	          x           u  d                     d  u           x
694	          x           u  d>>>>>>>>>>>>>>>>>>>>>d  u           x
695	          x           u  d      Bypass at      d  u           x
696	       +--x-----+  +--u--d--+  GIMPS level  +--d--u--+  +-----x--+
697	       | C-mode |  | D-mode |               | D-mode |  | C-mode |
698	       |Handling|  |Handling|               |Handling|  |Handling|
699	       +--x-----+  +--u--d--+               +--d--u--+  +-----x--+
700	          x          u   d                     d   u          x
701	          x    uuuuuu    d>>>>>>>>>>>>>>>>>>>>>d    uuuuuu    x
702	          x   u          d      Bypass at      d          u   x
703	       +--x--u--+  +-----d--+    router     +--d-----+  +--u--x--+
704	       |IP Host |  |  RAO   |  alert level  |  RAO   |  |IP Host |
705	       |Handling|  |Handling|               |Handling|  |Handling|
706	       +--x--u--+  +-----d--+               +--d-----+  +--u--x--+
707	          x  u           d                     d           u  x

709	       +--x--u-----------d--+               +--d-----------u--x--+
710	       |      IP Layer      |               |      IP Layer      |
711	       |   (Receive Side)   |               |  (Transmit Side)   |
712	       +--x--u-----------d--+               +--d-----------u--x--+
713	          x  u           d                     d           u  x
714	          x  u           d                     d           u  x
715	          x  u           d                     d           u  x

717	            uuuuuuuuuuuuuu = upstream datagram mode messages
718	            dddddddddddddd = downstream datagram mode messages
719	            xxxxxxxxxxxxxx = connection mode messages
720	                       RAO = Router Alert Option

722	              Figure 3: Message Paths through a GIMPS Node

724	   Note that the same messages are used for maintaining internal GIMPS
725	   state and carrying signaling application payloads.  The state
726	   maintenance takes place as a result of processing specific GIMPS
727	   payloads in these messages.  The processing of these payloads is the
728	   subject of Section 4.3.

730	4.2.1  Message Reception

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

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

743	   Reception in datagram mode depends on the message direction.
744	   Upstream messages (from a downstream peer) will arrive UDP
745	   encapsulated and addressed directly to the receiving signaling node.
746	   Each datagram contains a single complete message which is passed to
747	   the GIMPS layer for further processing, just as in the connection
748	   mode case.

750	   Downstream datagram mode messages are UDP encapsulated with an IP
751	   router alert option to cause interception.  The signaling node will
752	   therefore 'see' all such messages.  The case where the NSLPID does
753	   not match a local signaling application is considered below in
754	   Section 4.2.4; otherwise, it is passed up to the GIMPS layer for
755	   further processing as in the other cases.

757	4.2.2  Local Processing

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

764	   One GIMPS-internal payload which is carried in each message and
765	   requires processing is the GIMPS hop count.  This is decremented on
766	   input processing, and checked to be greater than zero on output
767	   processing.  The primary purpose of the GIMPS hop count is to prevent
768	   message looping.

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

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

780	4.2.3  Message Transmission

782	   When a message is available for transmission, GIMPS uses internal
783	   policy and the stored routing state to determine how to handle it.
784	   The following processing applies equally to locally generated
785	   messages and messages forwarded from within the GIMPS or signaling
786	   application levels.

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

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

794	   o  protocol specification: for example, this document could specify
795	      that a message that requires fragmentation MUST be sent over a
796	      messaging association;

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

802	   In principle, as well as determining that some messaging association
803	   must be used, GIMPS could select between a set of alternatives, e.g.
804	   for load sharing or because different messaging associations provide
805	   different transport or security attributes (see Section 8.5 for
806	   further discussion).

808	   If the use of a messaging association is selected, the message is
809	   queued on the association (found from the upstream or downstream peer
810	   state table), and further output processing is carried out according
811	   to the details of the protocol stack used for the association.  If no
812	   appropriate association exists, the message is queued while one is
813	   created (see Section 4.3).  If no association can be created, this is
814	   again an error condition, and should be indicated back to the NSLP.

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

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

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

829	4.2.4  Bypass Forwarding

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

836	   A downstream datagram mode message contains an RAO value associated
837	   with NSIS, and the IP layer is unable to determine whether to forward
838	   it.

840	   A downstream datagram mode message contains an RAO value which is
841	   relevant to the node, but the signaling application for the actual
842	   NSLPID is not processed.

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

849	   In all cases, the role of GIMPS is to forward the message essentially
850	   unchanged.  However, a GIMPS implementation must ensure that the IP
851	   TTL field and GIMPS hop count are managed correctly to prevent
852	   message looping, and this should be done consistently independently
853	   of whether the processing (e.g.  for case (1)) takes place on the
854	   fast path or in GIMPS-specific code.  The rules are that in cases (1)
855	   and (2), the IP TTL is decremented just as if the message was a
856	   normal IP forwarded packet; in cases (2) and (3) the GIMPS hop count
857	   is decremented as in the case of normal input processing.

859	4.3  Routing State and Messaging Association Maintenance

861	   The main responsibility of the GIMPS layer is to manage the routing
862	   state and messaging associations which are used in the basic message
863	   processing described above.  Routing state is installed and
864	   maintained by datagram mode messages containing specific GIMPS
865	   payloads.  Messaging associations are dependent on the existence of
866	   routing state, but are actually set up by the normal procedures of
867	   the transport and security protocols that comprise the messaging
868	   association.  Timers control routing state and messaging association
869	   refresh and expiration.

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

875	   The initial message in any routing state maintenance operation is a
876	   downstream datagram mode message, sent from the querying node and
877	   intercepted at the responding node.  This is encapsulated and
878	   addressed just as in the normal case; in particular, it has
879	   addressing and other identifiers appropriate for the flow and
880	   signaling application that state maintenance is being done for, and
881	   it is allowed to contain an NSLP payload.  Processing at the querying
882	   and responding nodes is also essentially the same.  However, the
883	   querying node includes additional payloads: its own address
884	   information, a proposal for possible messaging association protocol
885	   stacks, and optionally 'Discover-Query' information, including a
886	   Response Request flag and a Query Cookie.  This message is informally
887	   referred to as a 'GIMPS-query'.  The role of the cookies in this and
888	   subsequent messages is to protect against certain denial of service
889	   attacks.

891	           +----------+              +----------+
892	           | Querying |              |Responding|
893	           |   Node   |              |   Node   |
894	           +----------+              +----------+

896	                      GIMPS-query
897	                ---------------------->
898	                Router Alert Option
899	                MRI/SID/NSLPID           ...........
900	                Q-Node Addressing        . Routing .
901	                [Stack Proposal]         .  state  .  ^
902	                [Query Cookie]           .installed.  |     Existing
903	                [Response Request]       .   at    .  |    messaging
904	                [NSLP Payload]           .R-node(1).  |   associations
905	                                         ...........  |   can be used
906	                    GIMPS-response                    |    from here
907	   ...........  <----------------------               |     onwards
908	   . Routing .  MRI/SID/NSLPID                        |
909	   .  state  .  Query cookie                          |
910	   .installed.  R-Node Addressing                     | ^
911	   .   at    .            (D Mode only)               | |
912	   . Q-node  .  [Stack Proposal]                      | |
913	   ...........  [Responder Cookie]                    | |
914	                [Response Request]                    | |     New
915	                [NSLP Payload]                        | |  messaging
916	                                                      | | associations
917	                    Final handshake                   | |  can be set
918	                ---------------------->               | | up from here
919	                MRI/SID/NSLPID           ...........  | |   onwards
920	                Responder Cookie         . Routing .  | |
921	                Q-Node Addressing        .  state  .  | |
922	                         (D Mode only)   .installed.  | |
923	                [NSLP Payload]           .   at    .  | |
924	                                         .R-node(2).  | |
925	                                         ...........  | |

927	               Figure 4: Message Sequence at State Setup

929	   In the responding node, the GIMPS level processing of the
930	   Discover-Query information triggers the generation of a
931	   'GIMPS-response' message.  This is also a normally encapsulated and
932	   addressed message with particular payloads, this time in the upstream
933	   direction.  Again, it can contain an NSLP payload (possibly a
934	   response to the NSLP payload in the initial message).  It includes
935	   its own addressing information, a counter-proposal for messaging
936	   association protocol stacks, and the Query Cookie, and optionally
937	   'Discover-Response' information, including another Response Request
938	   flag and a Responder Cookie.  Note that if a messaging association
939	   already exists towards the querying node, this can be used to deliver
940	   the GIMPS-response message; otherwise, datagram mode is used.

942	   The querying node installs the responder address as downstream peer
943	   state information after verifying the Query Cookie in the
944	   GIMPS-response.  The responding node can install the querying address
945	   as upstream peer state information at two points in time:

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

949	   2.  after a third message in the downstream direction containing the
950	       Responder Cookie.

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

957	   Setup of messaging associations begins when both downstream peer
958	   addressing information is available and a new messaging association
959	   is actually needed.  (In many cases, the GIMPS-response message above
960	   will identify a downstream peer for whom an appropriate messaging
961	   association already exists, in which case no further action is
962	   needed.) Setup of the messaging association always starts from the
963	   upstream node, but it can be used equally in both directions.  The
964	   negotiation of what protocols to use for the messaging association is
965	   controlled by the Stack Proposal information exchanged, and the
966	   processing is outline in Section 6.6.

968	   Refresh and expiration of all types of state is controlled by timers.
969	   State in the routing table has a per-flow, per-direction timer, which
970	   expires after a routing state lifetime.  It is the responsibility of
971	   the querying node to generate a GIMPS-query message, optionally with
972	   a Discover-Query payload, before this timer expires, if it believes
973	   that the flow is still active.  Receipt of the message at the
974	   responding node will refresh upstream peer addressing state, and
975	   receipt of a GIMPS-response at the querying node will refresh any
976	   downstream peer addressing state if it exists.  Note that nodes do
977	   not control the refresh of upstream peer state themselves, they are
978	   dependent on the upstream peer for this.

980	   Messaging associations can be managed by either end.  Management
981	   consists of tearing down unneeded associations.  Whether an
982	   association is needed is a local policy decision, which could take
983	   into account the cost of keeping the messaging association open, the
984	   level of past activity on the association, and the likelihood of
985	   future activity (e.g.  if there are flows still in place which might
986	   generate messages that would use it).  Messaging associations can
987	   always be set up on demand, and messaging association status is not
988	   made directly visible outside the GIMPS layer.  Therefore, even if
989	   GIMPS tears down and later re-establishes a messaging association,
990	   signaling applications cannot distinguish this from the case where
991	   the association is kept permanently open.

993	5.  Message Formats and Encapsulations

995	5.1  GIMPS Messages

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

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

1008	   GIMPS-message: A message is either a datagram mode message or a
1009	   connection mode message.  GIMPS can detect which by the encapsulation
1010	   the message arrives over.

1012	       GIMPS-message = D-message / C-message

1014	   D-message: A datagram mode message is either upstream or downstream
1015	   (slightly different contents are allowed); the common header contains
1016	   a flag to say which.

1018	       D-message = D-upstream-message / D-downstream-message

1020	   C-message: A connection mode message is either upstream or downstream
1021	   (again, slightly different contents are allowed); the common header
1022	   contains a flag to say which.  Note that upstream and downstream
1023	   messages can be mixed on a single messaging association.

1025	       C-message = C-upstream-message / C-downstream-message

1027	   D-downstream-message: A downstream datagram mode message is used for
1028	   the GIMPS-query and final handshake in the discovery procedure, and
1029	   can also be used simply for carrying NSLP data.  Note that the
1030	   Common-Header includes a flag to indicate whether an explicit
1031	   response is required.

1033	       D-downstream-message = Common-Header
1034	                              Message-Routing-Information
1035	                              Node-Addressing
1036	                              Session-Identification
1037	                              [ Stack-Proposal ]
1038	                              [ Query-Cookie / Responder-Cookie ]
1039	                              [ Routing-State-Lifetime ]
1040	                              [ NSLP-Data ]

1042	   D-upstream-message: An upstream datagram mode message is used for the
1043	   GIMPS-response in the discovery procedure, and can also be used
1044	   simply for carrying NSLP data.

1046	       D-upstream-message   = Common-Header
1047	                              Message-Routing-Information
1048	                              Node-Addressing
1049	                              Session-Identification
1050	                              [ Stack-Proposal ]
1051	                              [ Query-Cookie [ Responder-Cookie ] ]
1052	                              [ Routing-State-Lifetime ]
1053	                              [ NSLP-Data ]

1055	   C-downstream-message: A downstream connection mode message is used
1056	   primarily for carrying NSLP data, but can also be used for the final
1057	   handshake during discovery.  Connection mode messages do not carry
1058	   node addressing, since this can be inferred from the messaging
1059	   association.

1061	       C-downstream-message = Common-Header
1062	                              Message-Routing-Information
1063	                              Session-Identification
1064	                              [ Responder-Cookie ]
1065	                              [ Routing-State-Lifetime ]
1066	                              [ NSLP-Data ]

1068	   C-upstream-message: An upstream connection mode message is used
1069	   primarily for carrying NSLP data, but can also be used for the
1070	   GIMPS-response during discovery (which is the only case where a
1071	   Stack-Proposal TLC can be included).

1073	       C-upstream-message   = Common-Header
1074	                              Message-Routing-Information
1075	                              Session-Identification
1076	                              [ Stack-Proposal ]
1077	                              [ Query-Cookie [ Responder-Cookie ] ]
1078	                              [ Routing-State-Lifetime ]
1079	                              [ NSLP-Data ]

1081	5.2  Information Elements

1083	   This section describes the content of the various information
1084	   elements that can be present in each GIMPS message, both the common
1085	   header, and the individual TLVs.  The format description in terms of
1086	   bit patterns is provided (in an extremely preliminary form) in
1087	   Appendix C.

1089	5.2.1  The Common Header

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

1094	   Version: The version number of the GIMPS protocol.

1096	   Length: The number of TLVs following in this message.

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

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

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

1108	   Response requested flag: A bit to indicate that this message contains
1109	      a cookie which must be echoed in the response.

1111	5.2.2  TLV Objects

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

1118	   These items are contained in each GIMPS message:

1120	   Message-Routing-Information (MRI): Information sufficient to define
1121	      the route that the flow will take through the network.

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

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

1134	       Flow-Identifier = network-layer-version
1135	                         source-address prefix-length
1136	                         destination-address prefix-length
1137	                         IP-protocol
1138	                         traffic-class
1139	                         [ flow-label ]
1140	                         [ ipsec-SPI / L4-ports]

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

1146	   Session-Identification (SID): The GIMPS session identifier is a long,
1147	      cryptographically random identifier chosen by the node which
1148	      begins the signaling exchange (the signaling application at the
1149	      node may specify it explicitly, or leave it up to GIMPS to select
1150	      a value).  The length is open, but 128 bits should be more than
1151	      sufficient to make the probability of collisions orders of
1152	      magnitude lower than other failure reasons.  The session
1153	      identifier should be considered immutable end-to-end along the
1154	      flow path (GIMPS never changes it, and signaling applications
1155	      should propagate it unchanged on messages for the same session).

1157	   The following items are optional:

1159	   Node addressing: Minimally, this is the IP address at which the GIMPS
1160	      node originating the message can be reached; this will be used to
1161	      fill in peer routing state.  It may also include a logical
1162	      interface identifier to assist in route change handling, see
1163	      Section 6.1, and port and other information relevant to the
1164	      messaging association protocols.  This field must be considered
1165	      mutable to allow for NAT traversal.  The level of flexibility
1166	      required in this field is discussed in Section 8.5.

1168	   Stack Proposal: This field contains information about which
1169	      combinations of transport and security protocols are proposed for
1170	      use in messaging associations.  This field must be considered
1171	      immutable between GIMPS peers; see Section 6.6 for further
1172	      details.

1174	   Query-Cookie/Responder-Cookie: A query-cookie is optional in a
1175	      GIMPS-query message and if present must be echoed in a
1176	      GIMPS-response; a response-cookie is optional in a GIMPS-response
1177	      message, and if present must be echoed in the following downstream
1178	      message.  Cookies are variable length (chosen by the cookie
1179	      generator) and need to be designed so that a node can determine
1180	      the validity of a cookie without keeping state.  A future version
1181	      of this specification will include references to techniques for
1182	      generating such cookies.

1184	   Routing-State-Lifetime: The lifetime of GIMPS routing state in the
1185	      absence of refreshes, measured in seconds.  Defaults to 30
1186	      seconds.

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

1191	5.3  Encapsulation in Datagram Mode

1193	   Encapsulation in datagram mode is simple.  The complete set of GIMPS
1194	   payloads for a single message is concatenated together with the
1195	   common header, and placed in the data field of a UDP datagram.  UDP
1196	   checksums should be enabled.  Upstream messages are directly
1197	   addressed to the adjacent peer.  Downstream messages are addressed
1198	   using information from the Message-Routing-Information and
1199	   encapsulated with a Router Alert Option.  Open issues about
1200	   alternative encapsulations, addressing possibilities, and router
1201	   alert option value-field setting are discussed in Section 8.2,
1202	   Section 8.3 and Section 8.4 respectively.

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

1214	   For the case of basic path-coupled signaling where the MRI
1215	   information is the Flow Identifier, it is vital that the D-mode
1216	   message truly mimics the actual data flow, since this is the basis of
1217	   how the signaling message is attached to the data path.  To this end,
1218	   GIMPS may set the traffic class and (for IPv6) flow label to match
1219	   the values in the Flow-Identifier if this would be needed to ensure
1220	   correct routing.  Similar considerations may apply to other message
1221	   routing methods if defined.

1223	5.4  Encapsulation in Connection Mode

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

1230	5.4.1  Choice of Transport Protocol

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

1237	   SCTP [6] satisfies all requirements.  (The bundling requirement is
1238	      met implicitly by the use of Nagle-like algorithms inside the SCTP
1239	      stack.)

1241	   DCCP [7] is message based but does not provide bundling or
1242	      fragmentation.  Bundling can be carried out by the GIMPS layer
1243	      sending multiple messages in a single datagram; because the common
1244	      header includes length information (number of TLVs), the message
1245	      boundaries within the datagram can be discovered during parsing.
1246	      Fragmentation of GIMPS messages over multiple datagrams should be
1247	      avoided, because of amplification of message loss rates that this
1248	      would cause.

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

1254	   UDP can be augmented as in the DCCP case.  (An additional reason for
1255	      avoiding fragmentation is the lack of congestion control
1256	      functionality in UDP.)

1258	   It can be seen that all of these protocol options can be supported by
1259	   the basic GIMPS message format already presented.  GIMPS messages
1260	   requiring fragmentation must be carried using a reliable transport
1261	   protocol, TCP or SCTP.

1263	5.4.2  Encapsulation Format

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

1272	      +---------------------------------------------+
1273	      |                  L2 Header                  |
1274	      +---------------------------------------------+
1275	      |                  IP Header                  |   ^
1276	      |      Source address = signaling source      |   ^
1277	      | Destination address = signaling destination |   .
1278	      +---------------------------------------------+   .
1279	      |                  L4 Header                  |   . ^
1280	      |     (Standard TCP/SCTP/DCCP/UDP header)     |   . ^
1281	      +---------------------------------------------+   . .
1282	      |                GIMPS Message                |   . . ^
1283	      | (Common header and TLVs as in section 5.1)  |   . . ^  Scope of
1284	      +---------------------------------------------+   . . .  security
1285	      | Additional GIMPS messages, each with its    |   . . . protection
1286	      | own common header, either as a continuous   |   . . . (depending
1287	      |   stream, or continuing to the next L4      |   . . . on channel
1288	      .             message boundary                .   . . .  security
1289	      .                                             .   V V V  mechanism
1290	      .                                             .   V V V   in use)

1292	                Figure 5: Connection Mode Encapsulation

1294	   Note that when GIMPS messages are carried in connection mode in this
1295	   way, between the GIMPS peers they are treated just like any other
1296	   traffic by intermediate routers.  Indeed, it would be impossible for
1297	   intermediate routers to carry out any processing on the messages
1298	   without terminating the transport and security protocols used.

1300	   Signaling messages are only ever delivered between peers established
1301	   in GIMPS-query/response exchanges.  Any route change is not detected
1302	   until another GIMPS-query/response procedure takes place; in the
1303	   meantime, signaling messages are misdelivered.  GIMPS is responsible
1304	   for prompt detection of route changes to minimise the period during
1305	   which this can take place.

1307	6.  Advanced Protocol Features

1309	6.1  Route Changes and Local Repair

1311	6.1.1  Introduction

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

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

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

1339	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1340	               x  +--+        +--+        +--+  x      Initial
1341	              x  .|B1|_.......|C1|_.......|D1|   x     Configuration
1342	             x  . +--+.      .+--+.      .+--+\.  x
1343	            x  .       .    .      .    .       .  x
1344	    >>xxxxxx  .         .  .        .  .         .  xxxxxx>>
1345	         +-+ .           ..          ..           . +-+
1346	    .....|A|/            ..          ..            .|E|_....
1347	         +-+ .          .  .        .  .          . +-+
1348	              .        .    .      .    .        .
1349	               .      .      .    .      .      .
1350	                . +--+        +--+        +--+ .
1351	                 .|B2|_.......|C2|_.......|D2|/
1352	                  +--+        +--+        +--+

1354	                  +--+        +--+        +--+         Configuration
1355	                 .|B1|........|C1|........|D1|         after failure
1356	                . +--+       .+--+        +--+         of D1-E link
1357	               .      \.    .     \.    ./
1358	              .         .  .        .  .
1359	         +-+ .           ..          ..             +-+
1360	    .....|A|.            ..          ..            .|E|_....
1361	         +-+\.          .  .        .  .          . +-+
1362	    >>xxxxxx  .        .    .      .    .        .  xxxxxx>>
1363	            x  .      .      .    .      .      .  x
1364	             x  . +--+        +--+        +--+ .  x
1365	              x  .|B2|_.......|C2|_.......|D2|/  x
1366	               x  +--+        +--+        +--+  x
1367	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

1371	               >>xxxxxxx>> = flow direction

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

1377	                      Figure 6: A Re-Routing Event

1379	6.1.2  Route Change Detection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1455	   +----------------------+----------------------+---------------------+
1456	   | Method               | Downstream           | Upstream            |
1457	   +----------------------+----------------------+---------------------+
1458	   | Local Trigger        | Discovers new        | Not applicable      |
1459	   |                      | downstream interface |                     |
1460	   |                      | (and peer if local)  |                     |
1461	   |                      |                      |                     |
1462	   | Extended Trigger     | Discovers new        | May determine that  |
1463	   |                      | downstream interface | route from upstream |
1464	   |                      | and may determine    | peer will have      |
1465	   |                      | new downstream peer  | changed             |
1466	   |                      |                      |                     |
1467	   | C-Mode Monitoring    | Provides hint that   | Provides hint that  |
1468	   |                      | change has occurred  | change has occurred |
1469	   |                      |                      |                     |
1470	   | Data Plane           | Not applicable       | NSLP informs GIMPS  |
1471	   | Monitoring           |                      | that a change may   |
1472	   |                      |                      | have occurred       |
1473	   |                      |                      |                     |
1474	   | D-Mode Probing       | Discovers changed    | Discovers changed   |
1475	   |                      | Node-Addressing in   | Node-Addressing in  |
1476	   |                      | GIMPS-response       | GIMPS-query         |
1477	   +----------------------+----------------------+---------------------+

1479	6.1.3  Local Repair

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

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

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

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

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

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

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

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

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

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

1535	6.1.4  Local Signaling Application State Removal

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

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

1558	6.1.5  Operation with Heterogeneous NSLPs

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

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

1578	6.2  Policy-Based Forwarding and Flow Wildcarding

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

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

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

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

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

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

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

1618	6.3  NAT Traversal

1620	   As already noted, GIMPS messages must carry packet addressing and
1621	   higher layer information as payload data in order to define the flow
1622	   signalled for.  (This applies to all GIMPS messages, regardless of
1623	   how they are encapsulated or which direction they are travelling in.)
1624	   At an addressing boundary the data flow packets will have their
1625	   headers translated; if the signaling payloads are not likewise
1626	   translated, the signaling messages will refer to incorrect (and
1627	   probably meaningless) flows after passing through the boundary.

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

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

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

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

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

1652	   5.  Forward the message with these new payloads.

1654	   The original Message-Routing-Information and Node-Addressing payloads
1655	   should be retained in the message, but encapsulated in a new TLV
1656	   type.  (In the case of a sequence of NATs, this TLV would become a
1657	   list.) This TLV essentially becomes a recorded route for the D-mode
1658	   message; a GIMPS node that wished to do topology hiding could replace
1659	   these original payloads with opaque tokens, or omit them altogether.
1660	   Note that a consequence of this approach is that the routing state
1661	   tables at the actual signaling application peers (either side of the
1662	   NAT) are no longer directly compatible (in particular, the values of
1663	   Message-Routing-Information are different.

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

1675	6.4  Interaction with IP Tunnelling

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

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

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

1709	6.5  IPv4-IPv6 Transition and Interworking

1711	   GIMPS itself is essentially IP version neutral (version dependencies
1712	   are isolated in the formats of the Message-Routing-Information and
1713	   Node-Addressing TLVs, and GIMPS also depends on the version
1714	   independence of the protocols that support messaging associations).
1715	   In mixed environments, GIMPS operation will be influenced by the IP
1716	   transition mechanisms in use.  This section provides a high level
1717	   overview of how GIMPS is affected, considering only the currently
1718	   predominant mechanisms.

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

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

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

1745	   Packet Translation: (Applicable to SIIT [5] and NAT-PT [13].) Some
1746	      transition mechanisms allow IPv4 and IPv6 nodes to communicate by
1747	      placing packet translators between them.  From the GIMPS
1748	      perspective, this should be treated essentially the same way as
1749	      any other NAT operation (e.g.  between 'public' and 'private'
1750	      addresses) as described in Section 6.3.  In other words, the
1751	      translating node needs to be GIMPS aware; it will run GIMPS with
1752	      IPv4 on some interfaces and with IPv6 on others, and will have to
1753	      translate the Message-Routing-Information payload between IPv4 and
1754	      IPv6 formats for flows which cross between the two.  The
1755	      translation rules for the fields in the payload (including e.g.
1756	      traffic class and flow label) are as defined in [5].

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

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

1778	6.6  Messaging Association Protocol Negotiation

1780	   A key attribute of GIMPS is that it is flexible in its ability to use
1781	   existing transport and security protocols.  Different transport
1782	   protocols may have performance attributes appropriate to different
1783	   environments; different security protocols may fit appropriately with
1784	   different authentication infrastructures.  Even if a single choice
1785	   for GIMPS could be agreed today, the need to support new protocols in
1786	   the future cannot be ruled out.  Therefore, some sort of protocol
1787	   negotiation capability is required.

1789	   The implicit requirements for protocol negotiation are as follows:

1791	   o  It should be possible to request a set of protocols (e.g.  TLS/TCP
1792	      or SCTP/IPsec), not just a single protocol.

1794	   o  The negotiation should complete in 1 RTT.

1796	   o  The negotiation should be resistant to bidding-down ("man in the
1797	      middle") attacks.

1799	   o  At the same time, the message elements involved should allow NAT
1800	      traversal.

1802	   o  The set of possible protocols should be extensible.

1804	   The stacking requirements are reminiscent of [10], and the
1805	   negotiation requirements of [20], and the following outline is based
1806	   on the same principles.  In particular, the latter should be read for
1807	   a more detailed security discussion.

1809	   o  Each possible "protocol layer" is represented by an IANA-assigned
1810	      tag.  A protocol layer defines a well-known protocol (such as
1811	      "TCP") and a set of rules for its use (such as "Connect from
1812	      Querying Node").

1814	   o  A protocol layer may define some security related parameters, and
1815	      will probably also define some addressing options; the latter
1816	      would be carried in the Node-Addressing TLV and are not considered
1817	      further here.

1819	   o  A "profile" is a sequence of protocol layers.

1821	   o  A Stack-Proposal TLV consists of a sequence of profiles, and any
1822	      associated security parameters.

1824	   o  When attempting to set up a messaging association, a node includes
1825	      a Stack-Proposal TLV in the GIMPS-query.  The contents of the TLV
1826	      must be fixed for a given outbound interface and NSLPID.

1828	   o  The responding node includes another Stack-Proposal in the
1829	      GIMPS-Response.  The contents of this TLV must also be fixed for a
1830	      given outbound interface and NSLPID.

1832	   o  The querying node selects a common profile from the proposals and
1833	      sets up the protocol layers accordingly.  Once the messaging
1834	      association is open, it repeats the Stack-Proposal from the
1835	      GIMPS-Response.  The responding node can verify this to ensure
1836	      that no bidding down attack has occurred.

1838	   The exchanges parallel the cookie exchanges which protect routing
1839	   state setup, but they are largely independent.  (The cookie exchanges
1840	   can be used to protect nodes from denial of service attacks
1841	   masquerading as a messaging association protocol setup, in case the
1842	   connection setup procedure for one of the protocols is
1843	   DoS-vulnerable, as is the case with TCP.)

1845	   It is expected that the initial set of protocol layers will be very
1846	   small; however, it could be extended, e.g.  to allow for different
1847	   configurations (e.g.  "Connect from Responding Node" or requiring the
1848	   use of particular protocol options) or entirely new protocols.

1850	7.  Security Considerations

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

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

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

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

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

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

1893	7.1  Message Confidentiality and Integrity

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

1907	7.2  Peer Node Authentication

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

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

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

1938	7.3  Routing State Integrity

1940	   The internal state in a node (see Section 4.1), specifically the
1941	   upstream and downstream peer identification, is used to route
1942	   messages.  If this state is corrupted, signaling messages may be
1943	   misdirected.

1945	   In the case where the message routing method is path-coupled
1946	   signaling, the messages need to be routed identically to the data
1947	   flow described by the Flow Identifier, and the routing state table is
1948	   the GIMPS view of how these flows are being routed through the
1949	   network in the immediate neighbourhood of the node.  Routes are only
1950	   weakly secured (e.g.  there is usually no cryptographic binding of a
1951	   flow to a route), and there is no other authoritative information
1952	   about flow routes than the current state of the network itself.
1953	   Therefore, consistency between GIMPS and network routing state has to
1954	   be ensured by directly interacting with the routing mechanisms to
1955	   ensure that the upstream and downstream signaling peers are the
1956	   appropriate ones for any given flow.  A good overview of security
1957	   issues and techniques in this sort of context is provided in [27].

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

1967	   Upstream peer identification can be installed directly on receiving a
1968	   GIMPS-query message containing addressing information for the
1969	   upstream peer.  However, any node in the network could generate such
1970	   a message (indeed, almost any node in the network could be the
1971	   genuine upstream peer for a given flow).  To protect against this,
1972	   two strategies are possible:

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

1985	   Authentication (weak or strong): the receiving node may refuse to
1986	      install upstream state until it has handshaked by some means with
1987	      the upstream peer.  This handshaking could be as simple as
1988	      requesting the upstream peer to echo the response cookie in the
1989	      discover-response payload of a GIMPS-response message (to
1990	      discourage nodes impersonating upstream peers from using forged
1991	      source addresses); or, it could be full peer authentication within
1992	      the messaging association, the reasoning being that an
1993	      authenticated peer can be trusted not to pretend that it is on
1994	      path when it is not.

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

2000	7.4  Denial of Service Prevention

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

2006	   However, GIMPS can still be subjected to denial-of-service attacks
2007	   where an attacker using forged source addresses forces a node to
2008	   establish state without return routability, causing a problem similar
2009	   to TCP SYN flood attacks.  In addition to vulnerabilities of a next
2010	   peer discovery an unprotected path discovery procedure might
2011	   introduce more denial of service attacks since a number of nodes
2012	   could possibly be forced to allocate state.  Furthermore, an
2013	   adversary might modify or replay unprotected signaling messages.
2014	   There are two types of state attacks and one computational resource
2015	   attack.  In the first state attack, an attacker floods a node with
2016	   messages that the node has to store until it can determine the next
2017	   hop.  If the destination address is chosen so that there is no
2018	   GIMPS-capable next hop, the node would accumulate messages for
2019	   several seconds until the discovery retransmission attempt times out.
2020	   The second type of state-based attack causes GIMPS state to be
2021	   established by bogus messages.  A related computational/
2022	   network-resource attack uses unverified messages to cause a node to
2023	   make AAA queries or attempt to cryptographically verify a digital
2024	   signature.  (RSVP is vulnerable to this type of attack.) Relying only
2025	   on upper layer security, for example based on CMS, might open a
2026	   larger door for denial of service attacks since the messages are
2027	   often only one-shot-messages without utilizing multiple roundtrips
2028	   and DoS protection mechanisms.

2030	   There are at least three defenses against these attacks:

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

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

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

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

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

2061	   Once a node has decided to establish routing state, there may still
2062	   be transport and security state to be established between peers.
2063	   This state setup is also vulnerable to additional denial of service
2064	   attacks.  GIMPS relies on the lower layer protocols that make up
2065	   messaging associations to mitigate such attacks.  The current
2066	   description assumes that the upstream node is always the one wishing
2067	   to establish a messaging association, so it is typically the
2068	   downstream node that needs to be protected.  Extensions are
2069	   considered in Section 8.6; these would require further analysis.

2071	8.  Open Issues

2073	8.1  Protocol Naming

2075	   Alternate names:
2076	   GIST: General Internet Signaling Transport
2077	   GIMPS: General Internet Messaging Protocol for Signaling
2078	   LUMPS: Lightweight Universal Messaging for Path associated Signaling

2080	   There is a danger of some ambiguity as to whether the protocol name
2081	   refers to the complete transport stack below the signaling
2082	   applications, or only to the additional protocol functionality above
2083	   the standard transport protocols (UDP, TCP etc.) The NSIS framework
2084	   uses the term NTLP for the first, but this specification uses the
2085	   GIST/variants names for the second (see Figure 2 in Section 3.1).  In
2086	   other words, this specification proposes to meet the requirements for
2087	   NTLP functionality by layering GIMPS/...  over existing standard
2088	   transport protocols.  It isn't clear if additional terminological
2089	   surgery is needed to make this clearer.

2091	8.2  General IP Layer Issues

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

2101	   The critical requirements for the encapsulation at this level are
2102	   that routers should be able to identify signaling packets for
2103	   processing, and that they should not mis-identify packets for
2104	   'normal' end-to-end user data flows as signaling packets.  The
2105	   current assumption is that UDP encapsulation can be used for such
2106	   messages, by allocating appropriate (new) value codes for the router
2107	   alert option (RAO) [1][4] to identify NSIS messages.  Specific open
2108	   issues about how to allocate such values are discussed in Section
2109	   8.4.

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

2120	8.3  Encapsulation and Addressing for Datagram Mode

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

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

2137	   Addressing for upstream datagram mode messages is simple: the IP
2138	   source address is the signaling source address, and the IP
2139	   destination address is the signaling destination address (compare
2140	   Figure 1).  For downstream datagram mode messages, the IP destination
2141	   address will be the flow destination address, but the IP source
2142	   address could be either of the flow source address or signaling
2143	   source address.  Some of the relative merits of these options are as
2144	   follows:

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

2154	   o  Conversely, using the signaling source address means that ICMP
2155	      error messages (specifically, unreachable port or address) will be
2156	      correctly delivered to the message originator, rather than being
2157	      sent back to the flow source.  Without seeing these messages, it
2158	      is very difficult for the querying node to recognise that it is
2159	      the last NSIS node on the path.  In addition, using the signaling
2160	      source address may make it possible to exchange messages through
2161	      GIMPS unaware NATs (although it isn't clear how useful the
2162	      resulting messages will be, see Section 6.3).

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

2171	8.4  Intermediate Node Bypass and Router Alert Values

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

2181	   There are two basic reasons why a GIMPS node might wish to ignore a
2182	   message:

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

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

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

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

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

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

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

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

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

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

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

2249	8.5  Messaging Association Flexibility

2251	   Section 4 discusses the use of 0 or 1 messaging associations between
2252	   any pair of GIMPS nodes.  However, logically it would be quite
2253	   possible to have more than one association, for example:

2255	   o  to allow different reliability characteristics;

2257	   o  to provide different levels of security protection or to have
2258	      security separation between different signaling streams;

2260	   o  even simply to have load split between different connections
2261	      according to priority (so there could be two associations with
2262	      identical protocol stacks).

2264	   It is possible to imagine essentially infinite flexibility in these
2265	   options, both in terms of how many possibilities are allowed and how
2266	   nodes signal their capabilities and preferences, without much
2267	   changing the overall GIMPS structure.  (The GIMPS-query and
2268	   GIMPS-response messages described in section Section 4.3 can be used
2269	   to exchange this information.) What is not clear is how much
2270	   flexibility is actually needed.

2272	8.6  Messaging Association Setup Message Sequences

2274	   The discussion of Section 4.3 assumes a simple fixed message
2275	   sequence, which we can picture as follows:

2277	   +---------------------------------+---------------------------------+
2278	   |            Direction            | Message                         |
2279	   +---------------------------------+---------------------------------+
2280	   |               --->              | GIMPS-query message             |
2281	   |                                 |                                 |
2282	   |               <---              | GIMPS-response message          |
2283	   |                                 |                                 |
2284	   |               ===>              | Querying node initiates         |
2285	   |                                 | messaging association setup     |
2286	   |                                 | messages                        |
2287	   |                                 |                                 |
2288	   |               <-->              | Signaling messages exchanged    |
2289	   +---------------------------------+---------------------------------+

2291	   There are several variants which could be considered at this level,
2292	   for example whether the messaging association could be set up by the
2293	   responding node:

2295	   +---------------------------------+---------------------------------+
2296	   |            Direction            | Message                         |
2297	   +---------------------------------+---------------------------------+
2298	   |               --->              | GIMPS-query message             |
2299	   |                                 |                                 |
2300	   |               <===              | Responding node initiates       |
2301	   |                                 | messaging association setup     |
2302	   |                                 | messages                        |
2303	   |                                 |                                 |
2304	   |               <-->              | Signaling messages exchanged    |
2305	   +---------------------------------+---------------------------------+

2307	   This saves a message but may be vulnerable to additional denial of
2308	   service attacks.

2310	   Another open area is how to manage the protocol exchanges that take
2311	   place in setting up the messaging association itself.  It is probably
2312	   an implementation matter to consider whether to carry out, for
2313	   example, the SCTP 4-way handshake only after IKE exchanges (for IPsec
2314	   SA initialisation) have completed, or whether these can be done
2315	   partly in parallel.  A more radical step is to carry the initial
2316	   request and response messages of both exchanges as payloads in the
2317	   GIMPS-query/response exchange, with the request message initially
2318	   formatted by the querying node with an unspecified destination IP
2319	   address.  This would require modifications to the protocol
2320	   implementations (especially at the querying node) similar to what is
2321	   needed for NAT traversal; it would have to be evaluated whether this
2322	   was worth the one or two round trip times that are saved.  Both this
2323	   technique and the "reverse connection" approach above can be
2324	   considered optimisations; given an appropriate negotiation procedure
2325	   in the base protocol as discussed in Section 6.6 they probably do not
2326	   need to be considered further for the initial version.

2328	   A final area is how the responding node propagates the signaling
2329	   message downstream.  It could initiate the downstream discovery
2330	   process as soon as it received the initial GIMPS-query message, or it
2331	   could wait until the first signaling application message has been
2332	   received (which might not be until a messaging association has been
2333	   established).  A similar timing question applies to when it should
2334	   initiate its own downstream messaging associations.  It is possible
2335	   that all these options are simply a matter for implementation
2336	   freedom, although leaving them open will make mobility and re-routing
2337	   behaviour rather harder to analyse, and again there are denial of
2338	   service implications for some approaches (see Section 7.4).

2340	8.7  GIMPS Support for Message Scoping

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

2347	   It may be that the GIMPS layer can assist such scoping, by detecting
2348	   and counting different types of nodes in the signaling plane.  The
2349	   simplest solution would be to count GIMPS nodes supporting the
2350	   relevant signaling application - this is already effectively done by
2351	   the GIMPS hop count.  A more sophisticated approach would be to track
2352	   the crossing of aggregation region boundaries, as introduced in
2353	   Section 8.4.  Whether this is plausible depends on the willingness of
2354	   operators to configure such boundary information in their routers.

2356	8.8  Additional Discovery Mechanisms

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

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

2376	8.9  Alternative Message Routing Requirements

2378	   The initial assumption of GIMPS is that signaling messages are to be
2379	   routed identically to data flow messages.  For this case of
2380	   path-coupled signaling, the MRI and upstream/downstream flag (in the
2381	   Common-Header) define the flow and the relationship of the signaling
2382	   to it sufficiently for GIMPS to route its messages correctly.
2383	   However, some additional modes of routing signaling messages have
2384	   been identified:

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

2395	   NAT Address Reservations: This applies to the case where a node
2396	      behind a NAT wishes to use NSIS signaling to reserve an address
2397	      from which it can be reached by a sender on the other side.  This
2398	      requires a message to be sent outbound from what will be the flow
2399	      receiver although no reverse routing state exists.  One possible
2400	      solution (assumed in [24]) is to construct a message with the
2401	      Flow-Routing-Information matching the possible senders and send it
2402	      as though it was downstream signaling.  It is not clear whether
2403	      signaling for the 'wrong direction' in this way will always be
2404	      treated consistently by GIMPS, especially if routing policies and
2405	      encapsulations for inbound and outbound traffic are treated very
2406	      differently within the rest of the network.

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

2414	   o  Defining the format of the MRI for the new message routing method
2415	      type.

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

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

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

2425	8.10  Congestion Control in Datagram Mode

2427	   The GIMPS-query and GIMPS-response messages may suffer from message
2428	   loss (e.g.  due to congestion or corruption).  Because a successful
2429	   handshake is necessary before a messaging association can even be
2430	   initiated, GIMPS must provide its own recovery method for these
2431	   cases.  A working assumption is that the querying node can repeat the
2432	   GIMPS-query with an exponential backoff until a response is received
2433	   or some retry threshold is reached.

2435	   More subtle is the case where there is a stream of D-mode messages
2436	   with no immediate feedback from the neighbour node.  This could be
2437	   the case where a signaling application was generating messages for
2438	   stateless processing in the interior of the network.  Here, the
2439	   appropriate approach may be to use rate-limiting algorithms such as
2440	   in ICMPv6 [11].  Another possibility would be to use ECN [17], if the
2441	   datagram mode messages can be correlated with a congestion controlled
2442	   messaging association which also supports ECN.  Details are clearly
2443	   for further study.

2445	8.11  Message Format Issues

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

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

2457	   Capabilities: For extensibility, it is useful to be able to mark
2458	      objects with some information about how they should be treated if
2459	      the receiving node does not implement them (e.g.  ignore or
2460	      reject).  Since the object space is shared between all protocols,
2461	      this marking has to be standardised across all the NSIS protocols.
2462	      Is an object marking scheme based on some flags in the object
2463	      header appropriate, or a more flexible scheme based on some type
2464	      of capability encoding?

2466	8.12  Protocol Design Details

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

2473	   o  Receiver initiated signaling applications need to have reverse
2474	      path state set up in the network, before the signaling application
2475	      itself can originate any messages.  Should this be done by GIMPS
2476	      carrying out the discovery for the specific signaling application
2477	      (which requires the flow sender to know what signaling
2478	      applications are going to be used), or should the discovery
2479	      attempt to find every GIMPS node and the signaling applications
2480	      they support?

2482	9.  Change History

2484	9.1  Changes In Version -02

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

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

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

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

2505	   4.  Extended Appendix C with a general discussion of rules for
2506	        message and object formats across GIMPS and other NSLPs.  Some
2507	        remaining open issues are noted in Section 8.11.

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

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

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

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

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

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

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

2543	9.2  Changes In Version -01

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

2558	   The full set of changes is as follows:

2560	   1.  Added a worked example in Section 3.3.

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

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

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

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

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

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

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

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

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

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

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

2613	   13.  Removed old open issues on Connection Mode Encapsulation
2614	        (section 8.7); added new open issues on Message Routing (Section
2615	        8.9) and Datagram Mode congestion control (Section 8.10).

2617	   14.  Added this change history.

2619	10.  References

2621	10.1  Normative References

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

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

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

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

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

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

2641	   [7]  Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
2642	        draft-ietf-dccp-spec-06 (work in progress), February 2004.

2644	   [8]  Stewart, R., "SCTP Partial Reliability Extension",
2645	        draft-ietf-tsvwg-prsctp-03 (work in progress), January 2004.

2647	10.2  Informative References

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

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

2656	   [11]  Conta, A. and S. Deering, "Internet Control Message Protocol
2657	         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
2658	         Specification", RFC 2463, December 1998.

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

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

2666	   [14]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.

2668	         Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2669	         2961, April 2001.

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

2674	   [16]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
2675	         3068, June 2001.

2677	   [17]  Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
2678	         Explicit Congestion Notification (ECN) to IP", RFC 3168,
2679	         September 2001.

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

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

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

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

2697	   [22]  Hancock, R., "Next Steps in Signaling: Framework",
2698	         draft-ietf-nsis-fw-05 (work in progress), October 2003.

2700	   [23]  Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
2701	         draft-ietf-nsis-threats-04 (work in progress), February 2004.

2703	   [24]  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
2704	         (NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May
2705	         2004.

2707	   [25]  Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
2708	         Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03
2709	         (work in progress), May 2004.

2711	   [26]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
2712	         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
2713	         progress), February 2004.

2715	   [27]  Nikander, P., "Mobile IP version 6 Route Optimization Security
2716	         Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work
2717	         in progress), December 2003.

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

2722	Authors' Addresses

2724	   Henning Schulzrinne
2725	   Columbia University
2726	   Department of Computer Science
2727	   450 Computer Science Building
2728	   New York, NY  10027
2729	   US

2731	   Phone: +1 212 939 7042
2732	   EMail: hgs+nsis@cs.columbia.edu
2733	   URI:   http://www.cs.columbia.edu

2735	   Robert Hancock
2736	   Siemens/Roke Manor Research
2737	   Old Salisbury Lane
2738	   Romsey, Hampshire  SO51 0ZN
2739	   UK

2741	   EMail: robert.hancock@roke.co.uk
2742	   URI:   http://www.roke.co.uk

2744	Appendix A.  Acknowledgements

2746	   This document is based on the discussions within the IETF NSIS
2747	   working group.  It has been informed by prior work and formal and
2748	   informal inputs from: Cedric Aoun, Attila Bader, Bob Braden, Marcus
2749	   Brunner, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth, Georgios
2750	   Karagiannis, John Loughney, Jukka Manner, Andrew McDonald, Glenn
2751	   Morrow, Dave Oran, Charles Shen, Melinda Shore, Martin Stiemerling,
2752	   Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Michael Welzl,
2753	   and Lars Westberg.  In particular, Hannes Tschofenig provided a
2754	   detailed set of review comments on the security section, and Andrew
2755	   McDonald provided the formal description for the initial packet
2756	   formats.  We look forward to inputs and comments from many more in
2757	   the future.

2759	Appendix B.  Example Message Routing State Table

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

2765	       A                        B          C          D           E
2766	   +------+                  +-----+    +-----+    +-----+    +--------+
2767	   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
2768	   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
2769	   |      |    +-+    +-+    |GIMPS|    |GIMPS|    |GIMPS|    |        |
2770	   +------+                  +-----+    +-----+    +-----+    +--------+

2772	                     ------------------------------>>
2773	                              Flow Direction

2775	                     Figure 7: A Signaling Scenario

2777	   Routing state table at node B:

2779	   +--------------------+----------+----------+----------+-------------+
2780	   |   Message Routing  |  Session |  NSLP ID | Upstream |  Downstream |
2781	   |     Information    |    ID    |          |   Peer   |     Peer    |
2782	   +--------------------+----------+----------+----------+-------------+
2783	   |    Method = Path   |  0xABCD  |   NSLP1  |   IP-#A  |    (null)   |
2784	   | Coupled; Flow ID = |          |          |          |             |
2785	   |   {IP-#A, IP-#E,   |          |          |          |             |
2786	   |  protocol, ports}  |          |          |          |             |
2787	   |                    |          |          |          |             |
2788	   |    Method = Path   |  0x1234  |   NSLP2  |   IP-#A  |  Pointer to |
2789	   | Coupled; Flow ID = |          |          |          |     B-D     |
2790	   |   {IP-#A, IP-#E,   |          |          |          |  messaging  |
2791	   |  protocol, ports}  |          |          |          | association |
2792	   +--------------------+----------+----------+----------+-------------+

2794	   The table shows the routing state at Node B for the single flow from
2795	   A to E.  The upstream state is just the same address for each
2796	   application.  For the downstream case, NSLP1 only requires datagram
2797	   mode messages and so no explicit routing state towards C is needed.
2798	   NSLP2 requires a messaging association for its messages towards node
2799	   D, and node C does not process NSLP2 at all, so the downstream peer
2800	   state for NSLP2 is a pointer to a messaging association that runs
2801	   directly from B to D.  Note that E is not visible in the state table
2802	   (except implicitly in the address in the message routing
2803	   information); routing state is stored only for adjacent peers.

2805	Appendix C.  Bit-Level Formats

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

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

2820	C.1  General NSIS Formatting Guidelines

2822	   Each NSIS message consists of a header and a sequence of objects.  An
2823	   NSLP message is one object within a GIMPS message.  The GIMPS header
2824	   has a specific format, described in more detail in Appendix C.2
2825	   below; the NSLP header format is common to all signaling applications
2826	   and includes simply a message type (which may be structured into a
2827	   type field and some processing flags, depending on the application).
2828	   Note that GIMPS provides the message length information and signaling
2829	   application identification.  There is no version information; if an
2830	   NSLP is extended so much that it stops being backwards compatible, a
2831	   new signaling application identifier is allocated.

2833	   Every object has the following general format:

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

2837	   o  Assignments for the Type field are common across all NSIS
2838	      protocols (i.e.  there is a single registry).  This is to
2839	      facilitate the sharing of common objects across different
2840	      signaling applications.  How to encode capability information
2841	      therefore has to be standardised across signaling applications;
2842	      this is still an open issue (see Section 8.11.

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

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

2853	   Error messages are identified by containing an error object (i.e.  an
2854	   object with Type='Error').  There should be a common error object
2855	   format, whose Value field includes a severity indication, an error
2856	   code, and optionally additional error-specific information.  Again,
2857	   the error code space is common across all protocols.

2859	C.2  The GIMPS Common Header

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

2867	    0                   1                   2                   3
2868	    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
2869	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2870	   |    Version    |  GIMPS hops   |        Number of TLVs         |
2871	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2872	   |   Signalling Application ID   |D|R|         Reserved          |
2873	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2875	   The flags are:
2876	   D - Direction (Set for "Upstream", Unset for "Downstream")
2877	   R - Response requested

2879	C.3  GIMPS TLV Objects

2881	C.3.1  Standard Object Header

2883	   Each object begins with a fixed header giving the object type and
2884	   object length.  See Section 8.11 for a discussion of extensibility
2885	   issues for object encoding.

2887	    0                   1                   2                   3
2888	    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
2889	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2890	   |             Type              |            Length             |
2891	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2897	C.3.2  Message-Routing-Information
2898	   Type: Message-Routing-Information

2900	   Length: Variable (depends on message routing method)

2902	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2903	   | Message-Routing-Method        |                               |
2904	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
2905	   //     Method-specific addressing information (variable)       //
2906	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2911	                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2912	                                   |IP-Ver |P|T|F|S|O|    Reserved |
2913	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2914	   //                       Source Address                        //
2915	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2916	   //                      Destination Address                    //
2917	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2918	   | Source Prefix |  Dest Prefix  |   Protocol    | Traffic Class |
2919	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2920	   :       Reserved        :              Flow Label               :
2921	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2922	   :                              SPI                              :
2923	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2924	   :          Source Port          :       Destination Port        :
2925	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2927	   The flags are:
2928	   P - Protocol
2929	   T - Traffic Class
2930	   F - Flow Label
2931	   S - SPI
2932	   O - Source/Destination Ports

2934	C.3.3  Session Identification

2936	   Type: Session-Identification

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

2940	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2941	   |                                                               |
2942	   +                                                               +
2943	   |                                                               |
2944	   +                          Session ID                           +
2945	   |                                                               |
2946	   +                                                               +
2947	   |                                                               |
2948	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2950	C.3.4  Node Addressing

2952	   Type: Node-Addressing

2954	   Length: Variable (depends on detailed format and what optional fields
2955	      are present)

2957	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2958	   |                                                               |
2959	   //                       Node Addressing                       //
2960	   |                                                               |
2961	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2963	C.3.5  Query Cookie

2965	   Type: Query-Cookie

2967	   Length: Variable (selected by querying node)

2969	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2970	   |                                                               |
2971	   //                        Query Cookie                         //
2972	   |                                                               |
2973	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2975	C.3.6  Responder Cookie

2977	   Type: Responder-Cookie

2979	   Length: Variable (selected by querying node)

2981	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2982	   |                                                               |
2983	   //                      Responder Cookie                       //
2984	   |                                                               |
2985	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2987	C.3.7  Lifetime

2989	   Type: Lifetime

2991	   Length: Fixed - 1 32-bit word

2993	   Value: Routing state lifetime in seconds

2995	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2996	   |                           Lifetime                            |
2997	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2999	C.3.8  NSLP Data

3001	   Type: NSLP-Data

3003	   Length: Variable (depends on NSLP)

3005	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3006	   |                                                               |
3007	   //                          NSLP Data                          //
3008	   |                                                               |
3009	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3011	Appendix D.  API between GIMPS and NSLP

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

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

3022	   Conceptually the API has similarities to the UDP sockets API,
3023	   particularly that for unconnected UDP sockets.  An extension for an
3024	   API like that for UDP connected sockets could be considered.  In this
3025	   case, for example, the only information needed in a SendMessage
3026	   primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
3027	   (which can be null).  Other information which was persistent for a
3028	   group of messages could be configured once for the socket.

3030	D.1  SendMessage

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

3035	   SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
3036	                 NSLP-Id, Session-ID,
3037	                 MRI, Direction, SII-Handle,
3038	                 Transfer-Attributes, Timeout, IP-TTL )

3040	   NSLP-Data: The NSLP message itself.

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

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

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

3051	   Session-ID: The NSIS session identifier.

3053	   MRI: Message routing information for use by GIMPS in determining the
3054	      correct next GIMPS hop for this message.  It contains, for
3055	      example, the flow source/destination addresses and the type of
3056	      routing to use for the signalling message.

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

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

3067	   Transfer-Attributes: Reliability, security, priority etc.  attributes
3068	      to be used for sending this particular message.  A value
3069	      indicating "default" or "don't care" may be given.

3071	   Timeout: Length of time GIMPS should attempt to send this message
3072	      before indicating an error.  A value indicating "default" or
3073	      "don't care" may be given.

3075	   IP-TTL: The value of the IP TTL that should be used when sending this
3076	      message.  A value indicating "default" or "don't care" may be
3077	      given.

3079	D.2  RecvMessage

3081	   This primtive is passed from GIMPS to an NSLP.  It is used whenever
3082	   GIMPS receives a message.

3084	   RecvMessage ( [NSLP-Data, NSLP-Data-Size,]
3085	                 NSLP-Id, Session-ID,
3086	                 MRI, Direction, SII-Handle,
3087	                 Transfer-Attributes,
3088	                 IP-TTL, Original-TTL )

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

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

3094	   NTLP-Message-Handle: A handle for this message, that can be used
3095	      later by the NSLP to reference it in a MessageReceived primitive.

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

3099	   Session-ID: The NSIS session identifier.

3101	   MRI: Message routing information that was used by GIMPS in forwarding
3102	      this message.  It contains, for example, the flow source/
3103	      destination addresses and the type of routing to used for the
3104	      signalling message.

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

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

3113	   Transfer-Attributes: Reliability, security, priority, etc.
3114	      attributes that were used for this particular message.

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

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

3122	D.3  MessageReceived

3124	   This primitive is passed from an NSLP to GIMPS.  It is used after a
3125	   RecvMessage primitive has been passed from GIMPS to an NSLP to inform
3126	   GIMPS whether the NSLP wishes GIMPS to retain state.

3128	   MessageReceived ( NTLP-Message-Handle, Retain-State )

3130	   NTLP-Message-Handle: A handle on a message, previously supplied by
3131	      GIMPS in a RecvMessage primitive.

3133	   RetainState: A value indicating whether or not the NSLP wishes GIMPS
3134	      to retain path state.

3136	D.4  MessageDeliveryError

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

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

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

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

3150	D.5  NetworkNotification

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

3155	   NetworkNotification ( MRI, Network-Notification-Type )

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

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

3164	D.6  SecurityProtocolAttributesRequest

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

3171	   SecurityProtocolAttributesRequest ( Peer-Info, Security-Protocol, Request-Type )

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

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

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

3181	D.7  SetStateLifetime

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

3188	   SetStateLifetime ( MRI, Direction, State-Lifetime )

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

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

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

3200	Intellectual Property Statement

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

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

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

3224	Disclaimer of Validity

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

3234	Copyright Statement

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

3240	Acknowledgment

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