idnits 2.17.1 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

  == Line 800 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 (July 19, 2004) is 7220 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 222

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

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

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

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

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

  == Outdated reference: A later version (-25) exists of
     draft-ietf-nsis-nslp-natfw-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-03

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


     Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 15 comments
     (--).

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

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


2	Next Steps in Signaling                                   H. Schulzrinne
3	Internet-Draft                                               Columbia U.
4	Expires: January 17, 2005                                     R. Hancock
5	                                                             Siemens/RMR
6	                                                           July 19, 2004

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

11	Status of this Memo

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

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

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

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

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

36	   This Internet-Draft will expire on January 17, 2005.

38	Copyright Notice

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

42	Abstract

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

57	Table of Contents

59	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
60	     1.1  Restrictions on Scope  . . . . . . . . . . . . . . . . . .   5
61	   2.   Requirements Notation and Terminology  . . . . . . . . . . .   6
62	   3.   Design Methodology . . . . . . . . . . . . . . . . . . . . .   8
63	     3.1  Overall Approach . . . . . . . . . . . . . . . . . . . . .   8
64	     3.2  Design Attributes  . . . . . . . . . . . . . . . . . . . .  10
65	     3.3  Example of Operation . . . . . . . . . . . . . . . . . . .  12
66	   4.   GIMPS Processing Overview  . . . . . . . . . . . . . . . . .  15
67	     4.1  GIMPS Service Interface  . . . . . . . . . . . . . . . . .  15
68	     4.2  GIMPS State  . . . . . . . . . . . . . . . . . . . . . . .  16
69	     4.3  Basic Message Processing . . . . . . . . . . . . . . . . .  18
70	     4.4  Routing State and Messaging Association Maintenance  . . .  23
71	   5.   Message Formats and Encapsulations . . . . . . . . . . . . .  29
72	     5.1  GIMPS Messages . . . . . . . . . . . . . . . . . . . . . .  29
73	     5.2  Information Elements . . . . . . . . . . . . . . . . . . .  30
74	     5.3  Encapsulation in Datagram Mode . . . . . . . . . . . . . .  33
75	     5.4  Encapsulation in Connection Mode . . . . . . . . . . . . .  34
76	   6.   Advanced Protocol Features . . . . . . . . . . . . . . . . .  37
77	     6.1  Route Changes and Local Repair . . . . . . . . . . . . . .  37
78	     6.2  Policy-Based Forwarding and Flow Wildcarding . . . . . . .  43
79	     6.3  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  43
80	     6.4  Interaction with IP Tunnelling . . . . . . . . . . . . . .  45
81	     6.5  IPv4-IPv6 Transition and Interworking  . . . . . . . . . .  46
82	     6.6  Messaging Association Protocol Negotiation . . . . . . . .  47
83	   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  49
84	     7.1  Message Confidentiality and Integrity  . . . . . . . . . .  49
85	     7.2  Peer Node Authentication . . . . . . . . . . . . . . . . .  50
86	     7.3  Routing State Integrity  . . . . . . . . . . . . . . . . .  50
87	     7.4  Denial of Service Prevention . . . . . . . . . . . . . . .  52
88	   8.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  54
89	     8.1  Protocol Naming  . . . . . . . . . . . . . . . . . . . . .  54
90	     8.2  General IP Layer Issues  . . . . . . . . . . . . . . . . .  54
91	     8.3  Encapsulation and Addressing for Datagram Mode . . . . . .  55
92	     8.4  Intermediate Node Bypass and Router Alert Values . . . . .  56
93	     8.5  Messaging Association Flexibility  . . . . . . . . . . . .  57
94	     8.6  Messaging Association Setup Message Sequences  . . . . . .  58
95	     8.7  GIMPS Support for Message Scoping  . . . . . . . . . . . .  59
96	     8.8  Additional Discovery Mechanisms  . . . . . . . . . . . . .  59
97	     8.9  Alternative Message Routing Requirements . . . . . . . . .  60
98	     8.10   Congestion Control in Datagram Mode  . . . . . . . . . .  61
99	     8.11   Message Format Issues  . . . . . . . . . . . . . . . . .  61
100	     8.12   Inter-Layer Security Coordination  . . . . . . . . . . .  62
101	     8.13   Protocol Design Details  . . . . . . . . . . . . . . . .  63
102	   9.   Change History . . . . . . . . . . . . . . . . . . . . . . .  64
103	     9.1  Changes In Version -03 . . . . . . . . . . . . . . . . . .  64
104	     9.2  Changes In Version -02 . . . . . . . . . . . . . . . . . .  64
105	     9.3  Changes In Version -01 . . . . . . . . . . . . . . . . . .  66
106	   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  68
107	   10.1   Normative References . . . . . . . . . . . . . . . . . . .  68
108	   10.2   Informative References . . . . . . . . . . . . . . . . . .  68
109	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  70
110	   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  71
111	   B.   Example Message Routing State Table  . . . . . . . . . . . .  72
112	   C.   Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . .  73
113	     C.1  General NSIS Formatting Guidelines . . . . . . . . . . . .  73
114	     C.2  The GIMPS Common Header  . . . . . . . . . . . . . . . . .  74
115	     C.3  GIMPS TLV Objects  . . . . . . . . . . . . . . . . . . . .  74
116	   D.   API between GIMPS and NSLP . . . . . . . . . . . . . . . . .  80
117	     D.1  SendMessage  . . . . . . . . . . . . . . . . . . . . . . .  80
118	     D.2  RecvMessage  . . . . . . . . . . . . . . . . . . . . . . .  81
119	     D.3  MessageReceived  . . . . . . . . . . . . . . . . . . . . .  82
120	     D.4  MessageDeliveryError . . . . . . . . . . . . . . . . . . .  82
121	     D.5  NetworkNotification  . . . . . . . . . . . . . . . . . . .  83
122	     D.6  SecurityProtocolAttributesRequest  . . . . . . . . . . . .  83
123	     D.7  SetStateLifetime . . . . . . . . . . . . . . . . . . . . .  83
124	        Intellectual Property and Copyright Statements . . . . . . .  85

126	1.  Introduction

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

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

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

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

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

174	1.1  Restrictions on Scope

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

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

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

192	2.  Requirements Notation and Terminology

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

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

202	   Source                GIMPS (adjacent) peer nodes         Destination

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

217	                  >>>>>>>>>>>>>>>>>  =  Downstream direction
218	                  <<<<<<<<<<<<<<<<<  =  Upstream direction

220	                      Figure 1: Basic Terminology

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

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

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

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

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

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

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

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

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

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

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

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

278	3.  Design Methodology

280	3.1  Overall Approach

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

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

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

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

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

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

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

325	   GIMPS offers two modes of transport operation:

327	   Datagram mode: for small, infrequent messages with modest delay
328	      constraints; and

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

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

373	           Figure 2: Protocol Stacks for Signaling Transport

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

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

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

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

414	3.2  Design Attributes

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

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

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

429	   Efficient: Signaling often occurs before an application such as an IP
430	      telephone conversation can commence, so that any signaling delay
431	      becomes noticeable to the application.  Signaling delays are
432	      incurred by the delay in finding signaling nodes along the path
433	      (peer discovery), in retransmitting lost signaling messages and in
434	      setting up security associations between nodes, among other
435	      factors.  GIMPS attempts to minimise these delays by several
436	      mechanisms, such as the use of high performance transport
437	      protocols to circumvent message loss, and the re-use of messaging
438	      associations to avoid setup latency.  If explicit discovery is
439	      needed it is a lightweight process which only probes local
440	      topology, and GIMPS also allows it to be bypassed completely for
441	      downstream datagram mode messages.

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

451	   Transport neutral: The GIMPS design can exploit any message or
452	      stream-oriented transport layer, including UDP, DCCP, TCP and
453	      SCTP.  Messages sent over protocols that do not offer a native
454	      fragmentation service, such as UDP or DCCP, are strictly limited
455	      in size to avoid loss-amplification; in the case of UDP, they must
456	      also be limited in rate to avoid network congestion.

458	   Proxy support: The end systems in a session may not be capable of
459	      handling either the signaling transport or the application and may
460	      instead rely on proxies to initiate and terminate signaling
461	      sessions.  Proxy support is limited to nodes that are actually on
462	      the data path (for example, access routers for stub networks);
463	      signaling from a 3rd party node not associated with the data path
464	      is not considered.  GIMPS decouples the operation of the messaging
465	      functions from the flow source and destination addresses, treating
466	      these primarily as data.

468	   Scaleable: As will be discussed in Section 4.4, up to one messaging
469	      association is generally kept for each adjacent GIMPS peer and
470	      thus association state scales better than the number of sessions.
471	      (Many peers may not have association state at all, if there are no
472	      messages for sessions visiting those nodes that warrant such
473	      treatment.) Messaging associations are managed based on policy at
474	      each node, depending on trade-offs between fast peer-to-peer
475	      communication and state overhead.  Messaging association state can
476	      be removed immediately after the last signaling session to a
477	      particular next-hop is removed, after some delay to wait for new
478	      sessions, or only if resource demands warrant it.

480	3.3  Example of Operation

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

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

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

502	   2.  The message payload is passed to the GIMPS layer in GN1, along
503	       with a definition of the flow and description of the message
504	       transfer attributes {downstream, unsecured, unreliable}.  GIMPS
505	       determines that this particular message does not require
506	       fragmentation and that it has no knowledge of the next peer for
507	       this flow and signaling application; however, it also determines
508	       that this application is likely to require secured upstream and
509	       downstream transport of large messages in the future.  This
510	       determination is a function of node-local policy, and some
511	       options for how it may be communicated between NSLP and GIMPS
512	       implementations within a node are indicated in Appendix D.

514	   3.  GN1 therefore constructs a UDP datagram with the signaling
515	       application payload, and additional payloads at the GIMPS level
516	       to be used to initiate the possible setup of a messaging
517	       association.  This datagram is injected into the network,
518	       addressed towards the flow destination and with a Router Alert
519	       Option included.

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

529	   5.  The message is finally intercepted at GN2.  The GIMPS layer
530	       identifies that the message is relevant to a local signaling
531	       application, and passes the signaling application payload and
532	       flow description upwards to it.  From there, the signaling
533	       application in GN2 can continue to process this message as in GN1
534	       (compare step 1), and this will eventually result in the message
535	       reaching the flow receiver.

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

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

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

554	   7.  Eventually, another signaling application message works its way
555	       upstream from the receiver to GN2.  This message contains a
556	       description of the actual resources requested, along with
557	       authorisation and other security information.  The signaling
558	       application in GN2 passes this payload to the GIMPS level, along
559	       with the flow definition and transfer attributes {upstream,
560	       secured, reliable}.

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

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

575	   It should be understood that many of these details of GIMPS
576	   operations can be varied, either by local policy or according to
577	   signaling application requirements, and they are also subject to
578	   development and refinement as the protocol design proceeds.  The
579	   authoritative details are contained in the remainder of this
580	   document.

582	4.  GIMPS Processing Overview

584	   This section defines the basic structure and operation of GIMPS.  It
585	   is divided into four parts.  Section 4.1 describes the way in which
586	   GIMPS interacts with (local) signaling applications in the form of an
587	   abstract service interface, with further information on the message
588	   transfer attributes that a signaling application may specify.
589	   Section 4.2 gives an overview of the per-flow and per-peer state that
590	   GIMPS maintains for the purpose of transferring messages.  Section
591	   4.3 describes how messages are processed in the case where any
592	   necessary messaging associations and associated routing state already
593	   exist; this includes the simple scenario of pure datagram mode
594	   operation, where no messaging associations are necessary in the first
595	   place (equivalent to the transport functionality of base RSVP as
596	   defined in [9]).  Finally, Section 4.4 describes how routing state is
597	   maintained and how messaging associations are initiated and
598	   terminated.

600	4.1  GIMPS Service Interface

602	   This section defines the service interface that GIMPS presents to
603	   signaling applications in terms of abstract functional properties of
604	   the message transfer.  Note that the same service interface is
605	   presented at every GIMPS node; however, applications may invoke it
606	   differently at different node (e.g.  depending on local policy).  In
607	   addition, the service interface is defined independently of any
608	   specific transport protocol, or even the distinction between datagram
609	   and connection mode.  The initial version of this specification
610	   defines how to support the service interface using a connection mode
611	   based on TCP; if additional transport protocol support is added, this
612	   will support the same interface and so be invisible to applications
613	   (except as a possible performance improvement).

615	4.1.1  Message Handling

617	   Fundamentally, GIMPS provides a simple message-by-message tranfer
618	   service for use by signaling applications: individual messages are
619	   sent, and individual messages are received.  Messages consist of a
620	   payload, and control information expressing the application's
621	   requirements about how the message should be routed.  Additional
622	   message transfer attributes control the specific transport and
623	   security properties that the signaling application desires for the
624	   message.

626	   The distinction between GIMPS connection and datagram modes is not
627	   visible at the service interface.  In addition, the invocation of
628	   GIMPS functionality to handle fragmentation and reassembly, bundling
629	   together of small messages (for efficiency), and congestion control
630	   are not directly visible at the service interface; GIMPS will take
631	   whatever action is necessary based on other properties of the
632	   messages and local node state.

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

641	4.1.2  Message Transfer Attributes

643	   The abstract API presented in Appendix D allows the signaling
644	   application to define message transfer attributes which influence
645	   some aspects of GIMPS message processing.  Those attributes are
646	   defined here.

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

656	   Priority: This attribute may have a range of locally defined values,
657	      and may be used to influence the sequence in which messages leave
658	      a node.  Any priority mechanism must respect the ordering
659	      requirements for reliable messages within a session, and priority
660	      values are not carried in the protocol or available at the
661	      signaling peer or intermediate nodes.

663	   Security: This attribute defines the security properties that the
664	      signaling application requires for the message, including the type
665	      of protection and identity information about the peer.  Details
666	      are for further study (see Section 8.12).

668	4.2  GIMPS State

670	4.2.1  Message Routing State

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

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

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

687	   Session Identification (SID): This is a cryptographically random and
688	      (probabilistically) globally unique identifier of the application
689	      layer session that is using the flow.  For a given flow, different
690	      signaling applications may or may not use the same session
691	      identifier.  Often there will only be one flow for a given
692	      session, but in mobility/multihoming scenarios there may be more
693	      than one and they may be differently routed.

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

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

703	   Upstream peer: the adjacent peer closer to the flow source.  This
704	      could be an IP address (learned from previous signaling) or a
705	      pointer to a messaging association.  It could also be null, if
706	      this node is the flow sender or this node is not storing reverse
707	      routing state, or a special value to indicate that this node is
708	      the last upstream node (but not the sender).

710	   Downstream peer: the adjacent peer closer to the flow destination.
711	      This could be a pointer to a messaging association, or it could be
712	      null, if this node is the flow receiver or this node is only
713	      sending downstream datagram mode messages for this flow and
714	      signaling application, or a special value to indicate that this
715	      node is the last downstream node (but not the receiver).

717	   Note that both the upstream and downstream peer state may be null,
718	   and that the session identifier information is not actually required
719	   for message processing; in that case, no state information at all
720	   needs to be stored in the table.  Both items of peer identification
721	   state have associated timers for how long the identification can be
722	   considered accurate; when these timers expire, the peer
723	   identification (IP address or messaging association pointer) is
724	   purged if it has not been refreshed.  Message routing state is
725	   installed and refreshed by the exchange of specific GIMPS messages as
726	   described in Section 4.4.  For a given flow, a GIMPS node is
727	   responsible for scheduling the messages which refresh its own
728	   downstream peer state and allow its downstream peer to refresh its
729	   upstream peer state, and this should be done while GIMPS determines
730	   the signaling application is still active.  GIMPS may
731	   opportunistically synchronise these 'internal' refresh operations
732	   with those in the signaling application if it wishes.  An example of
733	   a routing state table for a simple scenario is given in Appendix B.

735	   Note also that the information is described as a table of flows, but
736	   that there is no implied constraint on how the information is stored.
737	   For example, in a network using pure destination address routing
738	   (without load sharing or any form of policy-based forwarding), the
739	   downstream peer information might be possible to store in an
740	   aggregated form in the same manner as the IP forwarding table.  In
741	   addition, many of the per-flow entries may point to the same per-peer
742	   state (e.g.  the same messaging association) if the flows go through
743	   the same adjacent peer.  However, in general, and especially if GIMPS
744	   peers are several IP hops away, there is no way to identify the
745	   correct downstream peer for a flow and signaling application from the
746	   local forwarding table using prefix matching, and the same applies
747	   always to upstream peer state because of the possibility of
748	   asymmetric routing.  Per-flow routing state has to be stored, just as
749	   for RSVP [9].

751	4.2.2  Messaging Association State

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

759	   o  messages pending transmission while an association is being
760	      established;

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

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

769	4.3  Basic Message Processing

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

781	       +---------------------------------------------------------+
782	       |        >>  Signaling Application Processing   >>        |
783	       |                                                         |
784	       +--------^---------------------------------------V--------+
785	                ^                                       V
786	                ^             NSLP Payloads             V
787	                ^                                       V
788	       +--------^---------------------------------------V--------+
789	       |                    >>    GIMPS   >>                     |
790	       |  ^           ^  ^     Processing      V  V           V  |
791	       +--x-----------u--d---------------------d--u-----------x--+
792	          x           u  d                     d  u           x
793	          x           u  d>>>>>>>>>>>>>>>>>>>>>d  u           x
794	          x           u  d      Bypass at      d  u           x
795	       +--x-----+  +--u--d--+  GIMPS level  +--d--u--+  +-----x--+
796	       | C-mode |  | D-mode |               | D-mode |  | C-mode |
797	       |Handling|  |Handling|               |Handling|  |Handling|
798	       +--x-----+  +--u--d--+               +--d--u--+  +-----x--+
799	          x          u   d                     d   u          x
800	          x    uuuuuu    d>>>>>>>>>>>>>>>>>>>>>d    uuuuuu    x
801	          x   u          d      Bypass at      d          u   x
802	       +--x--u--+  +-----d--+    router     +--d-----+  +--u--x--+
803	       |IP Host |  |  RAO   |  alert level  |  RAO   |  |IP Host |
804	       |Handling|  |Handling|               |Handling|  |Handling|
805	       +--x--u--+  +-----d--+               +--d-----+  +--u--x--+
806	          x  u           d                     d           u  x
807	       +--x--u-----------d--+               +--d-----------u--x--+
808	       |      IP Layer      |               |      IP Layer      |
809	       |   (Receive Side)   |               |  (Transmit Side)   |
810	       +--x--u-----------d--+               +--d-----------u--x--+
811	          x  u           d                     d           u  x
812	          x  u           d                     d           u  x
813	          x  u           d                     d           u  x

815	            uuuuuuuuuuuuuu = upstream datagram mode messages
816	            dddddddddddddd = downstream datagram mode messages
817	            xxxxxxxxxxxxxx = connection mode messages
818	                       RAO = Router Alert Option

820	              Figure 3: Message Paths through a GIMPS Node

822	   Note that the same messages are used for maintaining internal GIMPS
823	   state and carrying signaling application payloads.  The state
824	   maintenance takes place as a result of processing specific GIMPS
825	   payloads in these messages.  The processing of these payloads is the
826	   subject of Section 4.4.

828	4.3.1  Message Reception

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

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

841	   Reception in datagram mode depends on the message direction.
842	   Upstream messages (from a downstream peer) will arrive UDP
843	   encapsulated and addressed directly to the receiving signaling node.
844	   Each datagram contains a single complete message which is passed to
845	   the GIMPS layer for further processing, just as in the connection
846	   mode case.

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

855	4.3.2  Local Processing

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

862	   One GIMPS-internal payload which is carried in each message and
863	   requires processing is the GIMPS hop count.  This is decremented on
864	   input processing, and checked to be greater than zero on output
865	   processing.  The primary purpose of the GIMPS hop count is to prevent
866	   message looping.

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

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

878	4.3.3  Message Transmission

880	   When a message is available for transmission, GIMPS uses internal
881	   policy and the stored routing state to determine how to handle it.
882	   The following processing applies equally to locally generated
883	   messages and messages forwarded from within the GIMPS or signaling
884	   application levels.

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

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

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

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

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

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

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

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

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

927	4.3.4  Bypass Forwarding

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

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

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

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

950	   In all cases, the role of GIMPS is to forward the message essentially
951	   unchanged.  However, a GIMPS implementation must ensure that the IP
952	   TTL field and GIMPS hop count are managed correctly to prevent
953	   message looping, and this should be done consistently independently
954	   of whether the processing (e.g.  for case (1)) takes place on the
955	   fast path or in GIMPS-specific code.  The rules are that in cases (1)
956	   and (2), the IP TTL is decremented just as if the message was a
957	   normal IP forwarded packet; in cases (2) and (3) the GIMPS hop count
958	   is decremented as in the case of normal input processing.  These
959	   rules are summarised in the following table:

961	   +-------------+-------------+-------------------+-------------------+
962	   |  Match RAO? |    Match    |  IP TTL Handling  |    GHC Handling   |
963	   |             |   NSLPID?   |                   |                   |
964	   +-------------+-------------+-------------------+-------------------+
965	   |      No     | N/A (NSLPID |     Decrement;    |       Ignore      |
966	   |             |     not     |  forward message  |                   |
967	   |             |  examined)  |                   |                   |
968	   |             |             |                   |                   |
969	   |     Yes     |      No     |     Decrement;    |     Decrement     |
970	   |             |             |  forward message  |                   |
971	   |             |             |                   |                   |
972	   |   Message   |      No     |       Reset       |   Decrement and   |
973	   |   directly  |             |                   |  forward at GIMPS |
974	   |  addressed  |             |                   |     level (not    |
975	   |             |             |                   |    possible in    |
976	   |             |             |                   |      current      |
977	   |             |             |                   |   specification)  |
978	   |             |             |                   |                   |
979	   |   Yes, or   |     Yes     | Locally delivered |     Decrement     |
980	   |   message   |             |                   |                   |
981	   |   directly  |             |                   |                   |
982	   |  addressed  |             |                   |                   |
983	   +-------------+-------------+-------------------+-------------------+

985	4.4  Routing State and Messaging Association Maintenance

987	   The main responsibility of the GIMPS layer is to manage the routing
988	   state and messaging associations which are used in the basic message
989	   processing described above.  Routing state is installed and
990	   maintained by datagram mode messages containing specific GIMPS
991	   payloads.  Messaging associations are dependent on the existence of
992	   routing state, but are actually set up by the normal procedures of
993	   the transport and security protocols that comprise the messaging
994	   association.  Timers control routing state and messaging association
995	   refresh and expiration.

997	   Broadly, there are two different cases for state installation and
998	   refresh:

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

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

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

1009	4.4.1  State Setup

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

1015	   The initial message in any routing state maintenance operation is a
1016	   downstream datagram mode message, sent from the querying node and
1017	   intercepted at the responding node.  This is encapsulated and
1018	   addressed just as in the normal case; in particular, it has
1019	   addressing and other identifiers appropriate for the flow and
1020	   signaling application that state maintenance is being done for, and
1021	   it is allowed to contain an NSLP payload.  Processing at the querying
1022	   and responding nodes is also essentially the same.  However, the
1023	   querying node includes additional payloads: its own address
1024	   information, a proposal for possible messaging association protocol
1025	   stacks, and optionally 'Discover-Query' information, including a
1026	   Response Request flag and a Query Cookie.  This message is informally
1027	   referred to as a 'GIMPS-query'.  The role of the cookies in this and
1028	   subsequent messages is to protect against certain denial of service
1029	   attacks.

1031	           +----------+              +----------+
1032	           | Querying |              |Responding|
1033	           |   Node   |              |   Node   |
1034	           +----------+              +----------+

1036	                      GIMPS-query
1037	                ---------------------->
1038	                Router Alert Option
1039	                MRI/SID/NSLPID           ...........
1040	                Q-Node Addressing        . Routing .
1041	                [Stack Proposal]         .  state  .  ^
1042	                [Query Cookie]           .installed.  |     Existing
1043	                [Response Request]       .   at    .  |    messaging
1044	                [NSLP Payload]           .R-node(1).  |   associations
1045	                                         ...........  |   can be used
1046	                    GIMPS-response                    |    from here
1047	   ...........  <----------------------               |     onwards
1048	   . Routing .  MRI/SID/NSLPID                        |
1049	   .  state  .  Query cookie                          |
1050	   .installed.  R-Node Addressing                     | ^
1051	   .   at    .            (D Mode only)               | |
1052	   . Q-node  .  [Stack Proposal]                      | |
1053	   ...........  [Responder Cookie]                    | |
1054	                [Response Request]                    | |     New
1055	                [NSLP Payload]                        | |  messaging
1056	                                                      | | associations
1057	                    GIMPS-confirm                     | |  can be set
1058	                ---------------------->               | | up from here
1059	                MRI/SID/NSLPID           ...........  | |   onwards
1060	                Responder Cookie         . Routing .  | |
1061	                Q-Node Addressing        .  state  .  | |
1062	                         (D Mode only)   .installed.  | |
1063	                [NSLP Payload]           .   at    .  | |
1064	                                         .R-node(2).  | |
1065	                                         ...........  | |

1067	               Figure 4: Message Sequence at State Setup

1069	   In the responding node, the GIMPS level processing of the
1070	   Discover-Query information triggers the generation of a
1071	   'GIMPS-response' message.  This is also a normally encapsulated and
1072	   addressed message with particular payloads, this time in the upstream
1073	   direction.  Again, it can contain an NSLP payload (possibly a
1074	   response to the NSLP payload in the initial message).  It includes
1075	   its own addressing information, a counter-proposal for messaging
1076	   association protocol stacks, and the Query Cookie, and optionally
1077	   'Discover-Response' information, including another Response Request
1078	   flag and a Responder Cookie.

1080	   The querying node installs the responder address as downstream peer
1081	   state information after verifying the Query Cookie in the
1082	   GIMPS-response.  The responding node can install the querying address
1083	   as upstream peer state information at two points in time:

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

1087	   2.  after a GIMPS-confirm message in the downstream direction
1088	       containing the Responder Cookie.

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

1095	   Setup of messaging associations begins when both downstream peer
1096	   addressing information is available and a new messaging association
1097	   is actually needed.  Setup of the messaging association always starts
1098	   from the upstream node, but the association itself can be used
1099	   equally in both directions.  The negotiation of what protocols to use
1100	   for the messaging association is controlled by the Stack Proposal and
1101	   Node-Addressing information exchanged, and the processing is outline
1102	   in Section 6.6.

1104	4.4.2  Association Re-use

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

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

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

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

1133	   Interface-Address: This is an IP address associated with the
1134	      interface through which the flow associated with the signalling is
1135	      routed.  This can be considered as a routable identifier through
1136	      which the signaling node can be reached.  Note that this will be
1137	      changed passing through NATs, and will also change if the outgoing
1138	      interface for a flow changes.

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

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

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

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

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

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

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

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

1181	4.4.3  Background Maintenance

1183	   Refresh and expiration of all types of state is controlled by timers.
1184	   State in the routing table has a per-flow, per-direction timer, which
1185	   expires after a routing state lifetime.  It is the responsibility of
1186	   the querying node to generate a GIMPS-query message, optionally with
1187	   a Discover-Query payload, before this timer expires, if it believes
1188	   that the flow is still active.  Receipt of the message at the
1189	   responding node will refresh upstream peer addressing state, and
1190	   receipt of a GIMPS-response at the querying node will refresh any
1191	   downstream peer addressing state if it exists.  Note that nodes do
1192	   not control the refresh of upstream peer state themselves, they are
1193	   dependent on the upstream peer for this.

1195	   Messaging associations can be managed by either end.  Management
1196	   consists of tearing down unneeded associations.  Whether an
1197	   association is needed is a local policy decision, which could take
1198	   into account the cost of keeping the messaging association open, the
1199	   level of past activity on the association, and the likelihood of
1200	   future activity (e.g.  if there are flows still in place which might
1201	   generate messages that would use it).  Messaging associations can
1202	   always be set up on demand, and messaging association status is not
1203	   made directly visible outside the GIMPS layer.  Therefore, even if
1204	   GIMPS tears down and later re-establishes a messaging association,
1205	   signaling applications cannot distinguish this from the case where
1206	   the association is kept permanently open.  (To maintain the transport
1207	   semantics decribed in Section 4.1, GIMPS must close transport
1208	   connections carrying reliable messages gracefully or report an error
1209	   condition, and must not open a new association for a given session
1210	   and peer while messages on a previous association may still be
1211	   outstanding.)

1213	5.  Message Formats and Encapsulations

1215	5.1  GIMPS Messages

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

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

1228	   GIMPS-message: A message is either a datagram mode message or a
1229	   connection mode message.  GIMPS can detect which by the encapsulation
1230	   the message arrives over.

1232	       GIMPS-message = D-message / C-message

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

1238	       D-message = D-upstream-message / D-downstream-message

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

1245	       C-message = C-upstream-message / C-downstream-message

1247	   D-downstream-message: A downstream datagram mode message is used for
1248	   the GIMPS-query and GIMPS-confirm in the discovery procedure, and can
1249	   also be used simply for carrying NSLP data.  Note that the
1250	   Common-Header includes a flag to indicate whether an explicit
1251	   response is required.

1253	       D-downstream-message = Common-Header
1254	                              Message-Routing-Information
1255	                              Node-Addressing
1256	                              Session-Identification
1257	                              [ Stack-Proposal ]
1258	                              [ Query-Cookie / Responder-Cookie ]
1259	                              [ Routing-State-Lifetime ]
1260	                              [ NSLP-Data ]

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

1266	       D-upstream-message   = Common-Header
1267	                              Message-Routing-Information
1268	                              Node-Addressing
1269	                              Session-Identification
1270	                              [ Stack-Proposal ]
1271	                              [ Query-Cookie [ Responder-Cookie ] ]
1272	                              [ Routing-State-Lifetime ]
1273	                              [ NSLP-Data ]

1275	   C-downstream-message: A downstream connection mode message is used
1276	   primarily for carrying NSLP data, but can also be used for the
1277	   GIMPS-confirm during discovery.  Connection mode messages do not
1278	   carry node addressing, since this can be inferred from the messaging
1279	   association.

1281	       C-downstream-message = Common-Header
1282	                              Message-Routing-Information
1283	                              Session-Identification
1284	                              [ Responder-Cookie ]
1285	                              [ Routing-State-Lifetime ]
1286	                              [ NSLP-Data ]

1288	   C-upstream-message: An upstream connection mode message is used
1289	   primarily for carrying NSLP data, but can also be used for the
1290	   GIMPS-response during discovery (which is the only case where a
1291	   Stack-Proposal TLV can be included).

1293	       C-upstream-message   = Common-Header
1294	                              Message-Routing-Information
1295	                              Session-Identification
1296	                              [ Stack-Proposal ]
1297	                              [ Query-Cookie [ Responder-Cookie ] ]
1298	                              [ Routing-State-Lifetime ]
1299	                              [ NSLP-Data ]

1301	5.2  Information Elements

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

1309	5.2.1  The Common Header

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

1314	   Version: The version number of the GIMPS protocol.

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

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

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

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

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

1331	5.2.2  TLV Objects

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

1338	   These items are contained in each GIMPS message:

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

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

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

1354	       Flow-Identifier = network-layer-version
1355	                         source-address prefix-length
1356	                         destination-address prefix-length
1357	                         IP-protocol
1358	                         traffic-class
1359	                         [ flow-label ]
1360	                         [ ipsec-SPI / L4-ports]

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

1366	   Session-Identification (SID): The GIMPS session identifier is a long,
1367	      cryptographically random identifier chosen by the node which
1368	      begins the signaling exchange (the signaling application at the
1369	      node may specify it explicitly, or leave it up to GIMPS to select
1370	      a value).  The length is open, but 128 bits should be more than
1371	      sufficient to make the probability of collisions orders of
1372	      magnitude lower than other failure reasons.  The session
1373	      identifier should be considered immutable end-to-end along the
1374	      flow path (GIMPS never changes it, and signaling applications
1375	      should propagate it unchanged on messages for the same session).

1377	   The following items are optional:

1379	   Node addressing: This includes an IP address at which the GIMPS node
1380	      originating the message can be reached which will be used to fill
1381	      in peer routing state, and an opaque identifier for matching
1382	      existing associations, as discussed in Section 4.4.2.  The address
1383	      can also be used in route change handling, see Section 6.1, and
1384	      port and other information relevant to the messaging association
1385	      protocols is also included.

1387	       Node-Addressing = peer-identity
1388	                         interface-address
1389	                         *higher-layer-addressing

1391	       There is a higher-layer-addressing field for each protocol which
1392	      may be a candidate for use in the messaging association and for
1393	      which addressing information (e.g.  a port number) is required.
1394	      These protocols are identified with the same tags as they appear
1395	      with in the security protocol stack proposal (see below).  This
1396	      field must be considered mutable to allow for NAT traversal.  The
1397	      level of flexibility required in this field is discussed in
1398	      Section 8.5.

1400	   Stack Proposal: This field contains information about which
1401	      combinations of transport and security protocols are proposed for
1402	      use in messaging associations.  This field must be considered
1403	      immutable between GIMPS peers; see Section 6.6 for further
1404	      discussion of the details.

1406	       Stack-Proposal = *stack-profile

1408	       stack-profile = *protocol-layer

1410	       Each protocol-layer field identifies a protocol with a unique
1411	      tag; any address-related (mutable) information associated with the
1412	      protocol will be carried in a higher-layer-protocol field in the
1413	      Node-Addressing TLV (see above).

1415	   Query-Cookie/Responder-Cookie: A query-cookie is optional in a
1416	      GIMPS-query message and if present must be echoed in a
1417	      GIMPS-response; a response-cookie is optional in a GIMPS-response
1418	      message, and if present must be echoed in the following downstream
1419	      message.  Cookies are variable length (chosen by the cookie
1420	      generator) and need to be designed so that a node can determine
1421	      the validity of a cookie without keeping state.  A future version
1422	      of this specification will include references to techniques for
1423	      generating such cookies.

1425	   Routing-State-Lifetime: The lifetime of GIMPS routing state in the
1426	      absence of refreshes, measured in seconds.  Defaults to 30
1427	      seconds.

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

1432	5.3  Encapsulation in Datagram Mode

1434	   Encapsulation in datagram mode is simple.  The complete set of GIMPS
1435	   payloads for a single message is concatenated together with the
1436	   common header, and placed in the data field of a UDP datagram.  UDP
1437	   checksums should be enabled.  Upstream messages are directly
1438	   addressed to the adjacent peer.  Downstream messages are addressed
1439	   using information from the Message-Routing-Information and
1440	   encapsulated with a Router Alert Option.  Open issues about
1441	   alternative encapsulations, addressing possibilities, and router
1442	   alert option value-field setting are discussed in Section 8.2,
1443	   Section 8.3 and Section 8.4 respectively.

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

1455	   For the case of basic path-coupled signaling where the MRI
1456	   information is the Flow Identifier, it is vital that the D-mode
1457	   message truly mimics the actual data flow, since this is the basis of
1458	   how the signaling message is attached to the data path.  To this end,
1459	   GIMPS may set the traffic class and (for IPv6) flow label to match
1460	   the values in the Flow-Identifier if this would be needed to ensure
1461	   correct routing.  Similar considerations may apply to other message
1462	   routing methods if defined.

1464	5.4  Encapsulation in Connection Mode

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

1471	5.4.1  Choice of Transport Protocol

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

1478	   SCTP [6] satisfies all requirements.

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

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

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

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

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

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

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

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

1526	5.4.2  Encapsulation Format

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

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

1555	                Figure 5: Connection Mode Encapsulation

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

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

1570	6.  Advanced Protocol Features

1572	6.1  Route Changes and Local Repair

1574	6.1.1  Introduction

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

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

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

1602	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1603	               x  +--+        +--+        +--+  x      Initial
1604	              x  .|B1|_.......|C1|_.......|D1|   x     Configuration
1605	             x  . +--+.      .+--+.      .+--+\.  x
1606	            x  .       .    .      .    .       .  x
1607	    >>xxxxxx  .         .  .        .  .         .  xxxxxx>>
1608	         +-+ .           ..          ..           . +-+
1609	    .....|A|/            ..          ..            .|E|_....
1610	         +-+ .          .  .        .  .          . +-+
1611	              .        .    .      .    .        .
1612	               .      .      .    .      .      .
1613	                . +--+        +--+        +--+ .
1614	                 .|B2|_.......|C2|_.......|D2|/
1615	                  +--+        +--+        +--+

1617	                  +--+        +--+        +--+         Configuration
1618	                 .|B1|........|C1|........|D1|         after failure
1619	                . +--+       .+--+        +--+         of D1-E link
1620	               .      \.    .     \.    ./
1621	              .         .  .        .  .
1622	         +-+ .           ..          ..             +-+
1623	    .....|A|.            ..          ..            .|E|_....
1624	         +-+\.          .  .        .  .          . +-+
1625	    >>xxxxxx  .        .    .      .    .        .  xxxxxx>>
1626	            x  .      .      .    .      .      .  x
1627	             x  . +--+        +--+        +--+ .  x
1628	              x  .|B2|_.......|C2|_.......|D2|/  x
1629	               x  +--+        +--+        +--+  x
1630	                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

1634	               >>xxxxxxx>> = flow direction

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

1640	                      Figure 6: A Re-Routing Event

1642	6.1.2  Route Change Detection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1718	   +----------------------+----------------------+---------------------+
1719	   | Method               | Downstream           | Upstream            |
1720	   +----------------------+----------------------+---------------------+
1721	   | Local Trigger        | Discovers new        | Not applicable      |
1722	   |                      | downstream interface |                     |
1723	   |                      | (and peer if local)  |                     |
1724	   |                      |                      |                     |
1725	   | Extended Trigger     | Discovers new        | May determine that  |
1726	   |                      | downstream interface | route from upstream |
1727	   |                      | and may determine    | peer will have      |
1728	   |                      | new downstream peer  | changed             |
1729	   |                      |                      |                     |
1730	   | C-Mode Monitoring    | Provides hint that   | Provides hint that  |
1731	   |                      | change has occurred  | change has occurred |
1732	   |                      |                      |                     |
1733	   | Data Plane           | Not applicable       | NSLP informs GIMPS  |
1734	   | Monitoring           |                      | that a change may   |
1735	   |                      |                      | have occurred       |
1736	   |                      |                      |                     |
1737	   | D-Mode Probing       | Discovers changed    | Discovers changed   |
1738	   |                      | Node-Addressing in   | Node-Addressing in  |
1739	   |                      | GIMPS-response       | GIMPS-query         |
1740	   +----------------------+----------------------+---------------------+

1742	6.1.3  Local Repair

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

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

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

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

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

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

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

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

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

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

1798	6.1.4  Local Signaling Application State Removal

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

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

1821	6.1.5  Operation with Heterogeneous NSLPs

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

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

1841	6.2  Policy-Based Forwarding and Flow Wildcarding

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

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

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

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

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

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

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

1881	6.3  NAT Traversal

1883	   As already noted, GIMPS messages must carry packet addressing and
1884	   higher layer information as payload data in order to define the flow
1885	   signalled for.  (This applies to all GIMPS messages, regardless of
1886	   how they are encapsulated or which direction they are travelling in.)
1887	   At an addressing boundary the data flow packets will have their
1888	   headers translated; if the signaling payloads are not likewise
1889	   translated, the signaling messages will refer to incorrect (and
1890	   probably meaningless) flows after passing through the boundary.  In
1891	   addition, some GIMPS messages (those used in the discovery process)
1892	   carry addressing information about the GIMPS nodes themselves, and
1893	   this must also be processed appropriately when traversing a NAT.

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

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

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

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

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

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

1922	   6.  Forward the message with these new payloads.

1924	   The original Message-Routing-Information payload is retained in the
1925	   message, but encapsulated in the new TLV type.  Further information
1926	   can be added corresponding to the Node-Addressing payload, either the
1927	   original payload itself or, in the case of a GIMPS node that wished
1928	   to do topology hiding, opaque tokens (or it could be omitted
1929	   altogether).  In the case of a sequence of NATs, this part of the
1930	   NAT-Traversal object would become a list.  Note that a consequence of
1931	   this approach is that the routing state tables at the actual
1932	   signaling application peers (either side of the NAT) are no longer
1933	   directly compatible.  In particular, the values of
1934	   Message-Routing-Information are different, which is why the
1935	   unmodified MRI is propagated in the NAT-Traversal payload to allow
1936	   subsequent C-mode messages to be interpreted correctly..

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

1948	6.4  Interaction with IP Tunnelling

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

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

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

1982	6.5  IPv4-IPv6 Transition and Interworking

1984	   GIMPS itself is essentially IP version neutral (version dependencies
1985	   are isolated in the formats of the Message-Routing-Information and
1986	   Node-Addressing TLVs, and GIMPS also depends on the version
1987	   independence of the protocols that support messaging associations).
1988	   In mixed environments, GIMPS operation will be influenced by the IP
1989	   transition mechanisms in use.  This section provides a high level
1990	   overview of how GIMPS is affected, considering only the currently
1991	   predominant mechanisms.

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

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

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

2018	   Packet Translation: (Applicable to SIIT [5] and NAT-PT [13].) Some
2019	      transition mechanisms allow IPv4 and IPv6 nodes to communicate by
2020	      placing packet translators between them.  From the GIMPS
2021	      perspective, this should be treated essentially the same way as
2022	      any other NAT operation (e.g.  between 'public' and 'private'
2023	      addresses) as described in Section 6.3.  In other words, the
2024	      translating node needs to be GIMPS aware; it will run GIMPS with
2025	      IPv4 on some interfaces and with IPv6 on others, and will have to
2026	      translate the Message-Routing-Information payload between IPv4 and
2027	      IPv6 formats for flows which cross between the two.  The
2028	      translation rules for the fields in the payload (including e.g.
2029	      traffic class and flow label) are as defined in [5].

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

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

2051	6.6  Messaging Association Protocol Negotiation

2053	   A key attribute of GIMPS is that it is flexible in its ability to use
2054	   existing transport and security protocols.  Different transport
2055	   protocols may have performance attributes appropriate to different
2056	   environments; different security protocols may fit appropriately with
2057	   different authentication infrastructures.  Even if a single choice
2058	   for GIMPS could be agreed today, the need to support new protocols in
2059	   the future cannot be ruled out.  Therefore, some sort of protocol
2060	   negotiation capability is required.

2062	   The implicit requirements for protocol negotiation are as follows:

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

2067	   o  The negotiation should complete in 1 RTT.

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

2072	   o  At the same time, the message elements involved should allow NAT
2073	      traversal.

2075	   o  The set of possible protocols should be extensible.

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

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

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

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

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

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

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

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

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

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

2123	7.  Security Considerations

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

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

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

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

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

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

2166	7.1  Message Confidentiality and Integrity

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

2180	7.2  Peer Node Authentication

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

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

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

2211	7.3  Routing State Integrity

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

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

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

2240	   Upstream peer identification can be installed directly on receiving a
2241	   GIMPS-query message containing addressing information for the
2242	   upstream peer.  However, any node in the network could generate such
2243	   a message (indeed, almost any node in the network could be the
2244	   genuine upstream peer for a given flow).  To protect against this,
2245	   two strategies are possible:

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

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

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

2273	7.4  Denial of Service Prevention

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

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

2303	   There are at least three defenses against these attacks:

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

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

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

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

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

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

2344	8.  Open Issues

2346	8.1  Protocol Naming

2348	   Alternate names:
2349	   GIST: General Internet Signaling Transport
2350	   GIMPS: General Internet Messaging Protocol for Signaling
2351	   LUMPS: Lightweight Universal Messaging for Path associated Signaling

2353	   There is a danger of some ambiguity as to whether the protocol name
2354	   refers to the complete transport stack below the signaling
2355	   applications, or only to the additional protocol functionality above
2356	   the standard transport protocols (UDP, TCP etc.) The NSIS framework
2357	   uses the term NTLP for the first, but this specification uses the
2358	   GIST/variants names for the second (see Figure 2 in Section 3.1).  In
2359	   other words, this specification proposes to meet the requirements for
2360	   NTLP functionality by layering GIMPS/...  over existing standard
2361	   transport protocols.  It isn't clear if additional terminological
2362	   surgery is needed to make this clearer.

2364	8.2  General IP Layer Issues

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

2374	   The critical requirements for the encapsulation at this level are
2375	   that routers should be able to identify signaling packets for
2376	   processing, and that they should not mis-identify packets for
2377	   'normal' end-to-end user data flows as signaling packets.  The
2378	   current assumption is that UDP encapsulation can be used for such
2379	   messages, by allocating appropriate (new) value codes for the router
2380	   alert option (RAO) [1][4] to identify NSIS messages.  Specific open
2381	   issues about how to allocate such values are discussed in Section
2382	   8.4.

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

2393	8.3  Encapsulation and Addressing for Datagram Mode

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

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

2410	   Addressing for upstream datagram mode messages is simple: the IP
2411	   source address is the signaling source address, and the IP
2412	   destination address is the signaling destination address (compare
2413	   Figure 1).  For downstream datagram mode messages, the IP destination
2414	   address will be the flow destination address, but the IP source
2415	   address could be either of the flow source address or signaling
2416	   source address.  Some of the relative merits of these options are as
2417	   follows:

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

2427	   o  Conversely, using the signaling source address means that ICMP
2428	      error messages (specifically, unreachable port or address) will be
2429	      correctly delivered to the message originator, rather than being
2430	      sent back to the flow source.  Without seeing these messages, it
2431	      is very difficult for the querying node to recognise that it is
2432	      the last NSIS node on the path.  In addition, using the signaling
2433	      source address may make it possible to exchange messages through
2434	      GIMPS unaware NATs (although it isn't clear how useful the
2435	      resulting messages will be, see Section 6.3).

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

2444	8.4  Intermediate Node Bypass and Router Alert Values

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

2454	   There are two basic reasons why a GIMPS node might wish to ignore a
2455	   message:

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

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

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

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

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

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

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

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

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

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

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

2522	8.5  Messaging Association Flexibility

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

2528	   o  to allow different reliability characteristics;

2530	   o  to provide different levels of security protection or to have
2531	      security separation between different signaling streams;

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

2537	   It is possible to imagine essentially infinite flexibility in these
2538	   options, both in terms of how many possibilities are allowed and how
2539	   nodes signal their capabilities and preferences, without much
2540	   changing the overall GIMPS structure.  (The GIMPS-query and
2541	   GIMPS-response messages described in section Section 4.4 can be used
2542	   to exchange this information.) What is not clear is how much
2543	   flexibility is actually needed.

2545	8.6  Messaging Association Setup Message Sequences

2547	   The discussion of Section 4.4 assumes a simple fixed message
2548	   sequence, which we can picture as follows:

2550	   +---------------------------------+---------------------------------+
2551	   |            Direction            | Message                         |
2552	   +---------------------------------+---------------------------------+
2553	   |               --->              | GIMPS-query message             |
2554	   |                                 |                                 |
2555	   |               <---              | GIMPS-response message          |
2556	   |                                 |                                 |
2557	   |               ===>              | Querying node initiates         |
2558	   |                                 | messaging association setup     |
2559	   |                                 | messages                        |
2560	   |                                 |                                 |
2561	   |               <-->              | Signaling messages exchanged    |
2562	   +---------------------------------+---------------------------------+

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

2568	   +---------------------------------+---------------------------------+
2569	   |            Direction            | Message                         |
2570	   +---------------------------------+---------------------------------+
2571	   |               --->              | GIMPS-query message             |
2572	   |                                 |                                 |
2573	   |               <===              | Responding node initiates       |
2574	   |                                 | messaging association setup     |
2575	   |                                 | messages                        |
2576	   |                                 |                                 |
2577	   |               <-->              | Signaling messages exchanged    |
2578	   +---------------------------------+---------------------------------+

2580	   This saves a message but may be vulnerable to additional denial of
2581	   service attacks.

2583	   Another open area is how to manage the protocol exchanges that take
2584	   place in setting up the messaging association itself.  It is probably
2585	   an implementation matter to consider whether to carry out, for
2586	   example, the SCTP 4-way handshake only after IKE exchanges (for IPsec
2587	   SA initialisation) have completed, or whether these can be done
2588	   partly in parallel.  A more radical step is to carry the initial
2589	   request and response messages of both exchanges as payloads in the
2590	   GIMPS-query/response exchange, with the request message initially
2591	   formatted by the querying node with an unspecified destination IP
2592	   address.  This would require modifications to the protocol
2593	   implementations (especially at the querying node) similar to what is
2594	   needed for NAT traversal; it would have to be evaluated whether this
2595	   was worth the one or two round trip times that are saved.  Both this
2596	   technique and the "reverse connection" approach above can be
2597	   considered optimisations; given an appropriate negotiation procedure
2598	   in the base protocol as discussed in Section 6.6 they probably do not
2599	   need to be considered further for the initial version.

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

2613	8.7  GIMPS Support for Message Scoping

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

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

2629	8.8  Additional Discovery Mechanisms

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

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

2649	8.9  Alternative Message Routing Requirements

2651	   The initial assumption of GIMPS is that signaling messages are to be
2652	   routed identically to data flow messages.  For this case of
2653	   path-coupled signaling, the MRI and upstream/downstream flag (in the
2654	   Common-Header) define the flow and the relationship of the signaling
2655	   to it sufficiently for GIMPS to route its messages correctly.
2656	   However, some additional modes of routing signaling messages have
2657	   been identified:

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

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

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

2687	   o  Defining the format of the MRI for the new message routing method
2688	      type.

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

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

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

2698	8.10  Congestion Control in Datagram Mode

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

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

2718	8.11  Message Format Issues

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

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

2730	   Extensibility: For extensibility, it is useful to be able to mark
2731	      objects with some information about how they should be treated if
2732	      the receiving node does not implement them (e.g.  ignore or
2733	      reject).  Since the object space is shared between all protocols,
2734	      this marking has to be standardised across all the NSIS protocols.

2736	   Space in the common object header has been set aside for space for
2737	   extensibility flags or equivalent information.  So far, three
2738	   candidate flags have been identified.  In each case, the formal
2739	   details for how they should be handled must be defined by the
2740	   signaling application (for example, only the signaling application
2741	   specification can identify which messages count as 'refreshes' or
2742	   'responses' and so on).

2744	   Critical: If set on an object, a node which does not understand the
2745	      object must reject the entire message with an error.  Several
2746	      protocols (IKE, RSVP, IPv6) define the equivalent of a 'C' bit;
2747	      others (SIP) require all extensions to be either optional or to be
2748	      explicitly negotiated, in which case C is irrelevant.

2750	   Propagate: If set on an object, the object should be included in
2751	      corresponding messages forwarded further along the path.

2753	   Refresh: If set on an object, the object should be considered part of
2754	      local state.  In itself this is not interesting (since the
2755	      contents of the object will be ignored anyway); however, the
2756	      object can also be included in local state refresh or repair
2757	      operations.  Note that R implies P.

2759	8.12  Inter-Layer Security Coordination

2761	   GIMPS is able to provide channel security protection between adjacent
2762	   signaling application peers, and it is efficient if signaling
2763	   applications themselves can rely on this protection for their
2764	   messages.  Ideally, to enable a consistent security analysis of the
2765	   signaling application, the properties and mode of use of the
2766	   underlying security protocol would be analysed jointly with signaling
2767	   application itself; however, for layering reasons, the operation of
2768	   the security protocol itself must be largely hidden below the GIMPS
2769	   layer.

2771	   This presents a challenge, mainly for the GIMPS service interface
2772	   specification (Section 4.1), which ideally would be able to expose
2773	   the relevant properties of the security protocol in use to the
2774	   signaling application depending on it, including allowing the
2775	   application to take part in the protocol operation (e.g.  selecting
2776	   which identity to use and verifying the identity of the peer).
2777	   Currently, the description is limited to the identification of a
2778	   transfer attribute called 'Security' in Section 4.1.2; more detailed
2779	   design may require this attribute to be an object with non-trivial
2780	   processing capabilities, rather than simply an enumerated value.
2781	   Details are for further study.

2783	8.13  Protocol Design Details

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

2790	   o  Receiver initiated signaling applications need to have reverse
2791	      path state set up in the network, before the signaling application
2792	      itself can originate any messages.  Should this be done by GIMPS
2793	      carrying out the discovery for the specific signaling application
2794	      (which requires the flow sender to know what signaling
2795	      applications are going to be used), or should the discovery
2796	      attempt to find every GIMPS node and the signaling applications
2797	      they support?

2799	9.  Change History

2801	9.1  Changes In Version -03

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

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

2813	   2.  Added a new open issue identifying where the interaction between
2814	       the security properties of GIMPS and the security requirements of
2815	       signaling applications should be identified (Section 8.12).

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

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

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

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

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

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

2839	   9.  Expanded the open issue discussion in Section 8.11 to include an
2840	       outline set of extensibility flags.

2842	9.2  Changes In Version -02

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

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

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

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

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

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

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

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

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

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

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

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

2901	9.3  Changes In Version -01

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

2916	   The full set of changes is as follows:

2918	   1.  Added a worked example in Section 3.3.

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

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

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

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

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

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

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

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

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

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

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

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

2975	   14.  Added this change history.

2977	10.  References

2979	10.1  Normative References

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

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

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

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

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

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

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

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

3005	10.2  Informative References

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

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

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

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

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

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

3026	         Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
3027	         2961, April 2001.

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

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

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

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

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

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

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

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

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

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

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

3069	   [26]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
3070	         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in
3071	         progress), June 2004.

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

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

3080	Authors' Addresses

3082	   Henning Schulzrinne
3083	   Columbia University
3084	   Department of Computer Science
3085	   450 Computer Science Building
3086	   New York, NY  10027
3087	   US

3089	   Phone: +1 212 939 7042
3090	   EMail: hgs+nsis@cs.columbia.edu
3091	   URI:   http://www.cs.columbia.edu

3093	   Robert Hancock
3094	   Siemens/Roke Manor Research
3095	   Old Salisbury Lane
3096	   Romsey, Hampshire  SO51 0ZN
3097	   UK

3099	   EMail: robert.hancock@roke.co.uk
3100	   URI:   http://www.roke.co.uk

3102	Appendix A.  Acknowledgements

3104	   This document is based on the discussions within the IETF NSIS
3105	   working group.  It has been informed by prior work and formal and
3106	   informal inputs from: Cedric Aoun, Attila Bader, Bob Braden, Marcus
3107	   Brunner, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth, Cheng Hong,
3108	   Georgios Karagiannis, John Loughney, Allison Mankin, Jukka Manner,
3109	   Andrew McDonald, Glenn Morrow, Dave Oran, Takako Sanda, Charles Shen,
3110	   Melinda Shore, Martin Stiemerling, Mike Thomas, Hannes Tschofenig,
3111	   Sven van den Bosch, Michael Welzl, and Lars Westberg.  In particular,
3112	   Hannes Tschofenig provided a detailed set of review comments on the
3113	   security section, and Andrew McDonald provided the formal description
3114	   for the initial packet formats.  We look forward to inputs and
3115	   comments from many more in the future.

3117	Appendix B.  Example Message Routing State Table

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

3123	       A                        B          C          D           E
3124	   +------+                  +-----+    +-----+    +-----+    +--------+
3125	   | Flow |    +-+    +-+    |NSLP1|    |NSLP1|    |     |    |  Flow  |
3126	   |Sender|====|R|====|R|====|NSLP2|====|     |====|NSLP2|====|Receiver|
3127	   |      |    +-+    +-+    |GIMPS|    |GIMPS|    |GIMPS|    |        |
3128	   +------+                  +-----+    +-----+    +-----+    +--------+

3130	                     ------------------------------>>
3131	                              Flow Direction

3133	                     Figure 7: A Signaling Scenario

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

3137	   +--------------------+----------+----------+----------+-------------+
3138	   |   Message Routing  |  Session |  NSLP ID |          |  Downstream |
3139	   |     Information    |    ID    |          | Upstream |     Peer    |
3140	   |                    |          |          |   Peer   |             |
3141	   +--------------------+----------+----------+----------+-------------+
3142	   |    Method = Path   |  0xABCD  |   NSLP1  |   IP-#A  |    (null)   |
3143	   | Coupled; Flow ID = |          |          |          |             |
3144	   |   {IP-#A, IP-#E,   |          |          |          |             |
3145	   |  protocol, ports}  |          |          |          |             |
3146	   |                    |          |          |          |             |
3147	   |    Method = Path   |  0x1234  |   NSLP2  |   IP-#A  |  Pointer to |
3148	   | Coupled; Flow ID = |          |          |          |     B-D     |
3149	   |   {IP-#A, IP-#E,   |          |          |          |  messaging  |
3150	   |  protocol, ports}  |          |          |          | association |
3151	   +--------------------+----------+----------+----------+-------------+

3153	   The upstream state is just the same address for each application.
3154	   For the downstream case, NSLP1 only requires datagram mode messages
3155	   and so no explicit routing state towards C is needed.  NSLP2 requires
3156	   a messaging association for its messages towards node D, and node C
3157	   does not process NSLP2 at all, so the downstream peer state for NSLP2
3158	   is a pointer to a messaging association that runs directly from B to
3159	   D.  Note that E is not visible in the state table (except implicitly
3160	   in the address in the message routing information); routing state is
3161	   stored only for adjacent peers.

3163	Appendix C.  Bit-Level Formats

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

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

3178	C.1  General NSIS Formatting Guidelines

3180	   Each NSIS message consists of a header and a sequence of objects.  An
3181	   NSLP message is one object within a GIMPS message.  The GIMPS header
3182	   has a specific format, described in more detail in Appendix C.2
3183	   below; the NSLP header format is common to all signaling applications
3184	   and includes simply a message type (which may be structured into a
3185	   type field and some processing flags, depending on the application).
3186	   Note that GIMPS provides the message length information and signaling
3187	   application identification.

3189	   Note that there is no version information at the NSLP level.  It is
3190	   assumed that minor protocol extensions can be implemented by adding
3191	   extra objects (see Section 8.11); if an NSLP has to be extended so
3192	   much that backwards compatibity is no longer possible, a new
3193	   signaling application identifier is allocated instead.

3195	   Every object has the following general format:

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

3199	   o  By default, assignments for the Type field are common across all
3200	      NSIS protocols (i.e.  there is a single registry).  This is to
3201	      facilitate the sharing of common objects across different
3202	      signaling applications.  How to encode capability information
3203	      therefore has to be standardised across signaling applications;
3204	      this is still an open issue.  Part of the object format is
3205	      reserved for extensibility flags, but no such flags have yet been
3206	      defined (see Section 8.11).

3208	   o  If it was necessary for an NSLP to define a TLV which for some
3209	      reason should never be used by another signaling application, it
3210	      would be possible to set aside a subset of the Type range to be
3211	      private to NSLPs.

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

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

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

3228	C.2  The GIMPS Common Header

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

3236	    0                   1                   2                   3
3237	    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
3238	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3239	   |    Version    |  GIMPS hops   |        Number of TLVs         |
3240	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3241	   |   Signalling Application ID   |D|R|         Reserved          |
3242	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3244	   The flags are:
3245	   D - Direction (Set for "Upstream", Unset for "Downstream")
3246	   R - Response requested

3248	C.3  GIMPS TLV Objects

3250	C.3.1  Standard Object Header

3252	   Each object begins with a fixed header giving the object type and
3253	   object length.  The bits marked 'r' are extensibility flags, which
3254	   (until defined) must be set to 0 on transmission; if a message is
3255	   received with any reserved flags set to 1 the message must be
3256	   rejected with an error.  See Section 8.11 for a discussion of
3257	   extensibility issues for object encoding.

3259	    0                   1                   2                   3
3260	    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
3261	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3262	   |r|r|r|r|         Type          |r|r|r|r|        Length         |
3263	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3269	C.3.2  Message-Routing-Information

3271	   Type: Message-Routing-Information

3273	   Length: Variable (depends on message routing method)

3275	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3276	   | Message-Routing-Method        |                               |
3277	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
3278	   //     Method-specific addressing information (variable)       //
3279	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

3284	                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3285	                                   |IP-Ver |P|T|F|I|O|    Reserved |
3286	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3287	   //                       Source Address                        //
3288	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3289	   //                      Destination Address                    //
3290	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3291	   | Source Prefix |  Dest Prefix  |   Protocol    | Traffic Class |
3292	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3293	   :       Reserved        :              Flow Label               :
3294	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3295	   :                              SPI                              :
3296	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3297	   :          Source Port          :       Destination Port        :
3298	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3300	   The flags are:
3301	   P - Protocol
3302	   T - Traffic Class
3303	   F - Flow Label
3304	   I - SPI
3305	   S - Source Port
3306	   D - Destination Port
3307	   If only one of S, D is set, both Port fields are included in the
3308	   message but the contents of one will be ignored.

3310	C.3.3  Session Identification

3312	   Type: Session-Identification

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

3316	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3317	   |                                                               |
3318	   +                                                               +
3319	   |                                                               |
3320	   +                          Session ID                           +
3321	   |                                                               |
3322	   +                                                               +
3323	   |                                                               |
3324	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3326	C.3.4  Node Addressing

3328	   Type: Node-Addressing

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

3333	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3334	   | PI-Length     | HL-Count      |IP-Ver |    Reserved           |
3335	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3336	   //                       Peer Identity                         //
3337	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3338	   //                     Interface Address                       //
3339	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3340	   |                 Higher-Layer-Information 1                    |
3341	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3342	   :                                                               :
3343	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3344	   |                 Higher-Layer-Information N                    |
3345	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3347	   PI-Length = the byte length of the Peer-Identity field
3348	               (this is padded to a whole number of words)
3349	   HL-Count  = the number of higher-layer-information fields
3350	               (these are assumed to be of fixed length)
3351	   IP-Ver    = the IP version for the Interface-Address field

3353	C.3.5  Stack Proposal

3355	   Type: Stack-Proposal

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

3360	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3361	   | Prof-Number   |     Reserved                                  |
3362	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3363	   //                    Profile 1                                //
3364	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3365	   :                                                               :
3366	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3367	   //                    Profile 2                                //
3368	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3370	   Prof-Number = The number of profiles in the proposal

3372	   Each profile is itself a sequence of protocol layers, formatted
3373	   as a list in the same way.

3375	C.3.6  Query Cookie

3377	   Type: Query-Cookie

3379	   Length: Variable (selected by querying node)

3381	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3382	   |                                                               |
3383	   //                        Query Cookie                         //
3384	   |                                                               |
3385	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3387	C.3.7  Responder Cookie

3389	   Type: Responder-Cookie
3390	   Length: Variable (selected by querying node)

3392	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3393	   |                                                               |
3394	   //                      Responder Cookie                       //
3395	   |                                                               |
3396	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3398	C.3.8  Lifetime

3400	   Type: Lifetime

3402	   Length: Fixed - 1 32-bit word

3404	   Value: Routing state lifetime in seconds

3406	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3407	   |                           Lifetime                            |
3408	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3410	C.3.9  NAT Traversal

3412	   Type: NAT-Traversal

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

3416	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3417	   | MRI-Length    | Type-Count    | NAT-Count    |  Reserved      |
3418	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3419	   //            Original Message-Routing-Information             //
3420	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3421	   //                 List of translated objects                  //
3422	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3423	   | Length of opaque NAO info.    |                               |
3424	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3425	   //            NAO information replaced by NAT #1                |
3426	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3427	   :                                                               :
3428	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3429	   | Length of opaque NAO info.    |                               |
3430	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              //
3431	   //            NAO information replaced by NAT #N                |
3432	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3433	   MRI-Length = the word length of the included MRI payload
3434	   Type-Count = the number of GIMPS payloads translated by the
3435	                NAT; the Type numbers are included as a list
3436	                (padded with 2 null bytes if necessary)
3437	   NAT-Count  = the number of NATs traversed by the message, and the
3438	                number of opaque NAO-related payloads at the end
3439	                of the object

3441	C.3.10  NSLP Data

3443	   Type: NSLP-Data

3445	   Length: Variable (depends on NSLP)

3447	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3448	   |                                                               |
3449	   //                          NSLP Data                          //
3450	   |                                                               |
3451	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3453	Appendix D.  API between GIMPS and NSLP

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

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

3464	   Conceptually the API has similarities to the UDP sockets API,
3465	   particularly that for unconnected UDP sockets.  An extension for an
3466	   API like that for UDP connected sockets could be considered.  In this
3467	   case, for example, the only information needed in a SendMessage
3468	   primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
3469	   (which can be null).  Other information which was persistent for a
3470	   group of messages could be configured once for the socket.

3472	D.1  SendMessage

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

3477	   SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
3478	                 NSLP-Id, Session-ID,
3479	                 MRI, Direction, SII-Handle,
3480	                 Transfer-Attributes, Timeout, IP-TTL )

3482	   NSLP-Data: The NSLP message itself.

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

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

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

3493	   Session-ID: The NSIS session identifier.  Note that it is assumed
3494	      that the signaling application provides this to GIMPS rather than
3495	      GIMPS providing a value itself; often, this will be a value
3496	      associated with an existing session, for example received in an
3497	      incoming message.  In the case of an entirely new session, a GIMPS
3498	      implementation might provide library functionality to generate a
3499	      new, cryptographically random SID which is guaranteed not to
3500	      collide with any existing session.

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

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

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

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

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

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

3528	D.2  RecvMessage

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

3533	   RecvMessage ( [NSLP-Data, NSLP-Data-Size,]
3534	                 NSLP-Id, Session-ID,
3535	                 MRI, Direction, SII-Handle,
3536	                 Transfer-Attributes,
3537	                 IP-TTL, Original-TTL )

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

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

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

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

3548	   Session-ID: The NSIS session identifier.

3550	   MRI: Message routing information that was used by GIMPS in forwarding
3551	      this message.  It contains, for example, the flow source/
3552	      destination addresses and the type of routing to used for the
3553	      signalling message.

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

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

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

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

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

3571	D.3  MessageReceived

3573	   This primitive is passed from an NSLP to GIMPS.  It is used after a
3574	   RecvMessage primitive has been passed from GIMPS to an NSLP to inform
3575	   GIMPS whether the NSLP wishes GIMPS to retain state.

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

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

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

3585	D.4  MessageDeliveryError

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

3591	   MessageDeliveryError ( NSLP-Message-Handle, Error-Type )
3592	   NSLP-Message-Handle: A handle for the message provided by the NSLP at
3593	      the time of sending.

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

3598	D.5  NetworkNotification

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

3603	   NetworkNotification ( MRI, Network-Notification-Type )

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

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

3612	D.6  SecurityProtocolAttributesRequest

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

3619	   SecurityProtocolAttributesRequest ( Peer-Info,
3620	                                       Security-Protocol,
3621	                                       Request-Type )

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

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

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

3631	D.7  SetStateLifetime

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

3638	   SetStateLifetime ( MRI, Direction, State-Lifetime )

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

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

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

3650	Intellectual Property Statement

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

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

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

3674	Disclaimer of Validity

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

3684	Copyright Statement

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

3690	Acknowledgment

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