idnits 2.17.1 draft-ietf-nsis-ntlp-07.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5520. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2476 has weird spacing: '...ng that the r...' == Line 2746 has weird spacing: '...ng that the r...' -- 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 18, 2005) is 6857 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 224 -- Looks like a reference, but probably isn't: 'Flow' on line 236 -- Looks like a reference, but probably isn't: 'Adjacent' on line 246 -- Looks like a reference, but probably isn't: 'Start' on line 2985 == Unused Reference: '1' is defined on line 4327, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 4342, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 4366, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 4381, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 4388, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 4396, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 4414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2765 (ref. '7') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2960 (ref. '8') (Obsoleted by RFC 4960) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 -- Possible downref: Normative reference to a draft: ref. '10' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '12') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '14') (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. '22') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '23') (Obsoleted by RFC 5082) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-06 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-06 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 == Outdated reference: A later version (-04) exists of draft-bound-dstm-exp-03 == Outdated reference: A later version (-02) exists of draft-stiemerling-nsis-natfw-mrm-01 == Outdated reference: A later version (-02) exists of draft-loughney-nsis-ext-00 Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 17 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 19, 2006 R. Hancock 5 Siemens/RMR 6 July 18, 2005 8 GIMPS: General Internet Messaging Protocol for Signaling 9 draft-ietf-nsis-ntlp-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies protocol stacks for the routing and transport 43 of per-flow signaling messages along the path taken by that flow 44 through the network. The design uses existing transport and security 45 protocols under a common messaging layer, the General Internet 46 Messaging Protocol for Signaling (GIMPS), which provides a universal 47 service for diverse signaling applications. GIMPS does not handle 48 signaling application state itself, but manages its own internal 49 state and the configuration of the underlying transport and security 50 protocols to enable the transfer of messages in both directions along 51 the flow path. The combination of GIMPS and the lower layer 52 transport and security protocols provides a solution for the base 53 protocol component of the "Next Steps in Signaling" framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 59 2. Requirements Notation and Terminology . . . . . . . . . . . 6 60 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1 Overall Design Approach . . . . . . . . . . . . . . . . . 8 62 3.2 Modes and Messaging Associations . . . . . . . . . . . . . 9 63 3.3 Message Routing Methods . . . . . . . . . . . . . . . . . 11 64 3.4 Signalling Sessions . . . . . . . . . . . . . . . . . . . 12 65 3.5 Example of Operation . . . . . . . . . . . . . . . . . . . 13 66 4. GIMPS Processing Overview . . . . . . . . . . . . . . . . . 16 67 4.1 GIMPS Service Interface . . . . . . . . . . . . . . . . . 16 68 4.2 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . 17 69 4.3 Basic Message Processing . . . . . . . . . . . . . . . . . 19 70 4.4 Routing State and Messaging Association Maintenance . . . 24 71 5. Message Formats and Transport . . . . . . . . . . . . . . . 31 72 5.1 GIMPS Messages . . . . . . . . . . . . . . . . . . . . . . 31 73 5.2 Information Elements . . . . . . . . . . . . . . . . . . . 33 74 5.3 Datagram Mode Transport . . . . . . . . . . . . . . . . . 36 75 5.4 Connection Mode Transport . . . . . . . . . . . . . . . . 39 76 5.5 Message Type/Encapsulation Relationships . . . . . . . . . 41 77 5.6 Error Message Processing . . . . . . . . . . . . . . . . . 42 78 5.7 Messaging Association Negotiation . . . . . . . . . . . . 43 79 5.8 Specific Message Routing Methods . . . . . . . . . . . . . 45 80 6. Formal Protocol Specification . . . . . . . . . . . . . . . 50 81 6.1 Node Processing . . . . . . . . . . . . . . . . . . . . . 51 82 6.2 Query Node Processing . . . . . . . . . . . . . . . . . . 53 83 6.3 Responder Node Processing . . . . . . . . . . . . . . . . 59 84 6.4 Messaging Association Processing . . . . . . . . . . . . . 65 85 7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 72 86 7.1 Route Changes and Local Repair . . . . . . . . . . . . . . 72 87 7.2 Policy-Based Forwarding and Flow Wildcarding . . . . . . . 78 88 7.3 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 78 89 7.4 Interaction with IP Tunnelling . . . . . . . . . . . . . . 80 90 7.5 IPv4-IPv6 Transition and Interworking . . . . . . . . . . 81 91 8. Security Considerations . . . . . . . . . . . . . . . . . . 83 92 8.1 Message Confidentiality and Integrity . . . . . . . . . . 83 93 8.2 Peer Node Authentication . . . . . . . . . . . . . . . . . 84 94 8.3 Routing State Integrity . . . . . . . . . . . . . . . . . 84 95 8.4 Denial of Service Prevention . . . . . . . . . . . . . . . 86 96 8.5 Summary of Requirements on Cookie Mechanisms . . . . . . . 87 97 8.6 Residual Threats . . . . . . . . . . . . . . . . . . . . . 88 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 99 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 92 100 10.1 Changes In Version -07 . . . . . . . . . . . . . . . . . 92 101 10.2 Changes In Version -06 . . . . . . . . . . . . . . . . . 92 102 10.3 Changes In Version -05 . . . . . . . . . . . . . . . . . 94 103 10.4 Changes In Version -04 . . . . . . . . . . . . . . . . . 95 104 10.5 Changes In Version -03 . . . . . . . . . . . . . . . . . 96 105 10.6 Changes In Version -02 . . . . . . . . . . . . . . . . . 97 106 10.7 Changes In Version -01 . . . . . . . . . . . . . . . . . 98 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 101 108 11.1 Normative References . . . . . . . . . . . . . . . . . . 101 109 11.2 Informative References . . . . . . . . . . . . . . . . . 101 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 103 111 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 112 B. Example Message Routing State Table . . . . . . . . . . . . 106 113 C. Bit-Level Formats and Error Messages . . . . . . . . . . . . 107 114 C.1 General GIMPS Formatting Guidelines . . . . . . . . . . . 107 115 C.2 The GIMPS Common Header . . . . . . . . . . . . . . . . . 107 116 C.3 General Object Characteristics . . . . . . . . . . . . . . 108 117 C.4 GIMPS TLV Objects . . . . . . . . . . . . . . . . . . . . 109 118 C.5 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 116 119 D. API between GIMPS and NSLP . . . . . . . . . . . . . . . . . 124 120 D.1 API Concepts . . . . . . . . . . . . . . . . . . . . . . . 124 121 D.2 SendMessage . . . . . . . . . . . . . . . . . . . . . . . 124 122 D.3 RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 126 123 D.4 MessageStatus . . . . . . . . . . . . . . . . . . . . . . 127 124 D.5 NetworkNotification . . . . . . . . . . . . . . . . . . . 128 125 D.6 SetStateLifetime . . . . . . . . . . . . . . . . . . . . . 128 126 D.7 InvalidateRoutingState . . . . . . . . . . . . . . . . . . 128 127 Intellectual Property and Copyright Statements . . . . . . . 130 129 1. Introduction 131 Signaling involves the manipulation of state held in network 132 elements. 'Manipulation' could mean setting up, modifying and 133 tearing down state; or it could simply mean the monitoring of state 134 which is managed by other mechanisms. 136 This specification concentrates on "path-coupled" signaling, which 137 involves network elements which are located on the path taken by a 138 particular data flow, possibly including but not limited to the flow 139 endpoints. Indeed, there are almost always more than two 140 participants in a path-coupled signaling session, although there is 141 no need for every node on the path to participate. Path-coupled 142 signaling thus excludes end-to-end higher-layer application signaling 143 (except as a degenerate case) such as ISUP (telephony signaling for 144 Signaling System #7) messages being transported by SCTP between two 145 nodes. 147 In the context of path-coupled signaling, examples of state 148 management include network resource allocation (for "resource 149 reservation"), firewall configuration, and state used in active 150 networking; examples of state monitoring are the discovery of 151 instantaneous path properties (such as available bandwidth, or 152 cumulative queuing delay). Each of these different uses of path- 153 coupled signaling is referred to as a signaling application. 155 Every signaling application requires a set of state management rules, 156 as well as protocol support to exchange messages along the data path. 157 Several aspects of this protocol support are common to all or a large 158 number of signaling applications, and hence can be developed as a 159 common protocol. The NSIS framework given in [24] provides a 160 rationale for a function split between the common and application 161 specific protocols, and gives outline requirements for the former, 162 the 'NSIS Transport Layer Protocol' (NTLP). 164 This specification provides a concrete solution for the NTLP. It is 165 based on the use of existing transport and security protocols under a 166 common messaging layer, the General Internet Messaging Protocol for 167 Signaling (GIMPS). GIMPS does not handle signaling application state 168 itself; in that crucial respect, it differs from application 169 signaling protocols such as SIP, RTSP, and the control component of 170 FTP. Instead, GIMPS manages its own internal state and the 171 configuration of the underlying transport and security protocols to 172 ensure the transfer of signaling messages on behalf of signaling 173 applications in both directions along the flow path. 175 1.1 Restrictions on Scope 177 This section briefly lists some important restrictions on GIMPS 178 applicability and functionality. In some cases, these are implicit 179 consequences of the functionality split developed in the NSIS 180 framework; in others, they are restrictions on the types of scenario 181 in which GIMPS can operate correctly. 183 Flow splitting: In some cases, e.g. where packet-level load sharing 184 has been implemented, the path taken by a single flow in the 185 network may not be well defined. If this is the case, GIMPS 186 cannot route signaling meaningfully. (In some circumstances, 187 GIMPS implementations could detect this condition, but even this 188 cannot be guaranteed.) 190 Multicast: GIMPS does not handle multicast flows. This includes 191 'classical' IP multicast and any of the 'small group multicast' 192 schemes recently proposed. 194 2. Requirements Notation and Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [2]. 200 The terminology used in this specification is fully defined in this 201 section. The basic entities relevant at the GIMPS level are shown in 202 Figure 1. 204 Source GIMPS (adjacent) peer nodes Destination 206 IP address IP addresses = Signaling IP address 207 = Flow Source/Destination Addresses = Flow 208 Source (depending on signaling direction) Destination 209 Address | | Address 210 V V 211 +--------+ +------+ Data Flow +------+ +--------+ 212 | Flow |-----------|------|-------------|------|-------->| Flow | 213 | Sender | | | | | |Receiver| 214 +--------+ |GIMPS |============>|GIMPS | +--------+ 215 | Node |<============| Node | 216 +------+ Signaling +------+ 217 GN1 Flow GN2 219 >>>>>>>>>>>>>>>>> = Downstream direction 220 <<<<<<<<<<<<<<<<< = Upstream direction 222 Figure 1: Basic Terminology 224 [Data] Flow: A set of packets identified by some fixed combination of 225 header fields. Flows are unidirectional (a bidirectional 226 communication is considered a pair of unidirectional flows). 228 Session: A single application layer flow of information for which 229 some state information is to be manipulated or monitored. See 230 Section 3.4 for further detailed discussion. 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 flow 234 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 node along the data path, in the upstream 247 or downstream direction, with which a GIMPS node explicitly 248 interacts. The GIMPS peer discovery mechanisms implicitly 249 determine whether two nodes will be adjacent. It is possible for 250 adjacencies to 'skip over' intermediate nodes which decide not to 251 take part in the signaling exchange at the NTLP layer; even if 252 such nodes process parts of the signaling messages, they store no 253 state about the session and are never explicitly visible at the 254 GIMPS level to the nodes either side. 256 Datagram Mode: A mode of sending GIMPS messages between nodes without 257 using any transport layer state or security protection. Datagram 258 mode uses UDP encapsulation, with IP addresses derived either from 259 the flow definition or previously discovered adjacency 260 information. 262 Connection Mode: A mode of sending GIMPS messages directly between 263 nodes using point to point "messaging associations" (see below). 264 Connection mode allows the re-use of existing transport and 265 security protocols where such functionality is required. 267 Messaging Association: A single connection between two explicitly 268 identified GIMPS adjacent peers, i.e. between a given signaling 269 source and destination address. A messaging association may use a 270 specific transport protocol and known ports. If security 271 protection is required, it may use a specific network layer 272 security association, or use a transport layer security 273 association internally. A messaging association is bidirectional; 274 signaling messages can be sent over it in either direction, and 275 can refer to flows of either direction. 277 Message Routing Method: Even in the path-coupled case, there can be 278 different algorithms for discovering the route that signaling 279 messages should take. These are referred to as message routing 280 methods, and GIMPS supports alternatives within a common protocol 281 framework. See Section 3.3. 283 Transfer Attributes: A description of the requirements which a 284 signaling application has for the delivery of a particular 285 message; for example, whether the message should be delivered 286 reliably. See Section 4.1.2. 288 3. Design Overview 290 3.1 Overall Design Approach 292 The generic requirements identified in the NSIS framework [24] for 293 transport of path-coupled signaling messages are essentially two- 294 fold: 296 "Routing": Determine how to reach the adjacent signaling node along 297 each direction of the data path (the GIMPS peer), and if necessary 298 explicitly establish addressing and identity information about 299 that peer; 301 "Transport": Deliver the signaling information to that peer. 303 To meet the routing requirement, one possibility is for the node to 304 use local routing state information to determine the identity of the 305 GIMPS peer explicitly. GIMPS defines a 3-way handshake (Query/ 306 Response/optional Confirm) which sets up the necessary routing state 307 between adjacent peers, during which signalling application data can 308 also be exchanged; the Query message is encapsulated in a special 309 way, depending on the message routing method, in order to probe the 310 network infrastructure so that the correct peer will intercept it. 311 If the routing state does not exist, it may be possible for GIMPS to 312 send a message anyway, with the same encapsulation as used for a 313 Query message. 315 Once the routing decision has been made, the node has to select a 316 mechanism for transport of the message to the peer. GIMPS divides 317 the transport problems into two categories, the easy and the 318 difficult. It handles the easy cases internally, and uses well- 319 understood transport protocols for the harder cases. Here, with 320 details discussed later, "easy" messages are those that are sized 321 well below the lowest MTU along a path, are infrequent enough not to 322 cause concerns about congestion and flow control, and do not need 323 security protection or guaranteed delivery. 325 In [24] all of these routing and transport requirements are assigned 326 to a single notional protocol, the 'NSIS Transport Layer Protocol' 327 (NTLP). The strategy of splitting the transport problem leads to a 328 layered structure for the NTLP, as a specialised GIMPS 'messaging' 329 layer running over standard transport and security protocols, as 330 shown in Figure 2. This also shows GIMPS offering its services to 331 upper layers at an abstract interface, the GIMPS API, further 332 discussed in Section 4.1. 334 ^^ +-------------+ 335 || | Signaling | 336 NSIS +------------|Application 2| 337 Signaling | Signaling +-------------+ 338 Application |Application 1| | 339 Level +-------------+ | 340 || | | 341 VV | | 342 =========|===================|===== <-- GIMPS API 343 | | 344 ^^ +------------------------------------------------+ 345 || |+-----------------------+ +--------------+ | 346 || || GIMPS | | GIMPS State | | 347 || || Encapsulation |<<<>>>| Maintenance | | 348 || |+-----------------------+ +--------------+ | 349 || |GIMPS: Messaging Layer | 350 || +------------------------------------------------+ 351 NSIS | | | | 352 Transport ............................. 353 Level . Transport Layer Security . 354 ("NTLP") ............................. 355 || | | | | 356 || +----+ +----+ +----+ +----+ 357 || |UDP | |TCP | |SCTP| |DCCP|.... 358 || +----+ +----+ +----+ +----+ 359 || | | | | 360 || ............................. 361 || . IP Layer Security . 362 || ............................. 363 VV | | | | 364 =========================|=======|=======|=======|=============== 365 | | | | 366 +----------------------------------------------+ 367 | IP | 368 +----------------------------------------------+ 370 Figure 2: Protocol Stacks for Signaling Transport 372 3.2 Modes and Messaging Associations 374 Internally, GIMPS has two modes of operation: 376 Datagram mode ('D mode') is used for small, infrequent messages with 377 modest delay constraints; it is also used at least for the Query 378 message of the 3-way handshake. 380 Connection mode ('C mode') is used for larger data objects or where 381 fast state setup in the face of packet loss is desirable, or where 382 channel security is required. 384 Datagram mode uses UDP, as this is the only encapsulation which does 385 not require per-message shared state to be maintained between the 386 peers. The connection mode can in principal use any stream or 387 message-oriented transport protocol; this specification currently 388 defines the use of TCP as the initial choice. It may employ specific 389 network layer security associations (such as IPsec), or an internal 390 transport layer security association (such as TLS). When GIMPS 391 messages are carried in connection mode, they are treated just like 392 any other traffic by intermediate routers between the GIMPS peers. 393 Indeed, it would be impossible for intermediate routers to carry out 394 any processing on the messages without terminating the transport and 395 security protocols used. Also, signaling messages are only ever 396 delivered between peers established in GIMPS-Query/Response 397 exchanges. 399 It is possible to mix these two modes along a path. This allows, for 400 example, the use of datagram mode at the edges of the network and 401 connection mode in the core of the network. Such combinations may 402 make operation more efficient for mobile endpoints, while allowing 403 multiplexing of signaling messages across shared security 404 associations and transport connections between core routers. 406 It must be understood that the routing and transport decisions made 407 by GIMPS are not independent. If the message transfer has 408 requirements that enforce the use of connection mode (e.g. the 409 message is so large that fragmentation is required), this can only be 410 used between explicitly identified nodes. In such cases, GIMPS must 411 carry out the 3-way handshake initially in datagram mode to identify 412 the peer and then set up the necessary transport connection if it 413 does not already exist. It must also be understood that the 414 signaling application does not make the D/C mode selection directly; 415 rather, this decision is made by GIMPS on the basis of the message 416 characteristics and the transfer attributes stated by the 417 application. The distinction is not visible at the GIMPS service 418 interface. 420 In general, the state associated with connection mode messaging to a 421 particular peer (signaling destination address, protocol and port 422 numbers, internal protocol configuration and state information) is 423 referred to as a "messaging association". There may be any number of 424 messaging associations between two GIMPS peers (although the usual 425 case is 0 or 1), and they are set up and torn down by management 426 actions within GIMPS itself. 428 3.3 Message Routing Methods 430 The baseline message routing functionality in GIMPS is that 431 signalling messages follow a route defined by an existing flow in the 432 network, visiting a subset of the nodes through which it passes. 433 This is the appropriate behaviour for application scenarios where the 434 purpose of the signalling is to manipulate resources for that flow. 435 However, there are scenarios for which other behaviours are 436 applicable. Two examples are: 438 Predictive Routing: Here, the intent is to send signaling along a 439 path that the data flow may or will follow in the future. 440 Possible cases are pre-installation of state on the backup path 441 that would be used in the event of a link failure; and predictive 442 installation of state on the path that will be used after a mobile 443 node handover. 445 NAT Address Reservations: This applies to the case where a node 446 behind a NAT wishes to use NSIS signaling to reserve an address 447 from which it can be reached by a sender on the other side. This 448 requires a message to be sent outbound from what will be the flow 449 receiver although no reverse routing state exists. 451 Most of the details of GIMPS operation are independent of which 452 alternative is being used. Therefore, the GIMPS design encapsulates 453 the routing-dependent details as a message routing method (MRM), and 454 allows multiple MRMs to be defined. The default is the path-coupled 455 MRM, which corresponds to the baseline functionality described above; 456 a second MRM for the NAT Address Reservation case is also defined. 458 The content of a MRM definition is as follows, using the path-coupled 459 MRM as an example: 461 o The format of the information that describes the path that the 462 signalling should take, the Message Routing Information (MRI). 463 For the path-coupled MRM, this is just the Flow Identifier (see 464 Section 5.8.1.1). The MRI always includes an element to 465 distinguish between the two directions that signalling messages 466 can take, denoted 'upstream' and 'downstream'. 468 o A specification of the IP level encapsulation of the messages that 469 probe the network to discover the adjacent peers. A downstream 470 encapsulation must be defined; an upstream encapsulation is 471 optional. For the path-coupled MRM, this information is given in 472 Section 5.8.1.2 and Section 5.8.1.3. 474 o A specification of what validation checks GIMPS should apply to 475 the probe messages, for example to protect against IP address 476 spoofing attacks. The checks may be dependent on the direction 477 (upstream/downstream) of the message. For the path-coupled MRM, 478 the downstream validity check is basically a form of ingress 479 filtering, also discussed in Section 5.8.1.2. 481 o The mechanism(s) available for route change detection, i.e. any 482 change in the neighbour relationships that the MRM discovers. The 483 default case for any MRM is soft-state refresh, but additional 484 supporting techniques may be possible; see Section 7.1.2. 486 In addition, it should be noted that NAT traversal almost certainly 487 requires transformation of the MRI field in GIMPS messages (see 488 Section 7.3). Although the transformation does not have to be 489 defined as part of the standard, the impact on existing GIMPS NAT 490 implementations should be considered. 492 3.4 Signalling Sessions 494 GIMPS allows signalling applications to associate each message with a 495 "signalling session". Informally, given an application layer 496 exchange of information for which some network control state 497 information is to be manipulated or monitored, the corresponding 498 signalling messages should be associated with the same session. 499 Signalling applications provide the session identifier (SID) whenever 500 they wish to send a message, and GIMPS reports the SID when a message 501 is received. 503 Most GIMPS processing and state information is related to the flow 504 (defined by the MRI, see above) and NSLPID. There are several 505 possible relationships between flows and sessions, for example: 507 o The simplest case is that all messages for the same flow have the 508 same SID. 510 o Messages for more than one flow may use the same SID, for example 511 because one flow is replacing another in a mobility or multihoming 512 scenario. 514 o A single flow may have messages for different SIDs, for example 515 from independently operating signalling applications. 517 Because of this range of options, GIMPS does not perform any 518 validation on how signalling applications map between flows and 519 sessions, nor does it perform any validation on the properties of the 520 SID itself. In particular, when a new SID is needed, logically it 521 should be generated by the NSLP. (NSIS implementations could provide 522 common functionality to generate SIDs for use by any NSLP, but this 523 is not part of GIMPS.) GIMPS only defines the syntax of the SID as 524 an opaque 128-bit number. 526 The SID assignment has the following impact on GIMPS processing: 528 o Messages with the same SID to be delivered reliably between the 529 same GIMPS peers are delivered in order. 531 o All other messagse are handled independently. 533 o GIMPS identifies routing state (upstream and downstream peer) by 534 the triplet (MRI, NSLPID, SID). 536 Strictly, the routing state should not depend on the SID. However, 537 if the routing state is keyed only by (MRI, NSLPID) there is a 538 trivial denial of service attack (see Section 8.3) where a malicious 539 off-path node asserts that it is the peer for a particular flow. 540 Instead, the routing state is also segregated between different SIDs, 541 which means that the attacking node can only disrupt a signalling 542 session if it can guess the corresponding SID. A consequence of this 543 design is that signalling applications should choose SIDs so that 544 they are cryptographically random, and should not use several SIDs 545 for the same flow unless strictly necessary, to avoid additional load 546 from routing state maintenance. 548 3.5 Example of Operation 550 This section presents an example of GIMPS usage in a relatively 551 simple (in particular, NAT-free) signaling scenario, to illustrate 552 its main features. 554 Consider the case of an RSVP-like signaling application which 555 allocates resources for a single unicast flow. We will consider how 556 GIMPS transfers messages between two adjacent peers along the path, 557 GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange 558 is initiated by the signaling application instance in the sender; we 559 take up the story at the point where the first message is being 560 processed (above the GIMPS layer) by the signaling application in 561 GN1. 563 1. The signaling application in GN1 determines that this message is 564 a simple description of resources that would be appropriate for 565 the flow. It determines that it has no special security or 566 transport requirements for the message, but simply that it should 567 be transferred to the next downstream signaling application peer 568 on the path that the flow will take. 570 2. The message payload is passed to the GIMPS layer in GN1, along 571 with a definition of the flow and description of the message 572 transfer attributes {unsecured, unreliable}. GIMPS determines 573 that this particular message does not require fragmentation and 574 that it has no knowledge of the next peer for this flow and 575 signaling application; however, it also determines that this 576 application is likely to require secured upstream and downstream 577 transport of large messages in the future. This determination is 578 a function of node-local policy; see Appendix D.1 for some 579 additional discussion. 581 3. GN1 therefore constructs a GIMPS-Query message, which is a UDP 582 datagram carrying the signaling application payload and 583 additional payloads at the GIMPS level to be used to initiate the 584 setup of a messaging association. The Query is injected into the 585 network, addressed towards the flow destination and with a Router 586 Alert Option included. 588 4. The Query message passes through the network towards the flow 589 receiver, and is seen by each router in turn. GIMPS-unaware 590 routers will not recognise the RAO value and will forward the 591 message unchanged; GIMPS-aware routers which do not support the 592 signaling application in question will also forward the message 593 basically unchanged, although they may need to process more of 594 the message to decide this. 596 5. The message is intercepted at GN2. The GIMPS layer identifies 597 the message as relevant to a local signaling application, and 598 passes the signaling application payload and flow description 599 upwards to it. The signaling application in GN2 indicates to 600 GIMPS that it will peer with GN1 and so GIMPS should proceed to 601 set up any routing state. In addition, the signaling application 602 continues to process the message as in GN1 (compare step 1), and 603 this will eventually result in the message reaching the flow 604 receiver. 606 6. In parallel, the GIMPS instance in GN2 now knows that it should 607 maintain routing state and a messaging association for future 608 signalling with GN1. This is recognised because the message is a 609 GIMPS-Query, and because the local signaling application has 610 indicated that it will peer with GN1. There are two basic 611 possible cases for sending back the necessary GIMPS-Response: 613 A. GN1 and GN2 already have an appropriate messaging 614 association. GN2 simply records the identity of GN1 as its 615 upstream peer for that flow and signaling application, and 616 sends a GIMPS-Response back to GN1 over the association 617 identifying itself as the peer for this flow. 619 B. No messaging association exists. GN2 sends the GIMPS- 620 Response in D mode directly to GN1, identifying itself and 621 agreeing to the association setup. The protocol exchanges 622 needed to complete this will proceed in the background. 624 7. Eventually, another signaling application message works its way 625 upstream from the receiver to GN2. This message contains a 626 description of the actual resources requested, along with 627 authorisation and other security information. The signaling 628 application in GN2 passes this payload to the GIMPS level, along 629 with the flow definition and transfer attributes {secured, 630 reliable}. 632 8. The GIMPS layer in GN2 identifies the upstream peer for this flow 633 and signaling application as GN1, and determines that it has a 634 messaging association with the appropriate properties. The 635 message is queued on the association for transmission (this may 636 mean some delay if the negotiations begun in step 6.B have not 637 yet completed). 639 Further messages can be passed in each direction in the same way. 640 The GIMPS layer in each node can in parallel carry out maintenance 641 operations such as route change detection (this can be done by 642 sending additional GIMPS-Query messages, see Section 7.1 for more 643 details). 645 It should be understood that several of these details of GIMPS 646 operations can be varied, either by local policy or according to 647 signaling application requirements. The authoritative details are 648 contained in the remainder of this document. 650 4. GIMPS Processing Overview 652 This section defines the basic structure and operation of GIMPS. 653 Section 4.1 describes the way in which GIMPS interacts with (local) 654 signaling applications in the form of an abstract service interface. 655 Section 4.2 describes the per-flow and per-peer state that GIMPS 656 maintains for the purpose of transferring messages. Section 4.3 657 describes how messages are processed in the case where any necessary 658 messaging associations and routing state already exist; this includes 659 the simple scenario of pure datagram mode operation, where no 660 messaging associations are necessary in the first place. Finally, 661 Section 4.4 describes how routing state and messaging associations 662 are created and managed. 664 4.1 GIMPS Service Interface 666 This section defines the service interface that GIMPS presents to 667 signaling applications in terms of abstract properties of the message 668 transfer. Note that the same service interface is presented at every 669 GIMPS node; however, applications may invoke it differently at 670 different nodes (e.g. depending on local policy). In addition, the 671 service interface is defined independently of any specific transport 672 protocol, or even the distinction between datagram and connection 673 mode. The initial version of this specification defines how to 674 support the service interface using a connection mode based on TCP; 675 if additional transport protocol support is added, this will support 676 the same interface and so be invisible to applications (except as a 677 possible performance improvement). A more detailed description of 678 this service interface is given in Appendix D. 680 4.1.1 Message Handling 682 Fundamentally, GIMPS provides a simple message-by-message transfer 683 service for use by signaling applications: individual messages are 684 sent, and individual messages are received. At the service 685 interface, the signalling application payload (which is opaque to 686 GIMPS) is accompanied by control information expressing the 687 application's requirements about how the message should be routed, 688 and the application also provides the session identifier (see 689 Section 3.4). Additional message transfer attributes control the 690 specific transport and security properties that the signaling 691 application desires for the message. 693 The distinction between GIMPS connection and datagram modes is not 694 visible at the service interface. In addition, the invocation of 695 GIMPS functionality to handle fragmentation and reassembly, bundling 696 together of small messages (for efficiency), and congestion control 697 is not directly visible at the service interface; GIMPS will take 698 whatever action is necessary based on the properties of the messages 699 and local node state. 701 4.1.2 Message Transfer Attributes 703 Message transfer attributes are used to define certain performance 704 and security related aspects of message processing. The attributes 705 available are as follows: 707 Reliability: This attribute may be 'true' or 'false'. For the case 708 'true', messages will be delivered to the signaling application in 709 the peer exactly once or not at all; if there is a chance that the 710 message was not delivered, an error will be indicated to the local 711 signaling application identifying the routing information for the 712 message in question. For the case 'false', a message may be 713 delivered, once, several times or not at all, with no error 714 indications in any case. 716 Security: This attribute defines the security properties that the 717 signaling application requires for the message, including the type 718 of protection required, and what authenticated identities should 719 be used for the signaling source and destination. This 720 information maps onto the corresponding properties of the security 721 associations established between the peers in connection mode. It 722 can be specified explicitly by the signaling application, or 723 reported by GIMPS to the signaling application (either on 724 receiving a message, or just before sending a message but after 725 configuring or selecting the messaging association to be used for 726 it). This attribute can also be used to convey information about 727 any address validation carried out by GIMPS (for example, whether 728 a return routability check has been carried out). Further details 729 are discussed in Appendix D. 731 Local Processing: An NSLP may provide hints to GIMPS to enable more 732 efficient or appropriate processing. For example, the NSLP may 733 select a priority from a range of locally defined values to 734 influence the sequence in which messages leave a node. Any 735 priority mechanism must respect the ordering requirements for 736 reliable messages within a session, and priority values are not 737 carried in the protocol or available at the signaling peer or 738 intermediate nodes. An NSLP may also indicate that reverse path 739 routing state will not be needed for this flow, to inhibit the 740 node requesting its downstream peer to create it. 742 4.2 GIMPS State 743 4.2.1 Message Routing State 745 For each flow, the GIMPS layer can maintain message routing state to 746 manage the processing of outgoing messages. This state is 747 conceptually organised into a table with the following structure. 749 The primary key (index) for the table is the combination of the 750 information about how the message is to be routed, the session being 751 signalled for, and the signaling application itself: 753 Message Routing Information (MRI): This defines the method to be used 754 to route the message, the direction in which to send the message, 755 and any associated addressing information; see Section 3.3. 757 Session Identification (SID): The signalling session with which this 758 message should be associated; see Section 3.4. 760 Signaling Application Identification (NSLPID): This is an IANA 761 assigned identifier of the signaling application which is 762 generating messages for this flow. The inclusion of this 763 identifier allows the routing state to be different for different 764 signaling applications (e.g. because of different adjacencies). 766 The information for a given key consists of two items: the routing 767 state to reach the upstream and the downstream peer, with respect to 768 the MRI in each case. The routing state includes information about 769 the peer identity (see Section 4.4.2), and a UDP port number (for 770 datagram mode) or a reference to one or more messaging associations 771 (for connection mode). All of this information is learned from prior 772 GIMPS exchanges. 774 It is also possible for the state information for either direction to 775 be null. There are several possible cases: 777 o The signaling application has indicated that no messages will 778 actually be sent in that direction. 780 o The node is a flow endpoint, so there can be no signaling peer in 781 one or other direction. 783 o The node is the endpoint of the signalling path (for example, 784 because it is acting as a proxy, or because it has determined 785 explicitly that there are no further signalling nodes in that 786 direction). 788 o The node can use other techniques to route the message. For 789 example, it can encapsulate it the same way as a Query message and 790 rely on the peer to intercept it. 792 Each item of routing state has an associated validity timer for how 793 long it can be considered accurate; when this timer expires, it is 794 purged if it has not been refreshed. Installation and maintenance of 795 routing state is described in more detail in Section 4.4. 797 Note also that the routing state is described as a table of flows, 798 but that there is no implied constraint on how the information is 799 stored. However, in general, and especially if GIMPS peers are 800 several IP hops away, there is no way to identify the correct 801 downstream peer for a flow and signaling application from the local 802 forwarding table using prefix matching, and the same applies always 803 to upstream peer state because of the possibility of asymmetric 804 routing: per-flow state has to be stored, just as for RSVP [11]. 806 4.2.2 Messaging Association State 808 The per-flow message routing state is not the only state stored by 809 GIMPS. There is also the state required to manage the messaging 810 associations. Since these associations are typically per-peer rather 811 than per-flow, they are stored in a separate table, including the 812 following information: 814 o messages pending transmission while an association is being 815 established; 817 o a timer for how long since the peer re-stated its desire to keep 818 the association open (see Section 4.4.3). 820 In addition, per-association state is held in the messaging 821 association protocols themselves. However, the details of this state 822 are not directly visible to GIMPS, and they do not affect the rest of 823 the protocol description. 825 4.3 Basic Message Processing 827 This section describes how signaling application messages are 828 processed in the case where any necessary messaging associations and 829 routing state are already in place. The description is divided into 830 several parts. Firstly, message reception, local processing and 831 message transmission are described for the case where the node 832 handles the NSLPID in the message. Secondly, the case where the 833 message is forwarded directly in the IP or GIMPS layer (because there 834 is no matching signaling application on the node) is given. An 835 overview is given in Figure 3. 837 +---------------------------------------------------------+ 838 | >> Signaling Application Processing >> | 839 | | 840 +--------^---------------------------------------V--------+ 841 ^ V 842 ^ NSLP Payloads V 843 ^ V 844 +--------^---------------------------------------V--------+ 845 | >> GIMPS >> | 846 | ^ ^ ^ Processing V V V | 847 +--x-----------N--Q---------------------Q--N-----------x--+ 848 x N Q Q N x 849 x N Q>>>>>>>>>>>>>>>>>>>>>Q N x 850 x N Q Bypass at Q N x 851 +--x-----+ +--N--Q--+ GIMPS level +--Q--N--+ +-----x--+ 852 | C-mode | | D-mode | | D-mode | | C-mode | 853 |Handling| |Handling| |Handling| |Handling| 854 +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ 855 x N Q Q N x 856 x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x 857 x N Q Bypass at Q N x 858 +--x--N--+ +-----Q--+ router +--Q-----+ +--N--x--+ 859 |IP Host | | RAO | alert level | RAO | |IP Host | 860 |Handling| |Handling| |Handling| |Handling| 861 +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ 862 x N Q Q N x 863 +--x--N-----------Q--+ +--Q-----------N--x--+ 864 | IP Layer | | IP Layer | 865 | (Receive Side) | | (Transmit Side) | 866 +--x--N-----------Q--+ +--Q-----------N--x--+ 867 x N Q Q N x 868 x N Q Q N x 869 x N Q Q N x 871 NNNNNNNNNNNNNN = 'Normal' datagram mode messages 872 QQQQQQQQQQQQQQ = Datagram mode messages which 873 are Queries or likewise encapsulated 874 xxxxxxxxxxxxxx = connection mode messages 875 RAO = Router Alert Option 877 Figure 3: Message Paths through a GIMPS Node 879 4.3.1 Message Reception 881 Messages can be received in connection or datagram mode, and in the 882 latter case with two types of message encapsulation. 884 Reception in connection mode is simple: incoming packets undergo the 885 security and transport treatment associated with the messaging 886 association, and the messaging association provides complete messages 887 to the GIMPS layer for further processing. Unless the message is 888 protected by a query/response cookie exchange (see Section 4.4.1), 889 the routing state table is checked to ensure that this messaging 890 association is associated with the MRI/NSLPID/SID combination given 891 in the message, or else a "Incorrectly Delivered Message" error 892 message Appendix C.5.4.5 is returned. 894 Reception in datagram mode depends on the message type. 'Normal' 895 messages arrive UDP encapsulated and addressed directly to the 896 receiving signaling node, at an address and port learned previously. 897 Each datagram contains a single complete message which is passed to 898 the GIMPS layer for further processing, just as in the connection 899 mode case. 901 Where GIMPS is sending messages to be intercepted by the appropriate 902 peer rather than directly addressed to it (in particular, Query 903 messages), these are UDP encapsulated with an IP router alert option. 904 Each signaling node will therefore 'see' all such messages. The case 905 where the NSLPID does not match a local signaling application at all 906 is considered below in Section 4.3.4; otherwise, it is again passed 907 up to the GIMPS layer for further processing. 909 4.3.2 Local Processing 911 Once a message has been received, by any method, it is processed 912 locally within the GIMPS layer. The GIMPS processing to be done 913 depends on the message type and payloads carried; most of the GIMPS- 914 internal payloads are associated with state maintenance and are 915 covered in Section 4.4. There is also a hop count to prevent message 916 looping, see Section 4.3.4. 918 The remainder of the GIMPS message consists of an NSLP payload. This 919 is delivered locally to the signaling application identified at the 920 GIMPS level; the format of the NSLP payload is not constrained by 921 GIMPS, and the content is not interpreted. 923 Even when a message relates to a local signaling application, an 924 adjacency may or may not be required based on signaling application 925 policy, and the application of this policy may depend on the NSLP 926 payload. Therefore, when this decision has to be made, the NSLP 927 payload is delivered and the signaling application has two options: 929 o to proceed setting up the adjacency. The application may provide 930 an NSLP payload (which will be used in any GIMPS-Response). 932 o to bypass the message and drop out of the signaling path. The 933 application may provide an NSLP payload (which will be used in the 934 message which is then forwarded in the same direction by GIMPS). 936 Signaling applications can generate their messages for transmission, 937 either asynchronously, or in response to an input message, and GIMPS 938 can also generate messages autonomously. Regardless of the source, 939 outgoing messages are passed downwards for message transmission. 941 4.3.3 Message Transmission 943 When a message is available for transmission, GIMPS uses internal 944 policy and the stored routing state to determine how to handle it. 945 The following processing applies equally to locally generated 946 messages and messages forwarded from within the GIMPS or signaling 947 application levels. (However, note that special rules apply to the 948 transmission of error messages generated by GIMPS. These are given 949 in Section 5.6.) 951 The main decision is whether the message must be sent in connection 952 mode or datagram mode. Reasons for using the former could be: 954 o NSLP requirements: for example, the signaling application has 955 requested channel secured delivery, or reliable delivery; 957 o protocol specification: for example, this document specifies that 958 a message that requires fragmentation MUST be sent over a 959 messaging association; 961 o local GIMPS policy: for example, a node may prefer to send 962 messages over a messaging association to benefit from adaptive 963 congestion control. 965 In principle, as well as determining that some messaging association 966 must be used, GIMPS could select between a set of alternatives, e.g. 967 for load sharing or because different messaging associations provide 968 different transport or security attributes. 970 If the use of a messaging association is selected, the message is 971 queued on the association found from the routing state table, and 972 further output processing is carried out according to the details of 973 the protocol stacks used. If no appropriate association exists, the 974 message is queued while one is created (see Section 4.4). If no 975 association can be created, this is an error condition, and should be 976 indicated back to the local NSLP. 978 If a messaging association is not required, the message is sent in 979 datagram mode. The processing in this case depends on the message 980 type and whether routing state exists or not. 982 o If the message is not a Query, and routing state exists, it is UDP 983 encapsulated and sent directly to the address from the routing 984 state table. 986 o If the message is a Query, then it is UDP encapsulated with IP 987 address and router alert option determined from the MRI and NSLPID 988 (further details depend on the message routing method). 990 o If no routing state exists, GIMPS can attempt to use the same IP/ 991 UDP encapsulation as in the Query case. If this is not possible 992 (e.g. because the encapsulation algorithm for the message routing 993 method is only defined valid for one message direction), then this 994 is an error condition which is reported back to the local NSLP. 996 4.3.4 Bypass Forwarding 998 A node may have to handle messages for which it has no signaling 999 application corresponding to the message NSLPID. There are several 1000 possible cases depending mainly on the RAO setting (see Section 5.3.2 1001 for more details): 1003 1. A datagram mode message contains an RAO value which is relevant 1004 to NSIS but not to the specific node, but the IP layer is unable 1005 to recognise whether it needs to be passed to GIMPS for further 1006 processing or whether the packet should be forwarded just like a 1007 normal IP datagram. 1009 2. A datagram mode message contains an RAO value which is relevant 1010 to the node, but the specific signaling application for the 1011 actual NSLPID in the message is not processed there. 1013 3. A message is delivered directly to the node for which there is no 1014 corresponding signaling application. (According to the rules of 1015 the current specification, this should never happen. While 1016 future versions might find a use for such a feature, currently 1017 this causes an "Incorrectly Delivered Message" error message 1018 (Appendix C.5.4.5) from the GIMPS peer.) 1020 +-------------+-------------+-------------------+-------------------+ 1021 | Match RAO? | Match | IP TTL Handling | GHC Handling | 1022 | | NSLPID? | | | 1023 +-------------+-------------+-------------------+-------------------+ 1024 | No | N/A (NSLPID | Decrement; | Ignore | 1025 | | not | forward message | | 1026 | | examined) | | | 1027 | | | | | 1028 | Yes | No | Decrement; | Decremented | 1029 | | | forward message | | 1030 | | | | | 1031 | Message | No | Reset | Decrement; reject | 1032 | directly | | | with error | 1033 | addressed | | | | 1034 | | | | | 1035 | Yes, or | Yes | Message is | N/A (ignored) | 1036 | message | | locally delivered | | 1037 | directly | | | | 1038 | addressed | | | | 1039 +-------------+-------------+-------------------+-------------------+ 1041 In all cases, the role of GIMPS is to forward the message 1042 essentially unchanged, and it will not become a peer to the node 1043 sending the message. However, a GIMPS implementation must ensure 1044 that the IP TTL field and GIMPS hop count are managed correctly to 1045 prevent message looping, and this should be done consistently 1046 independently of whether the processing (e.g. for case (1)) takes 1047 place on the fast path or in GIMPS-specific code. The rules are that 1048 in cases (1) and (2), the IP TTL is decremented just as if the 1049 message was a normal IP forwarded packet; in cases (2) and (3) the 1050 GIMPS hop count is decremented as in the case of normal input 1051 processing. These rules are summarised in the table above. 1053 4.4 Routing State and Messaging Association Maintenance 1055 The main responsibility of GIMPS is to manage the routing state and 1056 messaging associations which are used in the basic message processing 1057 described above. Routing state is installed and maintained by 1058 specific GIMPS messages. Messaging associations are dependent on the 1059 existence of routing state, but are actually set up by the normal 1060 procedures of the transport and security protocols that comprise 1061 them. Timers control routing state and messaging association refresh 1062 and expiration. 1064 There are two different cases for state installation and refresh: 1066 1. Where routing state is being discovered or a new association is 1067 to be established; and 1069 2. Where an existing association can be re-used, including the case 1070 where routing state for the flow is being refreshed. 1072 These cases are now considered in turn, followed by the case of 1073 background general management procedures. 1075 4.4.1 State Setup 1077 The complete sequence of possible messages for state setup between 1078 adjacent peers is shown in Figure 4 and described in detail in the 1079 following text. 1081 The initial message in any routing state maintenance operation is a 1082 GIMPS-Query message, sent from the querying node and intercepted at 1083 the responding node. This message has addressing and other 1084 identifiers appropriate for the flow and signaling application that 1085 state maintenance is being done for, addressing information about the 1086 node itself, and it is allowed to contain an NSLP payload. The 1087 querying node also includes additional payloads: a Query Cookie, and 1088 optionally a proposal for possible messaging association protocol 1089 stacks. The role of the cookies in this and subsequent messages is 1090 to protect against certain denial of service attacks and to correlate 1091 the various events in the message sequence. 1093 +----------+ +----------+ 1094 | Querying | |Responding| 1095 | Node | | Node | 1096 +----------+ +----------+ 1097 GIMPS-Query 1098 ----------------------> ............. 1099 Router Alert Option . Routing . 1100 MRI/SID/NSLPID . state . 1101 Q-Node Network Layer Info . installed . 1102 Query Cookie . at . 1103 [Q-Node Stack-Proposal . R-node(1) . 1104 Q-Node Stack-Config Data] ............. 1105 [NSLP Payload] 1107 ...................................... 1108 . The responder can use an existing . 1109 . messaging association if available . 1110 . from here onwards to short-circuit . 1111 . messaging association setup . 1112 ...................................... 1114 GIMPS-Response 1115 ............. <---------------------- 1116 . Routing . MRI/SID/NSLPID 1117 . state . R-Node Network Layer Info (D Mode only) 1118 . installed . Query cookie 1119 . at . [R-Node Stack-Proposal 1120 . Q-Node . R-Node Stack-Config Data] 1121 ............. [Responder Cookie] 1122 [NSLP Payload] 1124 .................................... 1125 . If a messaging association needs . 1126 . to be created, it is set up here . 1127 .................................... 1129 GIMPS-Confirm 1130 ----------------------> 1131 MRI/SID/NSLPID ............. 1132 Q-Node Network Layer Info . Routing . 1133 Responder Cookie . state . 1134 [R-Node Stack-Proposal] . installed . 1135 [NSLP Payload] . at . 1136 . R-node(2) . 1137 ............. 1139 Figure 4: Message Sequence at State Setup 1141 Reception of a GIMPS-Query triggers the generation of a GIMPS- 1142 Response message. This is a 'normally' encapsulated datagram mode 1143 message with additional payloads. It contains network layer 1144 information about the responding node, echoes the Query Cookie, and 1145 can contain an NSLP payload (possibly a response to the NSLP payload 1146 in the initial message). In case a messaging association was 1147 requested, it must also contain a Responder Cookie and counter- 1148 proposal for the messaging association protocol stacks. Even if a 1149 messaging association is not requested, the Response may still 1150 include a Responder Cookie if the node's routing state setup policy 1151 requires it (see below). 1153 Setup of a new messaging association begins when peer addressing 1154 information is available and a new messaging association is actually 1155 needed. The setup has to be contemporaneous with a specific GIMPS- 1156 Query/Response exchange, because the addressing information used may 1157 have a limited lifetime (either because it depends on limited 1158 lifetime NAT bindings, or because it refers to agile destination 1159 ports for the transport protocols). The negotiation of what 1160 protocols to use for the messaging association is controlled by the 1161 Stack-Proposal and Stack-Configuration-Data information exchanged, 1162 and the processing of these objects is described in more detail in 1163 Section 5.7. With the protocol options currently defined, setup of 1164 the messaging association always starts from the Querying node, 1165 although more flexible configurations are possible within the overall 1166 GIMPS design. In any case, once set up the association itself can be 1167 used equally in both directions. 1169 The GIMPS-Confirm is the first message sent over the association and 1170 echoes the Responder Cookie and Stack Proposal from the GIMPS- 1171 Response. The former is used to allow the receiver to validate the 1172 contents of the message (see Section 8.5), and the latter is to 1173 prevent certain bidding-down attacks on messaging association 1174 security. The association can be used in the upstream direction for 1175 that flow and NSLPID after the Confirm has been received. 1177 The querying node installs the responder address as routing state 1178 information after verifying the Query Cookie in the GIMPS-Response. 1179 The responding node can install the querying address as peer state 1180 information at two points in time: 1182 1. after the receipt of the initial GIMPS-Query, or 1184 2. after a GIMPS-Confirm message containing the Responder Cookie. 1186 The precise constraints on when state information is installed are a 1187 matter of security policy considerations on prevention of denial-of- 1188 service attacks and state poisoning attacks, which are discussed 1189 further in Section 8. Because the responding node may choose to 1190 delay state installation as in case (2), the GIMPS-Confirm must 1191 contain sufficient information to allow it to be processed 1192 identically to the original Query. This places some special 1193 requirements on NAT traversal and cookie functionality, which are 1194 discussed in Section 7.3 and Section 8 respectively. 1196 4.4.2 Association Re-use 1198 It is a general design goal of GIMPS that, so far as possible, 1199 messaging associations should be re-used for multiple flows and 1200 sessions, rather than a new association set up for each. This is to 1201 ensure that the association cost scales only like the number of 1202 peers, and to avoid the latency of new association setup where 1203 possible. 1205 However, re-use requires the identification of an existing 1206 association which matches the same routing state and desired 1207 properties that would be the result of a full handshake in D-mode, 1208 and this identification must be done as reliably and securely as 1209 continuing with the full procedure. Note that this requirement is 1210 complicated by the fact that NATs may remap the node addresses in 1211 D-mode messages, and also interacts with the fact that some nodes may 1212 peer over multiple interfaces (and so with different addresses). 1214 Association re-use is controlled by the Network-Layer-Information 1215 (NLI) object, which is carried in GIMPS-Query/Confirm and optionally 1216 GIMPS-Response messages. The NLI object includes: 1218 Peer-Identity: For a given node, this is a stable quantity (interface 1219 independent) with opaque syntax. It should be chosen so as to 1220 have a high probability of uniqueness between peers. Note that 1221 there is no cryptographic protection of this identity (attempting 1222 to provide this would essentially duplicate the functionality in 1223 the messaging association security protocols). 1225 Interface-Address: This is an IP address associated with the 1226 interface through which the flow associated with the signaling is 1227 routed. This can be considered as a routable identifier through 1228 which the signaling node can be reached; further discussion is 1229 contained in Section 5.7. 1231 By default, a messaging association is associated with the NLI object 1232 that was provided by the peer in the Query/Response/Confirm at the 1233 time the association was set up. There may be more than one 1234 association for a given NLI object (e.g. with different properties). 1236 Association re-use is controlled by matching the NLI provided in a 1237 GIMPS message with those associated with existing associations. This 1238 can be done on receiving either a GIMPS-Query or GIMPS-Response (the 1239 former is more likely): 1241 o If there is a perfect match to the NLI of an existing association, 1242 that association can be re-used (provided it has the appropriate 1243 properties in other respects). This is indicated by sending the 1244 remaining messages in the handshake over that association. This 1245 will only fail (i.e. lead to re-use of an association to the 1246 'wrong' node) if signaling nodes have colliding Peer-Identities, 1247 and one is reachable at the same Interface-Address as another. 1248 (This could be done by an on-path attacker.) 1250 o In all other cases, the full handshake is executed in datagram 1251 mode as usual. There are in fact four possibilities: 1253 1. Nothing matches: this is clearly a new peer. 1255 2. Only the Peer-Identity matches: this may be either a new 1256 interface on an existing peer, or a changed address mapping 1257 behind a NAT, or an attacker attempting to hijack the Peer- 1258 Identity. These should be rare events, so the expense of a 1259 new association setup is acceptable. If the authenticated 1260 peer identities match after association setup, the two 1261 Interface-Addresses may be bound to the association. 1263 3. Only the Interface-Address matches: this is probably a new 1264 peer behind the same NAT as an existing one. A new 1265 association setup is required. 1267 4. The full NLI object matches: this is a degenerate case, where 1268 one node recognises an existing peer, but wishes to allow the 1269 option to set up a new association in any case (for example to 1270 create an association with different transport or security 1271 properties). 1273 4.4.3 State Maintenance Procedures 1275 Refresh and expiration of all types of state is controlled by timers. 1277 Each item of routing state expires after a validity lifetime which is 1278 negotiated during the Query/Response/Confirm handshake. The NLI 1279 object in the Query contains a proposal for the lifetime value, and 1280 the NLI in the Response contains the value the Responding node 1281 requires. It is the responsibility of the Querying node to generate 1282 a GIMPS-Query message before this timer expires, if it believes that 1283 the flow is still active; otherwise, the Responding node may delete 1284 the state. Receipt of the message at the Responding node will 1285 refresh peer addressing state for one direction, and receipt of a 1286 GIMPS-Response at the querying node will refresh it for the other. 1287 There is no mechanism at the GIMPS level for explicit teardown of 1288 routing state. 1290 Unneeded messaging associations can be torn down by GIMPS, using the 1291 teardown mechanisms of the underlying transport or security protocols 1292 if available (for example, simply by closing a TCP connection). The 1293 teardown can be initiated by either end. Whether an association is 1294 needed is a combination of two factors: 1296 o local policy, which could take into account the cost of keeping 1297 the messaging association open, the level of past activity on the 1298 association, and the likelihood of future activity (e.g. if there 1299 is routing state still in place which might generate messages to 1300 use it). 1302 o whether the peer still wants the association in place. During 1303 messaging association setup, each node indicates its own MA-hold- 1304 time as part of the Stack-Configuration-Data; the node promises 1305 not to tear down the association if it has received traffic from 1306 its peer over that period. A peer which has generated no traffic 1307 but still wants the association retained can use a special 'null' 1308 message (GIMPS-MA-Hello) to indicate the fact. 1310 Messaging associations can always be set up on demand, and messaging 1311 association status is not made directly visible outside the GIMPS 1312 layer. Therefore, even if GIMPS tears down and later re-establishes 1313 a messaging association, signaling applications cannot distinguish 1314 this from the case where the association is kept permanently open. 1315 (To maintain the transport semantics described in Section 4.1, GIMPS 1316 must close transport connections carrying reliable messages 1317 gracefully or report an error condition, and must not open a new 1318 association for a given session and peer while messages on a previous 1319 association may still be outstanding.) 1321 5. Message Formats and Transport 1323 5.1 GIMPS Messages 1325 All GIMPS messages begin with a common header, which includes a 1326 version number, information about message type, signaling 1327 application, and additional control information. The remainder of 1328 the message is encoded in an RSVP-style format, i.e., as a sequence 1329 of type-length-value (TLV) objects. This subsection describes the 1330 possible GIMPS messages and their contents at a high level; a more 1331 detailed description of each information element is given in 1332 Section 5.2. 1334 The following gives the syntax of GIMPS messages in ABNF [3]. 1336 GIMPS-Message: The main messages are either one of the stages in the 1337 3-way handshake, or a simple message carrying NSLP data. Additional 1338 types are allocated for errors and messaging association keepalive. 1340 GIMPS-Message = GIMPS-Query / GIMPS-Response / 1341 GIMPS-Confirm / GIMPS-Data / 1342 GIMPS-Error / GIMPS-MA-Hello 1344 GIMPS-Query: A GIMPS-Query is always sent in datagram mode. As well 1345 as the common header, it contains certain mandatory control objects, 1346 and may contain a signaling application payload. A stack proposal 1347 and configuration data are mandatory if the message exchange relates 1348 to setup of a messaging association. 1350 GIMPS-Query = Common-Header 1351 Message-Routing-Information 1352 Session-Identification 1353 Network-Layer-Information 1354 Query-Cookie 1355 [ Stack-Proposal Stack-Configuration-Data ] 1356 [ NSLP-Data ] 1358 GIMPS-Response: A GIMPS-Response may be sent in datagram or 1359 connection mode (if a messaging association is being re-used). It 1360 echoes the MRI, SID and Query-Cookie of the Query, and in D-mode 1361 carries its own Network-Layer-Information; if the message exchange 1362 relates to setup of a messaging association (which can only take 1363 place in datagram mode), a Responder cookie is mandatory, as is its 1364 own stack proposal and configuration data. 1366 GIMPS-Response = Common-Header 1367 Message-Routing-Information 1368 Session-Identification 1369 [ Network-Layer-Information ] 1370 Query-Cookie 1371 [ Responder-Cookie 1372 [ Stack-Proposal Stack-Configuration-Data ] ] 1373 [ NSLP-Data ] 1375 GIMPS-Confirm: A GIMPS-Confirm may be sent in datagram or connection 1376 mode (if a messaging association has been re-used). It echoes the 1377 MRI, SID and Responder-Cookie of the Response; if the message 1378 exchange relates to setup of a new messaging association or reuse of 1379 an existing one (which can only take place in connection mode), the 1380 message must also echo the Stack-Proposal from the GIMPS-Response so 1381 it can be verified that this has not been tampered with. 1383 GIMPS-Confirm = Common-Header 1384 Message-Routing-Information 1385 Session-Identification 1386 Network-Layer-Information 1387 Responder-Cookie 1388 [ Stack-Proposal ] 1389 [ NSLP-Data ] 1391 GIMPS-Data: A plain data message contains no control objects, but 1392 only the MRI and SID associated with the NSLP data being transferred. 1393 Network-Layer-Information is only carried in the datagram mode case. 1395 GIMPS-Data = Common-Header 1396 Message-Routing-Information 1397 Session-Identification 1398 [ Network-Layer-Information ] 1399 NSLP-Data 1401 GIMPS-Error: A GIMPS-Error message reports a problem determined at 1402 the GIMPS level. (Errors generated by signalling applications are 1403 reported in NSLP-Data payloads and are not treated specially by 1404 GIMPS.) The message includes a Network-Layer-Information object for 1405 the originator of the error message it if is being sent in datagram 1406 mode; all other information related to the error is carried in a 1407 GIMPS-Error-Data object. 1409 GIMPS-Error = Common-Header 1410 [ Network-Layer-Information ] 1411 GIMPS-Error-Data 1413 GIMPS-MA-Hello: This message can be sent only in C-Mode to indicate 1414 that a node wishes to keep a messaging association open. It contains 1415 only the common header, with a null NSLPID. A flag can be set in the 1416 Common-Header to indicate that a reply is requested, thus allowing a 1417 node to test the liveness of the peer. 1419 GIMPS-MA-Hello = Common-Header 1421 5.2 Information Elements 1423 This section describes the content of the various information 1424 elements that can be present in each GIMPS message, both the common 1425 header, and the individual TLVs. The bit patterns are provided in 1426 Appendix C. 1428 5.2.1 The Common Header 1430 Each message begins with a fixed format common header, which contains 1431 the following information: 1433 Version: The version number of the GIMPS protocol. 1435 Length: The number of 32 bit words in the message following the 1436 common header. 1438 Signaling application identifier (NSLPID): This describes the 1439 specific signaling application, such as resource reservation or 1440 firewall control. 1442 GIMPS hop counter: A hop counter to prevent a message from looping 1443 indefinitely. 1445 Message type: The message type (Query, Response, etc.) 1447 Source addressing mode: A flag to indicate whether the IP source 1448 address of the message was set to be the signaling source address, 1449 or whether it was derived from the message routing information in 1450 the payload. 1452 Response requested: A flag to indicate that a message should be sent 1453 in response to this message. 1455 5.2.2 TLV Objects 1457 All data following the common header is encoded as a sequence of 1458 type-length-value objects. Currently, each object can occur at most 1459 once; the set of required and permitted objects is determined by the 1460 message type encapsulation. The ABNF given above fixes the order of 1461 objects within a message. 1463 Message-Routing-Information (MRI): Information sufficient to define 1464 how the signaling message should be routed through the network. 1466 Message-Routing-Information = message-routing-method 1467 method-specific-information 1469 The format of the method-specific-information depends on the 1470 message-routing-method requested by the signaling application. 1471 The MRI is essentially a read only object for GIMPS processing. 1472 It is set by the NSLP in the message sender and used by GIMPS to 1473 select the message addressing, but not otherwise modified. 1475 Session-Identification (SID): The GIMPS session identifier is a long, 1476 cryptographically random identifier chosen by the node which 1477 originates the signaling exchange. See Section 3.4. 1479 Network-Layer-Information: This object carries information about the 1480 network layer attributes of the node sending the message, 1481 including data related to the management of routing state. This 1482 includes a peer identity and IP address for the sending node. It 1483 also includes IP TTL information to allow the hop count between 1484 GIMPS peers to be measured and reported, and a validity time for 1485 the routing state. 1487 Network-Layer-Information = peer-identity 1488 interface-address 1489 RS-validity-time 1490 IP-TTL 1492 The peer-identity and interface-address are used for matching 1493 existing associations, as discussed in Section 4.4.2. Any 1494 technique may be used to generate the peer-identity, so long as it 1495 is stable. The interface-address must be routable, i.e. it must 1496 be usable as a destination IP address for packets to be sent back 1497 to the node generating the signalling message (whether in datagram 1498 or connection mode). This rules out the use of certain classes of 1499 address, such as link-local addresses (unless the GIMPS peer is 1500 known to be on-link). Where this object is used in a GIMPS-Query, 1501 the interface-address should specifically be set to the address of 1502 the interface that will be used for the outbound flow, to allow 1503 its use in route change handling, see Section 7.1. The use of the 1504 RS-validity-time field is described in Section 4.4.3. 1506 The setting and interpretation of the IP-TTL field depends on the 1507 message direction (as determined from the MRI) and encapsulation. 1509 * If the message is downstream, the IP-TTL is set to the TTL that 1510 will be set in the IP header for the message (if this can be 1511 determined), or else 0. 1513 * On receiving a downstream message in datagram mode, the IP-TTL 1514 is compared to the TTL in the IP header, and the result is 1515 stored as the IP-hop-count-to-peer for the upstream peer in the 1516 routing state table for that flow. Otherwise, the field is 1517 ignored. 1519 * If the message is upstream, the IP-TTL is set to the value of 1520 the IP-hop-count-to-peer stored in the routing state table, or 1521 0 if there is no value yet stored. 1523 * On receiving an upstream message, the IP-TTL is stored as the 1524 IP-hop-count-to-peer for the downstream peer. 1526 In all cases, the TTL value reported to signaling applications is 1527 the one stored with the routing state for that flow, after it has 1528 been updated (if appropriate) from processing the message in 1529 question. 1531 Stack-Proposal: This field contains information about which 1532 combinations of transport and security protocols are proposed for 1533 use in messaging associations, and is also discussed further in 1534 Section 5.7. 1536 Stack-Proposal = 1*stack-profile 1538 stack-profile = 1*protocol-layer 1540 Each protocol-layer field identifies a protocol with a unique tag; 1541 any address-related (mutable) information associated with the 1542 protocol will be carried in a higher-layer-addressing field in the 1543 Stack-Configuration-Data TLV (see below). 1545 Stack-Configuration-Data: This object carries information about the 1546 overall configuration of a messaging association. 1548 Stack-Configuration-Data = MA-hold-time 1549 0*higher-layer-addressing 1551 The MA-hold-time field indicates how long a node will hold open an 1552 inactive association; see Section 4.4.3 for more discussion. The 1553 higher-layer-addressing fields give the configuration of the 1554 protocols to be used for new messaging associations, and they are 1555 described in more detail in Section 5.7. 1557 Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a 1558 GIMPS-Query message and must be echoed in a GIMPS-Response; a 1559 Response-Cookie is optional in a GIMPS-Response message, and if 1560 present must be echoed in the following GIMPS-Confirm message. 1561 Cookies are variable length (chosen by the cookie generator) and 1562 need to be designed so that a node can determine the validity of a 1563 cookie without keeping state. See Section 8.5 for further details 1564 on requirements and mechanisms for cookie generation. 1566 NSLP-Data: The NSLP payload to be delivered to the signaling 1567 application. GIMPS does not interpret the payload content. 1569 GIMPS-Error-Data: This contains all the information to determine the 1570 cause and context of an error. 1572 GIMPS-Error-Data = error-class 1573 error-code error-subcode 1574 common-header 1575 [ Message-Routing-Information-content ] 1576 [ Session-Identification-content ] 1577 0*additional-information 1578 [ comment ] 1580 The error-class indicates the severity level, and the error-code 1581 and error-subcode identify the specific error itself. A full list 1582 of GIMPS errors and their severity levels is given in 1583 Appendix C.5. The common-header from the original message is 1584 always included, as are the contents of the Message-Routing- 1585 Information and Session-Identification objects if they were 1586 successfully decoded. For some errors, additional information 1587 fields must be included according to a fixed format; finally, an 1588 optional free-text comment may be added. 1590 5.3 Datagram Mode Transport 1592 This section describes the various encapsulation options for datagram 1593 mode messages. Although there are several possibilities, depending 1594 on message type, message routing method, and local policy, the 1595 general design principle is that the sole purpose of the 1596 encapsulation is to ensure that the message is delivered to or 1597 intercepted at the correct peer. Beyond that, minimal significance 1598 is attached to the type of encapsulation or the values of addresses 1599 or ports used for it. This allows new options to be developed in the 1600 future to handle particular deployment requirements without modifying 1601 the overall protocol specification. 1603 5.3.1 Normal Encapsulation 1605 Normal encapsulation is used for all datagram mode messages where the 1606 signaling peer is already known from previous signaling. This 1607 includes Response and Confirm messages, and Data messages except if 1608 these are being sent without using local routing state. Normal 1609 encapsulation is simple: the complete set of GIMPS payloads is 1610 concatenated together with the common header, and placed in the data 1611 field of a UDP datagram. UDP checksums should be enabled. The 1612 message is IP addressed directly to the adjacent peer; the UDP port 1613 numbering should be compatible with that used on Query messages (see 1614 below), that is, the same for messages in the same direction and 1615 swapped otherwise. 1617 5.3.2 Query Encapsulation 1619 Query encapsulation is used for messages where no routing state is 1620 available or where the routing state is being refreshed, in 1621 particular for GIMPS-Query messages. Query encapsulation is similar 1622 to normal encapsulation, with changes in IP address selection, IP 1623 options, and a defined method for selecting UDP ports. 1625 In general, the IP addresses are derived from information in the MRI; 1626 the exact rules depend on the message routing method. In addition, 1627 the IP header is given a Router Alert Option to assist the peer in 1628 intercepting the message depending on the NSLPID. Each NSLPID 1629 corresponds to a unique RAO value, but not necessarily vice versa; 1630 further details are discussed in [34]. 1632 The source UDP port is selected by the message sender as the port at 1633 which it is prepared to receive UDP messages in reply, and a 1634 destination UDP port should be allocated by IANA. Note that GIMPS 1635 may send messages addressed as {flow sender, flow receiver} which 1636 could make their way to the flow receiver even if that receiver were 1637 GIMPS-unaware. This should be rejected (with an ICMP message) rather 1638 than delivered to the user application (which would be unable to use 1639 the source address to identify it as not being part of the normal 1640 data flow). Therefore, a "well-known" port is required. 1642 5.3.3 Retransmission and Rate-Control 1644 Datagram mode uses UDP, and hence has no automatic reliability or 1645 congestion control capabilities. Signaling applications requiring 1646 reliability should be serviced using C-mode, which should also carry 1647 the bulk of signaling traffic. However, some form of messaging 1648 reliability is required for the GIMPS control messages themselves, as 1649 is rate control to handle retransmissions and also bursts of 1650 unreliable signaling or state setup requests from the signaling 1651 applications. 1653 GIMPS-Query messages which do not receive GIMPS-Responses should be 1654 retransmitted with a binary exponential backoff, with an initial 1655 timeout of T1 up to a maximum of T2 seconds. The values of T1 and T2 1656 may be implementation defined; default values are for further study. 1657 The value of T1 may be increased on long latency links. Note that 1658 GIMPS-Queries may go unanswered either because of message loss, or 1659 because there is no reachable GIMPS peer. Therefore, implementations 1660 must trade off reliability (large T2) against promptness of error 1661 feedback to applications (small T2). GIMPS-Responses should always 1662 be sent promptly to avoid spurious retransmissions. Retransmitted 1663 GIMPS-Queries should use different Query-Cookie values and will 1664 therefore elicit different GIMPS-Responses. If either message 1665 carries NSLP data, it may be delivered multiple times to the 1666 signaling application. 1668 Other datagram mode messages are not generally retransmitted. GIMPS- 1669 Responses do not need reliability; if they are lost, the initiating 1670 Query will eventually be resent. 1672 The case of a lost GIMPS-Confirm is more subtle. Notionally, we can 1673 distinguish between two cases: 1675 1. Where the Responding node is already prepared to store per-flow 1676 state after receiving a single (Query) message. This would 1677 include any cases where the node has NSLP data queued to send. 1678 Here, it is reasonable for the protocol to demand that the 1679 Responding node runs a retransmission timer to resend the 1680 Response message until a Confirm is received, since the node is 1681 already managing state for that flow. The problem of an 1682 amplification attack stimulated by a malicious Query should be 1683 handled by requiring the cookie mechanism to enable the node 1684 receiving the Response to discard it efficiently if it does not 1685 match a previously sent Query. 1687 2. Where the responding node is not prepared to store per-flow state 1688 until receiving a properly formed Confirm message. 1690 In case (2), a retransmission timer should not be required. However, 1691 we can assume that the next signaling message will be in the 1692 direction Querying Node -> Responding Node (if there is no 'next 1693 signaling message' the fact that the Confirm has been lost is moot). 1694 In this case, the responding node will start to receive messages at 1695 the GIMPS level for a MRI/NSLP combination for which there is no 1696 stored routing state (since this state is only created on receipt of 1697 a Confirm). 1699 The consequence of this is that the error condition is detected at 1700 the Responding node when such a message arrives, without the need for 1701 a specific timer. Recovery requires a Confirm to be transmitted and 1702 successfully received. The mechanism to cause this is for the 1703 Responding node to reject the incoming message with a "No Routing 1704 State" error message (Appendix C.5.4.6) back to the Querying node, 1705 which interprets this as caused by a lost Confirm; the Querying node 1706 needs to be able to regenerate the Confirm purely from local state 1707 (e.g. in particular it needs to remember a valid Responder Cookie). 1709 The basic rate-control requirements for datagram mode traffic are 1710 deliberately minimal. A single rate limiter applies to all traffic 1711 (for all interfaces and message types). It applies to 1712 retransmissions as well as new messages, although an implementation 1713 may choose to prioritise one over the other. When the rate limiter 1714 is imposed, datagram mode messages are queued until transmission is 1715 re-enabled, or an error condition may be indicated back to local 1716 signaling applications. The rate limiting mechanism is 1717 implementation defined, but it is recommended that a token bucket 1718 limiter as described in [10] should be used. 1720 5.4 Connection Mode Transport 1722 Encapsulation in connection mode is more complex, because of the 1723 variation in available transport functionality. This issue is 1724 treated in Section 5.4.1. The actual encapsulation is given in 1725 Section 5.4.2. 1727 5.4.1 Choice of Transport Protocol 1729 It is a general requirement of the NTLP defined in [24] that it 1730 should be able to support bundling (of small messages), fragmentation 1731 (of large messages), and message boundary delineation. Not all 1732 transport protocols natively support all these features. 1734 SCTP [8] satisfies all requirements. 1736 DCCP [9] is message based but does not provide bundling or 1737 fragmentation. Bundling can be carried out by the GIMPS layer 1738 sending multiple messages in a single datagram; because the common 1739 header includes length information, the message boundaries within 1740 the datagram can be discovered during parsing. Fragmentation of 1741 GIMPS messages over multiple datagrams should be avoided, because 1742 of amplification of message loss rates that this would cause. 1744 TCP provides both bundling and fragmentation, but not message 1745 boundaries. However, the length information in the common header 1746 allows the message boundary to be discovered during parsing. 1748 The bundling together of small messages is either built into the 1749 transport protocol or can be carried out by the GIMPS layer during 1750 message construction. Either way, two approaches can be 1751 distinguished: 1753 1. As messages arrive for transmission they are gathered into a 1754 bundle until a size limit is reached or a timeout expires (cf. 1755 the Nagle algorithm of TCP or similar optional functionality in 1756 SCTP). This provides maximal efficiency at the cost of some 1757 latency. 1759 2. Messages awaiting transmission are gathered together while the 1760 node is not allowed to send them (e.g. because it is congestion 1761 controlled). 1763 The second type of bundling is always appropriate. For GIMPS, the 1764 first type is inappropriate for 'trigger' (i.e. state-changing) 1765 messages, but may be appropriate for refresh messages. These 1766 distinctions are known only to the signaling applications, but could 1767 be indicated (as an implementation issue) by setting the priority 1768 transfer attribute. 1770 It can be seen that all of these protocol options can be supported by 1771 the basic GIMPS message format already presented. GIMPS messages 1772 requiring fragmentation must be carried using a reliable transport 1773 protocol, TCP or SCTP. This specification defines only the use of 1774 TCP, but it can be seen that the other possibilities could be 1775 included without additional work on message formatting. 1777 5.4.2 Encapsulation Format 1779 The GIMPS message, consisting of common header and TLVs, is carried 1780 directly in the transport protocol (possibly incorporating transport 1781 layer security protection). Further messages can be carried in a 1782 continuous stream (for TCP), or up to the next transport layer 1783 message boundary (for SCTP/DCCP/UDP). This situation is shown in 1784 Figure 5. 1786 +---------------------------------------------+ 1787 | L2 Header | 1788 +---------------------------------------------+ 1789 | IP Header | ^ 1790 | Source address = signaling source | ^ 1791 | Destination address = signaling destination | . 1792 +---------------------------------------------+ . 1793 | L4 Header | . ^ 1794 | (Standard TCP/SCTP/DCCP/UDP header) | . ^ 1795 +---------------------------------------------+ . . 1796 | GIMPS Message | . . ^ 1797 | (Common header and TLVs as in section 5.1) | . . ^ Scope of 1798 +---------------------------------------------+ . . . security 1799 | Additional GIMPS messages, each with its | . . . protection 1800 | own common header, either as a continuous | . . . (depending 1801 | stream, or continuing to the next L4 | . . . on channel 1802 . message boundary . . . . security 1803 . . V V V mechanism 1804 . . V V V in use) 1806 Figure 5: Connection Mode Encapsulation 1808 5.5 Message Type/Encapsulation Relationships 1810 GIMPS has four primary message types (Query/Response/Confirm/Data) 1811 and three possible encapsulation methods (D-Mode Normal/D-Mode Query/ 1812 C-Mode). For information, the allowed combinations of message type 1813 and encapsulation are given in the table below. However, it should 1814 be noted that the processing of the message at the receiver is not 1815 directly affected by the encapsulation method used, with the 1816 exception that the decapsulation process may provide additional 1817 information (e.g. translated addresses or IP hop count) which is used 1818 in the subsequent message processing. The selection of the 1819 encapsulation method is a matter for the message sender. 1821 +----------------+----------------+----------------+----------------+ 1822 | Message | D-Mode Normal | D-Mode Query | C-Mode | 1823 +----------------+----------------+----------------+----------------+ 1824 | GIMPS-Query | Never | Always | Never | 1825 | | | | | 1826 | GIMPS-Response | Unless a | Never | If a messaging | 1827 | | messaging | | association is | 1828 | | association is | | being re-used | 1829 | | being re-used | | | 1830 | | | | | 1831 | GIMPS-Confirm | Unless a | Never | If a messaging | 1832 | | messaging | | association | 1833 | | association | | has been set | 1834 | | has been set | | up or is being | 1835 | | up or is being | | re-used | 1836 | | re-used | | | 1837 | | | | | 1838 | GIMPS-Data | If routing | If no routing | If a messaging | 1839 | | state exists | state exists | association | 1840 | | for the flow | and the MRI | exists | 1841 | | but no | can be used to | | 1842 | | appropriate | derive the | | 1843 | | messaging | query | | 1844 | | association | encapsulation | | 1845 +----------------+----------------+----------------+----------------+ 1847 5.6 Error Message Processing 1849 Special rules apply to the encapsulation and transmission of error 1850 messages, and they are described here. 1852 GIMPS only generates error messages in response to incoming messages. 1853 (Error messages must not be generated in response to incoming error 1854 messages.) The routing and encapsulation of the error message is 1855 derived from that of the message that caused the error; in 1856 particular, local routing state is not consulted. No routing state 1857 or messaging association state should be created to handle the error, 1858 and error messages are not retransmitted explicitly by GIMPS, 1859 although they are subject to the same rate control as other messages. 1861 o If the incoming message was received in datagram mode, the error 1862 is send in datagram mode using the 'normal' encapsulation, using 1863 the addressing information from the NLI object in the incoming 1864 message. The NLI object in the GIMPS-Error message reports 1865 information about the generator of the error. 1867 o If the incoming message was received over a messaging association, 1868 the error is sent back over the same messaging association. 1870 The NSLPID in the common header of the GIMPS-Error is the null value 1871 (as for GIMPS-MA-Hello). If for any reason the error message cannot 1872 be sent (for example, if the NLI of the inbound message could not be 1873 decoded, or because an error message is too large to send in datagram 1874 mode), an error should be logged locally. 1876 5.7 Messaging Association Negotiation 1878 5.7.1 Overview 1880 A key attribute of GIMPS is that it is flexible in its ability to use 1881 existing transport and security protocols. Different transport 1882 protocols may have performance attributes appropriate to different 1883 environments; different security protocols may fit appropriately with 1884 different authentication infrastructures. Even given an initial 1885 default mandatory protocol set for GIMPS, the need to support new 1886 protocols in the future cannot be ruled out, and secure feature 1887 negotation cannot be added to an existing protocol in a backwards- 1888 compatible way. Therefore, some sort of negotiation capability is 1889 required. 1891 Protocol negotiation is carried out in GIMPS-Query/Response messages, 1892 using Stack-Proposal and Stack-Configuration-Data objects. If a new 1893 messaging association is required it is then set up, followed by a 1894 GIMPS-Confirm. Messaging association re-use is achieved by short- 1895 circuiting this exchange by sending the GIMPS-Response or GIMPS- 1896 Confirm messages on an existing association (Section 4.4.2); whether 1897 to do this is a matter of local policy. The end result of the 1898 negotiation is a messaging association which is a stack of protocols. 1899 If multiple associations exist, it is a matter of local policy how to 1900 distribute messages over them, subject to respecting the transfer 1901 attributes requested for each message. 1903 Every possible protocol for a messaging association has the following 1904 attributes: 1906 o MA-Protocol-ID, a 1-byte IANA assigned value. 1908 o A specification of the (non-negotiable) policies about how the 1909 protocol should be used (for example, in which direction a 1910 connection should be opened). 1912 o Formats for carrying the protocol addressing and other 1913 configuration information in higher-layer-addressing information 1914 elements in the Stack-Configuration-Data object. There are 1915 different formats depending on whether the information is carried 1916 in the Query or Response. 1918 A Stack-Proposal object is simply a list of profiles; each profile is 1919 a sequence of MA-Protocol-IDs. A Stack-Proposal is generally 1920 accompanied by a Stack-Configuration-Data object which carries a 1921 higher-layer-addressing information element for every protocol listed 1922 in the Stack-Proposal. A node generating a Stack-Configuration-Data 1923 object is committed to honouring the implied protocol configuration; 1924 in particular, it must be immediately prepared to accept incoming 1925 datagrams or connections at the protocol/port combinations 1926 advertised. However, the object contents should be retained only for 1927 the duration of the Query/Response exchange and any following 1928 association setup and afterwards discarded. (They may become invalid 1929 because of expired bindings at intermediate NATs, or because the 1930 advertising node is using agile ports.) 1932 A GIMPS-Query requesting association setup always contains a Stack- 1933 Proposal and Stack-Configuration-Data object, and unless re-use 1934 occurs, the GIMPS-Response does so also. For a GIMPS-Response, the 1935 Stack-Proposal must be invariant for the combination of outgoing 1936 interface and NSLPID (it must not depend on the GIMPS-Query). Once 1937 the messaging association is set up, the querying node repeats the 1938 responder's Stack-Proposal over it in the GIMPS-Confirm. The 1939 responding node can verify this to ensure that no bidding-down attack 1940 has occurred. 1942 5.7.2 Protocol Definition: Forwards-TCP 1944 This defines a basic configuration for the use of TCP between peers. 1945 Support for this protocol is mandatory; associations using it can 1946 carry messages with the transfer attribute Reliable=True. The 1947 connection is opened in the forwards direction, from the querying 1948 node, towards the responder at a previously advertised port. The 1949 higher-layer-addressing formats are: 1951 o downstream: no higher-layer-addressing field is needed. 1953 o upstream: 2 byte port number at which the connection will be 1954 accepted. 1956 5.7.3 Additional Protocol Options 1958 It is expected that the base GIMPS specification will define a single 1959 mandatory protocol for channel security (one of IKE/IPsec or TLS). 1960 Further protocols or configurations could be defined in the future 1961 for additional performance or flexibility. Examples are: 1963 o SCTP or DCCP as alternatives to TCP, with essentially the same 1964 configuration. 1966 o SigComp [20] for message compression. 1968 o ssh [29] or HIP/IPsec [30] for channel security. 1970 o Alternative modes of TCP operation, for example where it is set up 1971 from the responder to the querying node. 1973 5.8 Specific Message Routing Methods 1975 Each message routing method (see Section 3.3) requires the definition 1976 of the format of the message routing information (MRI) and Query- 1977 encapsulation rules. These are given in the following subsections 1978 for the various possible message routing methods. 1980 5.8.1 The Path-Coupled MRM 1982 5.8.1.1 Message Routing Information 1984 For the path-coupled MRM, this is just the Flow Identifier as in 1985 [24]. Minimally, this could just be the flow destination address; 1986 however, to account for policy based forwarding and other issues a 1987 more complete set of header fields should be used (see Section 7.2 1988 and Section 7.3 for further discussion). 1990 MRI = network-layer-version 1991 source-address prefix-length 1992 destination-address prefix-length 1993 IP-protocol 1994 diffserv-codepoint 1995 [ flow-label ] 1996 [ ipsec-SPI / L4-ports] 1998 Additional control information defines whether the flow-label, SPI 1999 and port information are present, the direction of the signalling 2000 message relative to this flow, and whether the IP-protocol and 2001 diffserv-codepoint fields should be interpreted as significant. The 2002 source and destination addresses should be host addresses, but prefix 2003 lengths other than 32/128 (for IPv4/6) can be provided to implement 2004 address 'wildcarding', allowing the MRI to refer to traffic to or 2005 from a wider address range. 2007 5.8.1.2 Downstream Query Encapsulation 2009 Where the signalling message is travelling in the same ('downstream') 2010 direction as the flow defined by the MRI, the IP addressing for Query 2011 messages is as follows: 2013 o The destination address MUST be the flow destination address as 2014 given in the MRI of the message payload. 2016 o By default, the source address is the flow source address, again 2017 from the MRI. This provides the best likelihood that the message 2018 will be correctly routed through any region which performs per- 2019 packet policy-based forwarding or load balancing which takes the 2020 source address into account. However, there may be circumstances 2021 where the use of the signaling source address is preferable, 2022 specifically: 2024 * In order to receive ICMP error messages about the Query message 2025 (such as unreachable port or address). If these are delivered 2026 to the flow source rather than the signaling source, it will be 2027 very difficult for the querying node to detect that it is the 2028 last GIMPS node on the path. 2030 * In order to attempt to run GIMPS through an unmodified NAT, 2031 which will only process and translate IP addresses in the IP 2032 header. 2034 Because of these considerations, use of the signaling source 2035 address is allowed as an option, with use based on local policy. 2036 A node SHOULD use the flow source address for initial Query 2037 messages, but MAY transition to the signaling source address for 2038 retransmissions or as a matter of static configuration (e.g. if a 2039 NAT is known to be in the path out of a certain interface). A 2040 flag in the common header tells the message receiver which option 2041 was used. 2043 It is vital that the Query message mimics the actual data flow as 2044 closely as possible, since this is the basis of how the signaling 2045 message is attached to the data path. To this end, GIMPS may set the 2046 DiffServ codepoint and (for IPv6) flow label to match the values in 2047 the MRI if this would be needed to ensure correct routing. 2049 Any message sent in datagram mode should be below a conservative 2050 estimate of the path MTU (e.g. 512 bytes). It is possible that 2051 fragmented datagrams including an RAO will not be correctly handled 2052 in the network, so the sender may set the DF (do not fragment) bit in 2053 the IPv4 header in order to detect that a message has encountered a 2054 link with an unusually low MTU. In this case, it must use the 2055 signalling source address for the IP source address in order to 2056 receive the ICMP error. 2058 A GIMPS implementation may apply validation checks to the MRI, to 2059 reject Query messages that are being injected by nodes with no 2060 legitimate interest in the flow being signalled for. In general, if 2061 the GIMPS node can detect that no flow could arrive over the same 2062 interface as the Query message, it should be rejected. (Such checks 2063 apply only to messages with the query encapsulation, since only those 2064 messages are required to track the flow path.) The main checks are 2065 that the IP version should match the version(s) used on that 2066 interface, and that the full range of source addresses (the source- 2067 address masked with its prefix-length) would pass ingress filtering 2068 checks. 2070 5.8.1.3 Upstream Query Encapsulation 2072 In some deployment scenarios it is desirable and logically possible 2073 to set up routing state in the upstream direction (from flow receiver 2074 towards the sender). This could be used to support firewall 2075 signaling to control traffic from an 'un-cooperative' sender, or 2076 signalling in general where the flow sender was not NSIS-capable. 2077 This can be incorporated into the GIMPS protocol structure by 2078 defining an encapsulation and processing rules for sending Query 2079 messages upstream. 2081 In general, it is not possible to determine the hop-by-hop route 2082 upstream because of asymmetric routing. However, in particular 2083 cases, the upstream peer can be discovered with a high degree of 2084 confidence, for example: 2086 o The upstream GIMPS peer is 1 IP hop away, and can be reached by 2087 tracing back through the interface on which the flow arrives. 2089 o The upstream peer is a border router of a single-home (stub) 2090 network. 2092 This section defines an upstream Query encapsulation and validation 2093 checks for when it can be used. The functionality to generate 2094 upstream Queries is optional, but if received they should be 2095 processed in the normal way (no special functionality is needed for 2096 this). It is possible for routing state (for a given MRI and NSLPID) 2097 to be installed by both upstream and downstream Query exchanges. If 2098 the SIDs are different, these items of routing state should be 2099 considered as independent; if they match, that installed by the 2100 downstream exchange should take precedence. 2102 The details of the encapsulation are as follows: 2104 o The destination address SHOULD be the flow source address as given 2105 in the MRI of the message payload. An implementation with more 2106 detailed knowledge of local routing MAY use an alternative 2107 destination address (e.g. the address of its default router). 2109 o The source address SHOULD be the signalling node address. 2111 o The DiffServ codepoint and (for IPv6) flow label may be set to 2112 match the values from the MRI, as in the downstream case. The 2113 same considerations about message size and fragmentation also 2114 apply as in the downstream case, and RAO setting and UDP port 2115 selection are also the same. 2117 o The IP-TTL of the message MUST be set to 255. 2119 The sending GIMPS implementation should attempt to send the Query 2120 message out of the same interface and to the same link layer 2121 neighbour from which the data packets of the flow are arriving. 2123 The receiving GIMPS implementation may apply validation checks to the 2124 message and MRI, to reject Query messages which have reached a node 2125 at which they can no longer be trusted. In particular, a node may 2126 reject a message which has been propagated more than one IP hop, with 2127 a "Invalid IP TTL" error message (Appendix C.5.4.12). This can be 2128 determined by examining the received IP TTL, similar to the 2129 generalised IP TTL security mechanism described in [23]. 2130 Alternatively, receipt of an upstream Query at the flow source may be 2131 used to trigger setup of NTLP state in the downstream direction. 2132 These restrictions may be relaxed in a future version. 2134 5.8.2 The Loose-End MRM 2136 This MRM is used to discover GIMPS nodes with particular properties 2137 in the direction of a given address, for example to discover a NAT 2138 along the upstream data path. It is based on work originally 2139 documented in [33]. 2141 5.8.2.1 Message Routing Information 2143 For the loose-end MRM, only a simplified version of the Flow 2144 Identifier is required. 2146 MRI = network-layer-version 2147 source-address 2148 destination-address 2150 The source address is the address of the node initiating the 2151 discovery process, for example the node that will be the data 2152 receiver in the NAT discovery case. The destination address is the 2153 address of a node which is expected to be the 'other side' of the 2154 node to be discovered. Additional control information defines the 2155 direction of the message relative to this flow. 2157 5.8.2.2 Downstream Query Encapsulation 2159 Only one encapsulation is defined for the loose-end MRM; by 2160 convention, this is referred to as the downstream encapsulation, and 2161 is defined as follows: 2163 o The IP destination address MUST be the destination address as 2164 given in the MRI of the message payload. 2166 o By default, the IP source address is the source address, again 2167 from the MRI. However, there may be circumstances where the use 2168 of the signaling source address is preferable, specifically: 2170 * In order to receive ICMP error messages about the Query message 2171 (such as unreachable port or address). If these are delivered 2172 to the MRI source rather than the signaling source, it will be 2173 very difficult for the querying node to detect that it is the 2174 last GIMPS node on the path. 2176 * In order to attempt to run GIMPS through an unmodified NAT, 2177 which will only process and translate IP addresses in the IP 2178 header. 2180 Because of these considerations, use of the signaling source 2181 address is allowed as an option, with use based on local policy. 2182 A node SHOULD use the MRI source address for initial Query 2183 messages, but MAY transition to the signaling source address for 2184 retransmissions or as a matter of static configuration. A flag in 2185 the common header tells the message receiver which option was 2186 used. 2188 There are no special requirements on the setting of the DiffServ 2189 codepoint, IP TTL, or (for IPv6) the flow label. Nor are any special 2190 validation checks applied. 2192 Any message sent in datagram mode should be below a conservative 2193 estimate of the path MTU (e.g. 512 bytes). It is possible that 2194 fragmented datagrams including an RAO will not be correctly handled 2195 in the network, so the sender may set the DF (do not fragment) bit in 2196 the IPv4 header in order to detect that a message has encountered a 2197 link with an unusually low MTU. In this case, it must use the 2198 signalling source address for the IP source address in order to 2199 receive the ICMP error. 2201 6. Formal Protocol Specification 2203 This section provides a more formal specification of the operation of 2204 GIMPS processing, in terms of rules for transitions between states of 2205 a set of communicating state machines within a node. 2207 Conceptually, the operation of GIMPS processing at a node may be seen 2208 as the cooperation of 4 types of state machine: 2210 1. There is a top-level state machine which represents the node 2211 itself (Node-SM). This is responsible for the processing of 2212 events which cannot be directed towards a more specific state 2213 machine, for example, inbound messages for which no per-flow 2214 routing state currently exists. This machine exists permanently, 2215 and is responsible for creating 'per-flow' state machines to 2216 manage the operation of the GIMPS handshake and routing state 2217 maintenance procedures. 2219 2. For each flow and signalling direction where the node is 2220 responsible for initiating the creation of routing state, there 2221 is an instance of a Query-Node Routing state machine (Query-SM). 2222 This machine sends Query and Confirm messages and waits for 2223 Responses, according to the requirements from locally generated 2224 API commands or timer processing (e.g. message repetition or 2225 routing state refresh). 2227 3. For each flow and signalling direction where the node has 2228 accepted the creation of routing state by a peer, there is an 2229 instance of a Responding-Node Routing state machine 2230 (Response-SM). This machine is responsible for managing the 2231 status of the routing state for that flow. In some cases, it is 2232 also responsible for [re]transmission of Response messages; 2233 however, in many cases, the generation of Response messages is 2234 handled by the Node-SM, and a Response-SM is not even created for 2235 a flow until a properly formatted Confirm has been accepted. 2237 4. Messaging assocations have their own lifecycle, represented by 2238 MA-SM, from when they are first created (in an 'incomplete' 2239 state, listening for an inbound connection or waiting for 2240 outbound connections to complete), to when they are active and 2241 available for use. 2243 Note that, apart from the fact that the various machines can be 2244 created and destroyed by each other, there is almost no interaction 2245 between them. The machines for different flows do not interact; the 2246 Query-SM and Response-SM for a single flow and signalling direction 2247 do not interact. That is, the Response-SM which accepts the creation 2248 of routing state for a flow on one interface has no direct 2249 interaction with the Query-SM which sets up routing state on the next 2250 interface along the path. This interaction is mediated instead 2251 through the NSLP. 2253 The state transition diagrams use the following terminology for event 2254 naming: 2256 o rx_ = a message received event. The rest of the event name is the 2257 name of the message 2259 o tg_ = a trigger event, either from the API or from another 2260 internal state machine. 2262 o to_ = a timeout event. 2264 o er_ = an error indication event. This may be filtered back to the 2265 NSLP. 2267 6.1 Node Processing 2269 The Node level state machine is responsible for processing events for 2270 which no more appropriate messaging association state or routing 2271 state exists. Its structure is trivial: there is a single state 2272 ('Idle'); all events cause a transition back to Idle. Some events 2273 cause the creation of other state machines. 2275 Incoming Events: 2277 +----------------+---------------------------------------------+ 2278 | Name | Meaning | 2279 +----------------+---------------------------------------------+ 2280 | rx_Query | A GIMPS Query message has been received. | 2281 | | | 2282 | rx_Response | A GIMPS Response message has been received. | 2283 | | | 2284 | rx_Confirm | A GIMPS Confirm message has been received. | 2285 | | | 2286 | rx_Data | A GIMPS Data message has been received. | 2287 | | | 2288 | tg_SendMessage | A SendMessage event from the API. | 2289 +----------------+---------------------------------------------+ 2291 Predicates: 2293 +------------------+------------------------------------------------+ 2294 | Name | Meaning | 2295 +------------------+------------------------------------------------+ 2296 | paranoid | The combination of local policy and transfer | 2297 | | attributes mean that the node will not allow | 2298 | | routing state to be created for a flow until | 2299 | | the full Q/R/C sequence is complete. This | 2300 | | corresponds to case 4 of the possible Q/R/C | 2301 | | sequences. | 2302 +------------------+------------------------------------------------+ 2304 State Transition Table: 2306 +----------------+---------------------+ 2307 | Incoming Event | Rule in state: Idle | 2308 +----------------+---------------------+ 2309 | rx_Query | Rule 1 | 2310 | | | 2311 | rx_Response | Rule 2 | 2312 | | | 2313 | rx_Confirm | Rule 3 | 2314 | | | 2315 | rx_Data | Rule 4 | 2316 | | | 2317 | tg_SendMessage | Rule 5 | 2318 +----------------+---------------------+ 2320 The processing rules are as follows: 2322 Rule 1: 2324 if !paranoid 2325 create R-SM 2326 pass message to it 2327 else 2328 send Response 2329 [Next state: Idle] 2331 Rule 2: 2333 // must already have a Q-SM to be receiving this 2334 discard message 2335 send Err_NoRtgState message 2336 [Next state: Idle] 2337 Rule 3: 2339 if !paranoid 2340 // should already have R-SM for it 2341 discard message 2342 send Err_NoRtgState message 2343 else 2344 create R-SM 2345 pass message to it 2346 [Next state: Idle] 2348 Rule 4: 2350 pass directly to NSLP 2351 [Next state: Idle] 2353 Rule 5: 2355 if Q-mode encapsulation is not possible for this MRI 2356 reject message with an error 2357 else 2358 if local policy & transfer attributes say routing state is not needed 2359 send message statelessly 2360 else 2361 create Q-SM 2362 pass message to it 2363 [Next state: Idle] 2365 6.2 Query Node Processing 2367 The Querying-Node state machine (Q-SM) has three states: 2369 o Awaiting Response 2371 o Established 2373 o Awaiting Refresh 2375 The Q-SM is created by the N-SM machine as a result of a request to 2376 send a message for a flow in a signalling direction where the 2377 appropriate state does not exist. The Query is generated 2378 immediately, and the machine transitions to the Awaiting Response 2379 state, in which timout-based retransmissions are handled. Once a 2380 Response has been successfully recieved and routing state created, 2381 the machine transitions to Established, during which NSLP data can be 2382 sent and received normally. The Awaiting Refresh state can be 2383 considered as a substate of Established, where a new Query has been 2384 generated to refresh the routing state (as in Awaiting Response) but 2385 NSLP data can be handled normally. 2387 tg_Initialise_QNode +-----+ 2388 -------------------------|Birth| 2389 | +-----+ 2390 | 2391 | 2392 | tg_NSLP_Data 2393 | tg_NSLP_Data er_No_RSM || rx_Data 2394 | -------- -------------------- -------- 2395 | | V | || V 2396 | | V | || V 2397 | +----------+ | +-----------+ 2398 ---->>| Awaiting | ---------------->> |Established| 2399 ------| Response |------------------------------>> | | 2400 | +----------+ rx_Response +-----------+ 2401 | ^ | ^ | 2402 | ^ | ^ | 2403 | -------- | | 2404 | to_No_Response | | 2405 | [!nResp_reached] tg_NSLP_Data | | 2406 | || rx_Data | | 2407 | -------- | | 2408 | | V | | 2409 | to_No_Response | V | | 2410 | [nResp_reached] +-----------+ rx_Response | | 2411 ---------- ------------| Awaiting |----------------- | 2412 | | | Refresh |<<------------------- 2413 | | +-----------+ to_Refresh_QNode 2414 | | ^ | || tg_Rtg_Update 2415 | | ^ | 2416 | | -------- 2417 | | to_No_Response 2418 | | [!nResp_reached] 2419 V V 2420 V V 2421 +-----+ 2422 |Death|<<--------------- 2423 +-----+ to_Inactive_QNode 2424 (from all states) 2426 Figure 6: Query Node State Machine 2428 Incoming Events: 2430 +------------------------+------------------------------------------+ 2431 | Name | Meaning | 2432 +------------------------+------------------------------------------+ 2433 | tg_Initialise_QNode | This RS has just been created. | 2434 | | | 2435 | rx_Response | A Response message is received. | 2436 | | | 2437 | rx_Data | A data only message is received. | 2438 | | | 2439 | rx_Err_NoRtgState | An error message is received from the | 2440 | | peer node indicating that it received a | 2441 | | data message for which there is no | 2442 | | stored routing state. | 2443 | | | 2444 | tg_NSLP_Data | An event is received requesting | 2445 | | transmission of a message. | 2446 | | | 2447 | tg_Set_QNode_Lifetime | An event is received from the API | 2448 | | setting the lifetime of the routing | 2449 | | state associated with this SM. This | 2450 | | event sets the period of the | 2451 | | Inactive_QNode timer. | 2452 | | | 2453 | tg_NetNotification | An event is recieved indicating that the | 2454 | | routing state associated with this state | 2455 | | machine is invalid. | 2456 | | | 2457 | to_Refresh_QNode | A timeout is received indicating that | 2458 | | the routing state associated with this | 2459 | | state machine should be refreshed. | 2460 | | | 2461 | to_No_Response | A timeout is received indicating that no | 2462 | | Response has been received in answer to | 2463 | | a Query. | 2464 | | | 2465 | to_Inactive_QNode | This Q-Node is inactive an can be | 2466 | | deleted. | 2467 +------------------------+------------------------------------------+ 2468 Timers: 2470 +---------------------+---------------------------------------------+ 2471 | Name | Meaning | 2472 +---------------------+---------------------------------------------+ 2473 | Refresh_QNode | Indicates when the routing state stored by | 2474 | | this state machine needs to be refreshed. | 2475 | | It is reset whenever a Response is received | 2476 | | indicating that the routing state is still | 2477 | | valid. The period of this timer is set by | 2478 | | the RS-validity-time field of a Reponse | 2479 | | message. | 2480 | | | 2481 | No_Response | Indicates that a Response has not been | 2482 | | received in answer to a Query. This is | 2483 | | started whenever a Query is sent and | 2484 | | stopped when a Response is received. | 2485 | | | 2486 | Inactive_QNode | Indicates that no traffic is currently | 2487 | | being handled by this state machine. This | 2488 | | is reset whenever the state machine handles | 2489 | | NSLP data (in either direction). The period | 2490 | | of this timer is set via the API. | 2491 +---------------------+---------------------------------------------+ 2492 State Transition Table 2494 +-------------------+-----------+-----------+-----------+-----------+ 2495 | Incoming Event | Rule in | Rule in | Rule in | Rule in | 2496 | | state: | state: | state: | state: | 2497 | | Birth | Awaiting | Establish | Awaiting | 2498 | | | Response | ed | Refresh | 2499 +-------------------+-----------+-----------+-----------+-----------+ 2500 | tg_Initialise_QNo | Rule 1 | Rule - | Rule - | Rule - | 2501 | de | | | | | 2502 | | | | | | 2503 | rx_Response | Rule - | Rule 2 | Rule s | Rule 2 | 2504 | | | | | | 2505 | rx_Data | Rule - | Rule 10 | Rule 7 | Rule 7 | 2506 | | | | | | 2507 | rx_Err_NoRtgState | Rule - | Rule - | Rule 11 | Rule - | 2508 | | | | | | 2509 | tg_NSLP_Data | Rule - | Rule 3 | Rule 8 | Rule 8 | 2510 | | | | | | 2511 | tg_Set_QNode_Life | Rule - | Rule 4 | Rule 4 | Rule 4 | 2512 | time | | | | | 2513 | | | | | | 2514 | tg_NetNotificatio | Rule - | Rule - | Rule 5 | Rule - | 2515 | n | | | | | 2516 | | | | | | 2517 | to_Refresh_QNode | Rule - | Rule - | Rule 5 | Rule - | 2518 | | | | | | 2519 | to_No_Response | Rule - | Rule 6 | Rule - | Rule 6 | 2520 | | | | | | 2521 | to_Inactive_Qnode | Rule - | Rule - | Rule 9 | Rule 9 | 2522 +-------------------+-----------+-----------+-----------+-----------+ 2524 The processing rules are as follows: 2526 Rule s: 2528 silently Ignore 2529 [Next state: Present State] 2531 Rule -: 2533 // This event/state combination should never occur 2534 raise fatal error 2535 [Next state: Death] 2536 Rule 1: 2538 if local policy & transfer attributes allow D-mode 2539 include NSLP data in Query 2540 else 2541 store NSLP data for later transmission 2542 send Query message 2543 start No_Response timer 2544 store any security 2545 handle from the API 2546 [Next state: Awaiting Response] 2548 Rule 2: 2550 if an MA-SM is needed 2551 create one 2552 if a Confirm is required 2553 send Confirm message* 2554 pass any NSLP data to the NSLP 2555 send any 2556 stored Data messages 2557 stop No_Response timer 2558 start Refresh_QNode timer 2559 start Inactive_QNode timer 2560 [Next state: Established] 2562 Rule 3: 2564 store message 2565 [Next state: Awaiting Response] 2567 Rule 4: 2569 restart Inactive_QNode timer with new value 2570 [Next state: Present State] 2572 Rule 5: 2574 send Query message* 2575 start No_Response timer 2576 stop Refresh_QNode timer 2577 [Next state: Awaiting Refresh] 2579 Rule 6: 2581 if number of Queries sent has reached the threshold 2582 // nQuery_isMax is true 2583 indicate No Response error to NSLP 2584 destroy self 2585 [Next state: Death] 2586 else 2587 send Query message* 2588 start No_Response timer with new value 2589 [Next state: Present State] 2591 Rule 7: 2593 pass any data to the NSLP 2594 (re)start Inactive_QNode timer 2595 [Next state: Present State] 2597 Rule 8: 2599 send Data message 2600 restart Inactive_QNode timer 2601 [Next state: Present State] 2603 Rule 9: 2605 destroy self 2606 [Next state: Death] 2608 Rule 10: 2610 // This should never happen but may indicate a lost Response 2611 send Query message* 2612 start No_Response timer 2613 stop Refresh_QNode timer 2614 [Next state: Present State] 2616 Rule 11: 2618 // Assume the Confirm was lost in transit so resend it 2619 send Confirm message 2620 restart Refresh_QNode timer 2621 restart Inactive_QNode timer 2622 [Next state: Present State] 2624 6.3 Responder Node Processing 2626 The Responding-Node state machine (R-SM) has three states: 2628 o Awaiting Confirm 2630 o Established 2632 o Awaiting Refresh 2634 The policy governing the creation of the R-SM has 4 cases, and these 2635 affect which state the state machine enters first: 2637 1. No state machine is ever created (there is a single Query- 2638 Response exchange but the responder never stores backwards 2639 routing state and there is no Confirm). 2641 2. The R-SM is created on receipt of a Query message, but no Confirm 2642 is requested. 2644 3. The R-SM is again created on receiving a Query, but a Confirm is 2645 requested. A timer is used to generate retransmitted Response 2646 messages and the R-SM is destroyed if a valid Confirm message is 2647 not forthcoming after some number of them. 2649 4. The R-SM cannot be created until a valid Confirm message is 2650 received. 2652 In case 4 the R-SM is created in the Awaiting Confirm state. The 2653 R-SM remains in this state until a Confirm is received, at which 2654 point it transitions to the Established state. In cases 2 and 3 the 2655 R-SM is created already in the Established state. In Established 2656 state the NSLP can send and receive data normally. The Awaiting 2657 Refresh state can be considered a substate of Established, where a 2658 Query has been received to begin the routing state refresh. In this 2659 state the R-SM behaves as in the Awaiting Confirm state, except that 2660 the NSLP can still send and receive data. 2662 rx_Query rx_Query 2663 [confirmRequired] +-----+ [!confirmRequired] 2664 -------------------------|Birth|---------------------------- 2665 | +-----+ | 2666 | | rx_Confirm | 2667 | ---------------------------- | 2668 | | | 2669 | | | 2670 | tg_NSLP_Data | | 2671 | || rx_Data | | 2672 | || rx_Query | | 2673 | tg_NSLP_Data [!confirmRequired] | | 2674 | -------- -------------- | | 2675 | | V | V V V 2676 | | V | V V V 2677 | +----------+ | +-----------+ 2678 ---->>| Awaiting | rx_Confirm -----------|Established| 2679 ------| Confirm |------------------------------>> | | 2680 | +----------+ +-----------+ 2681 | ^ | ^ | 2682 | ^ | ^ | 2683 | -------- | | 2684 | to_No_Confirm | | 2685 | [!nConf_reached] tg_NSLP_Data | | 2686 | || rx_Data | | 2687 | -------- | | 2688 | | V | | 2689 | to_No_Confirm | V | | 2690 | [nConf_reached] +-----------+ rx_Confirm | | 2691 ---------- ------------| Awaiting |----------------- | 2692 | | | Refresh |<<------------------- 2693 | | +-----------+ rx_Query 2694 | | ^ | [confirmRequired] 2695 | | ^ | 2696 | | -------- 2697 | | to_No_Confirm 2698 | | [!nConf_reached] 2699 V V 2700 V V 2701 +-----+ 2702 |Death|<<--------------------- 2703 +-----+ to_Expire_RNode 2704 (from all states) 2706 Figure 7: Responder Node State Machine 2708 Incoming Events: 2710 +------------------------+------------------------------------------+ 2711 | Name | Meaning | 2712 +------------------------+------------------------------------------+ 2713 | rx_Query | Node receives a Query message. | 2714 | | | 2715 | rx_Data | Node receives a data message. | 2716 | | | 2717 | rx_Confirm | Node receives a Confirm message. | 2718 | | | 2719 | tg_NSLP_Data | A SendMessage event is received from the | 2720 | | API requesting transmission of a | 2721 | | message. | 2722 | | | 2723 | tg_Invalidate | An event is recieved, from the N-SM or | 2724 | | the RC-SM marking the routing state | 2725 | | associated with this SM as invalid. | 2726 | | | 2727 | to_Expire_RNode | A timeout is received indicating that | 2728 | | the RS should be expired immediately. | 2729 | | Note: state may not be refreshed from | 2730 | | the R-Node | 2731 | | | 2732 | to_No_Confirm | A timeout is received indicating that we | 2733 | | have not received a confirm for this RS | 2734 | | where one was expected. | 2735 +------------------------+------------------------------------------+ 2737 Timers: 2739 +---------------------+---------------------------------------------+ 2740 | Name | Meaning | 2741 +---------------------+---------------------------------------------+ 2742 | Expire_RNode | Indicates when the routing state stored by | 2743 | | this state machine needs to be expired. It | 2744 | | is reset whenever a Query or Confirm | 2745 | | (depending on local policy) is received | 2746 | | indicating that the routing state is still | 2747 | | valid. | 2748 | | | 2749 | No_Confirm | Indicates that a Confirm has not been | 2750 | | received in answer to a Response. This is | 2751 | | started / reset whenever a Response is sent | 2752 | | and stopped when a Confirm is received. | 2753 +---------------------+---------------------------------------------+ 2754 State Transition Table 2756 +-------------------+-----------+-----------+-----------+-----------+ 2757 | Incoming Event | Rule in | Rule in | Rule in | Rule in | 2758 | | state: | state: | state: | state: | 2759 | | [Start] | Awaiting | Establish | Awaiting | 2760 | | | Confirm | ed | Refresh | 2761 +-------------------+-----------+-----------+-----------+-----------+ 2762 | rx_Query | 1 | s | 9 | s | 2763 | | | | | | 2764 | rx_Confirm | 2 | 3 | s | 3 | 2765 | | | | | | 2766 | rx_Data | - | 10 | 7 | 7 | 2767 | | | | | | 2768 | tg_NSLP_Data | - | 5 | 4 | 4 | 2769 | | | | | | 2770 | to_Expire_RNode | - | 8 | 8 | 8 | 2771 | | | | | | 2772 | to_No_Confirm | - | 6 | - | 6 | 2773 +-------------------+-----------+-----------+-----------+-----------+ 2775 The processing rules are as follows: 2777 Rule -: 2779 // This event/state combination should never occur 2780 raise fatal error 2781 [Next state: Death] 2783 Rule s: 2785 silently Ignore 2786 [Next state: Present State] 2788 Rule 1: 2790 if MA-SM is needed 2791 create one 2792 if local policy & transfer attributes require a Confirm message 2793 // confirmRequired is true 2794 send Response message* 2795 start No_Confirm timer 2796 [Next state: Awaiting Confirm] 2797 else 2798 send Response message* 2799 start Expire_RNode timer 2800 [Next state: Established] 2802 Rule 2: 2804 if MA-SM is needed 2805 create one 2806 start Expire_RNode timer 2807 [Next state: Established] 2809 Rule 3: 2811 send any stored Data messages* 2812 stop No_Confirm timer 2813 start Expire_RNode timer 2814 [Next state: Established] 2816 Rule 4: 2818 send Data message* 2819 [Next state: Present State] 2821 Rule 5: 2823 store Data message 2824 [Next state: Present State] 2826 Rule 6: 2828 if number of Responses sent has reached threshold 2829 // nResp_isMax is true 2830 destroy self 2831 [Next state: Death] 2832 else 2833 send Response message* 2834 start No_Response timer 2835 [Next state: Present State] 2837 Rule 7: 2839 pass data to NSLP 2840 [Next state: Present State] 2842 Rule 8: 2844 destroy self 2845 [Next state: Death] 2846 Rule 9: 2848 stop Expire_RNode timer 2849 if local policy & transfer attributes require a Confirm message 2850 // confirmRequired is true 2851 send Response message* 2852 start No_Confirm timer 2853 [Next state: Awaiting Refresh] 2854 else 2855 send Response message* 2856 start Expire_RNode timer 2857 [Next state: Established] 2859 Rule 10: 2861 send Err_NoRtgState message* 2862 [Next state: Present State] 2864 6.4 Messaging Association Processing 2866 Messaging associations are modelled for use within GIMPS with a 2867 simple 3-state process. The two main states indicate that the 2868 messaging association is either waiting for the connection process to 2869 complete, or open and ready to use. In addition there is an 2870 'Uninterested' state in which the local node no longer requires the 2871 messaging association but the remote node still requires it to be 2872 kept open. 2874 Clearly, many internal details of the messaging assocation protocols 2875 are hidden in this model, especially where the messaging association 2876 uses multiple protocol layers; however, the specification of these is 2877 left up to the individual protocol definitions. Note also that 2878 although the existence of messaging associations is not directly 2879 visible to NSLPs, there is some interaction between the two because 2880 security-related information becomes available during the open 2881 process, and this may be indicated to signalling applications if they 2882 have requested it. 2884 tg_Initialise_MA +-----+ 2885 ----------------------------|Birth| 2886 | +-----+ 2887 | 2888 | tg_Send_Message 2889 || rx_Data 2890 || rx_Hello 2891 | tg_Send_Message || to_SendHello 2892 | -------- -------- 2893 | | V | V 2894 | | V | V 2895 | +----------+ +-----------+ 2896 ---->>| Awaiting | tg_Connected | Connected | 2897 ------|Connection|------------------------->>| | 2898 | +----------+ +-----------+ 2899 | ^ | 2900 | tg_Send_Message^ | 2901 | || rx_Data | |to_NoActivity 2902 | | V 2903 | | V 2904 | er_MA_Connect +-----+ to_NoHello +-----------+ 2905 --------------->>|Death|<<-------------------| Idle | 2906 +-----+ | | 2907 ^ +-----------+ 2908 ^ ^ | 2909 | ^ | 2910 ----------------- -------- 2911 er_MA_Failure rx_Hello 2912 (from all states) 2914 Figure 8: Messaging Association State Machine 2916 Incoming Events 2918 +------------------------+------------------------------------------+ 2919 | Name | Meaning | 2920 +------------------------+------------------------------------------+ 2921 | to_NoActivity | A timeout is received indicating that | 2922 | | there has not been any activity on this | 2923 | | node for a period of time. | 2924 | | | 2925 | to_SendHello | A timeout is received indicating that an | 2926 | | MAHello message should be sent to the | 2927 | | remote node. | 2928 | | | 2929 | to_NoHello | A timeout is received indicating that an | 2930 | | MAHello has not been received from the | 2931 | | remote node for a period of time. | 2932 | | | 2933 | tg_Initialise_MA | This MA has just been created. | 2934 | | | 2935 | tg_Send_Data | A request has been made to send a C-Mode | 2936 | | message over this MA. | 2937 | | | 2938 | er_MA_Connect | An error occurred while creating the | 2939 | | connection. Either an active connect | 2940 | | failed, or no incoming connection was | 2941 | | received within a certain timeout. | 2942 | | | 2943 | tg_Connected | The connection to the peer has been | 2944 | | created. | 2945 | | | 2946 | rx_Data | A GIMPS Query, Response, Confirm or Data | 2947 | | message has been received over this MA. | 2948 | | | 2949 | rx_Hello | An MA-Hello message has been received | 2950 | | over this MA. | 2951 | | | 2952 | er_MA_Failure | The messaging association has been | 2953 | | destroyed by lower layer protocol | 2954 | | operations (e.g. TCP Reset). | 2955 +------------------------+------------------------------------------+ 2956 Timers: 2958 +------------------------+------------------------------------------+ 2959 | Name | Meaning | 2960 +------------------------+------------------------------------------+ 2961 | SendHello | Indicates that an MAHello message should | 2962 | | be sent to the remote node. The period | 2963 | | of this timer is determined by the | 2964 | | MA-Hold-Time sent by the remote node | 2965 | | during the Query/Response exchange. | 2966 | | | 2967 | NoHello | Indicates that no MAHello has been | 2968 | | received from the remote node for a | 2969 | | period of time. The period of this timer | 2970 | | is sent to the remote node as the | 2971 | | MA-Hold-Time during the Query/Response | 2972 | | exchange. | 2973 | | | 2974 | NoActivity | Indicates that the link has been | 2975 | | inactive for a period of time. The | 2976 | | period of this timer is implementation | 2977 | | specific but is likely to be related to | 2978 | | the period of the NoHello timer. | 2979 +------------------------+------------------------------------------+ 2980 State Transition Table 2982 +------------+------------+-------------+-------------+-------------+ 2983 | Incoming | Rule in | Rule in | Rule in | Rule in | 2984 | Event | state: | state: | state: | state: | 2985 | | [Start] | Awaiting | Connected | Inactive | 2986 | | | Connection | | | 2987 +------------+------------+-------------+-------------+-------------+ 2988 | tg_Initial | Rule 1 | Rule - | Rule - | Rule - | 2989 | ise_MA | | | | | 2990 | | | | | | 2991 | tg_Send_Da | Rule - | Rule 2 | Rule 5 | Rule 5 | 2992 | ta | | | | | 2993 | | | | | | 2994 | er_MA_Conn | Rule - | Rule 3 | Rule - | Rule - | 2995 | ect | | | | | 2996 | | | | | | 2997 | tg_Connect | Rule - | Rule 4 | Rule - | Rule - | 2998 | ed | | | | | 2999 | | | | | | 3000 | rx_Data | Rule - | Rule - | Rule 6 | Rule 6 | 3001 | | | | | | 3002 | rx_Hello | Rule - | Rule - | Rule 7 | Rule 7 | 3003 | | | | | | 3004 | er_MA_Fail | Rule - | Rule - | Rule 3 | Rule 3 | 3005 | ure | | | | | 3006 | | | | | | 3007 | to_NoActiv | Rule - | Rule - | Rule 9 | Rule - | 3008 | ity | | | | | 3009 | | | | | | 3010 | to_SendHel | Rule - | Rule - | Rule 8 | Rule - | 3011 | lo | | | | | 3012 | | | | | | 3013 | to_NoHello | Rule - | Rule - | Rule - | Rule 3 | 3014 +------------+------------+-------------+-------------+-------------+ 3016 The processing rules are as follows: 3018 Rule -: 3020 // This event/state combination should never occur 3021 raise fatal error 3022 [Next state: Death] 3023 Rule 1: 3025 // The precise action here depends on protocols used and directionality 3026 create listening endpoints or attempt an active connect 3027 start timers to detect connection failure if necessary 3028 [Next state: Awaiting Connection] 3030 Rule 2: 3032 queue message for later transmission 3033 [Next state: Awaiting Connection] 3035 Rule 3: 3037 destroy self 3038 [Next state: Death] 3040 Rule 4: 3042 pass outstanding queued messages to transport layer 3043 stop any timers controlling connection establishment 3044 start NoActivity timer 3045 start SendHello timer 3046 [Next state: Connected] 3048 Rule 5: 3050 pass message to transport layer 3051 (re)start NoActivity timer 3052 (re)start SendHello 3053 [Next state: Connected] 3055 Rule 6: 3057 pass message to N-SM 3058 (re)start NoActivity timer 3059 [Next state: Connected] 3061 Rule 7: 3063 if reply requested 3064 send MA-Hello 3065 restart NoHello timer 3066 [Next state: Present State] 3067 Rule 8: 3069 send MA-Hello message 3070 [Next state: Present State] 3072 Rule 9: 3074 stop NoActivity timer 3075 stop sendHello timer 3076 start NoHello timer 3077 [Next state: Inactive] 3079 7. Advanced Protocol Features 3081 7.1 Route Changes and Local Repair 3083 7.1.1 Introduction 3085 When re-routing takes place in the network, GIMPS and signaling 3086 application state needs to be updated for all flows whose paths have 3087 changed. The updates to signaling application state are usually 3088 signaling application dependent: for example, if the path 3089 characteristics have actually changed, simply moving state from the 3090 old to the new path is not sufficient. Therefore, GIMPS cannot carry 3091 out the complete path update processing. Its responsibilities are to 3092 detect the route change, update its own routing state consistently, 3093 and inform interested signaling applications at affected nodes. 3095 Route change management is complicated by the distributed nature of 3096 the problem. Consider the re-routing event shown in Figure 9. An 3097 external observer can tell that the main responsibility for 3098 controlling the updates will probably lie with nodes A and E; 3099 however, D1 is best placed to detect the event quickly at the GIMPS 3100 level, and B1 and C1 could also attempt to initiate the repair. 3102 On the assumption that NSLPs are soft-state based and operate end to 3103 end, and because GIMPS also periodically updates its picture of 3104 routing state, route changes will eventually be repaired 3105 automatically. However, especially if NSLP refresh times are 3106 extended to reduce signaling load, the duration of inconsistent state 3107 may be very long indeed. Therefore, GIMPS includes logic to deliver 3108 prompt notifications to NSLPs, to allow them to carry out local 3109 repair if possible. 3111 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3112 x +--+ +--+ +--+ x Initial 3113 x .|B1|_.......|C1|_.......|D1| x Configuration 3114 x . +--+. .+--+. .+--+\. x 3115 x . . . . . . x 3116 >>xxxxxx . . . . . . xxxxxx>> 3117 +-+ . .. .. . +-+ 3118 .....|A|/ .. .. .|E|_.... 3119 +-+ . . . . . . +-+ 3120 . . . . . . 3121 . . . . . . 3122 . +--+ +--+ +--+ . 3123 .|B2|_.......|C2|_.......|D2|/ 3124 +--+ +--+ +--+ 3126 +--+ +--+ +--+ Configuration 3127 .|B1|........|C1|........|D1| after failure 3128 . +--+ .+--+ +--+ of D1-E link 3129 . \. . \. ./ 3130 . . . . . 3131 +-+ . .. .. +-+ 3132 .....|A|. .. .. .|E|_.... 3133 +-+\. . . . . . +-+ 3134 >>xxxxxx . . . . . . xxxxxx>> 3135 x . . . . . . x 3136 x . +--+ +--+ +--+ . x 3137 x .|B2|_.......|C2|_.......|D2|/ x 3138 x +--+ +--+ +--+ x 3139 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3141 ........... = physical link topology 3143 >>xxxxxxx>> = flow direction 3145 _.......... = indicates outgoing link 3146 for flow xxxxxx given 3147 by local forwarding table 3149 Figure 9: A Re-Routing Event 3151 7.1.2 Route Change Detection 3153 There are two aspects to detecting a route change at a single node: 3155 o Detecting that the path in the direction of the Query has (or may 3156 have) changed. 3158 o Detecting that the path in the direction of the Response has (or 3159 may have) changed (in which case the node may no longer be on the 3160 path at all). 3162 At a single node, these processes are largely independent, although 3163 clearly a change in the path in one direction at a node corresponds 3164 to a change in path in the opposite direction at its peer. Note that 3165 there are two possible aspects of route change: 3167 Interface: The interface through which a flow leaves or enters a node 3168 may change. 3170 Peer: The adjacent peer may change. 3172 In general, a route change could include one or the other or both. 3173 (In theory it could include neither, although such changes are hard 3174 to detect and even harder to do anything useful about.) 3176 There are five mechanisms for a GIMPS node to detect that a route 3177 change has occurred, which are listed below. They apply differently 3178 depending on whether the change is in the Query or Response 3179 direction, and these differences are summarised in the following 3180 table. 3182 Local Trigger: In trigger mode, a node finds out that the next hop 3183 has changed. This is the RSVP trigger mechanism where some form 3184 of notification mechanism from the routing table to the protocol 3185 handler is assumed. Clearly this only works if the routing change 3186 is local, not if the routing change happens somewhere a few 3187 routing hops away (including the case that the change happens at a 3188 GIMPS-unaware node). 3190 Extended Trigger: An extended trigger, where the node checks a link- 3191 state routing table to discover that the path has changed. This 3192 makes certain assumptions on consistency of route computation (but 3193 you probably need to make those to avoid routing loops) and only 3194 works within a single area for OSPF and similar link-state 3195 protocols. Where available, this offers the most accurate and 3196 expeditious indication of route changes, but requires more access 3197 to the routing internals than a typical OS may provide. 3199 GIMPS C-mode Monitoring: A node may find that C-mode packets are 3200 arriving (from either peer) with a different TTL or on a different 3201 interface. This provides no direct information about the new flow 3202 path, but indicates that routing has changed and that rediscovery 3203 may be required. 3205 Data Plane Monitoring: The signaling application on a node may detect 3206 a change in behaviour of the flow, such as TTL change, arrival on 3207 a different interface, or loss of the flow altogether. The 3208 signaling application on the node is allowed to notify this 3209 information locally to GIMPS. 3211 GIMPS Probing: In probing mode, each GIMPS node periodically repeats 3212 the discovery (GIMPS-Query/GIMPS-Response) operation. The 3213 querying node will discover the route change by a modification in 3214 the Network-Layer-Information in the GIMPS-Response. This is 3215 similar to RSVP behavior, except that there is an extra degree of 3216 freedom since not every message needs to repeat the discovery, 3217 depending on the likely stability of routes. All indications are 3218 that, leaving mobility aside, routes are stable for hours and 3219 days, so this may not be necessary on a 30-second interval, 3220 especially if the other techniques listed above are available. 3222 When these methods discover a route change in the Response direction, 3223 this cannot be handled directly by GIMPS at the detecting node, since 3224 route discovery proceeds only in the Query direction. Therefore, to 3225 exploit these mechanisms, it must be possible for GIMPS to send a 3226 notification message to initiate this. (This would be possible for 3227 example by setting an additional flag in the Common-Header of a 3228 message.) 3230 +----------------------+----------------------+---------------------+ 3231 | Method | Query direction | Response direction | 3232 +----------------------+----------------------+---------------------+ 3233 | Local Trigger | Discovers new | Not applicable | 3234 | | interface (and peer | | 3235 | | if local) | | 3236 | | | | 3237 | Extended Trigger | Discovers new | May determine that | 3238 | | interface and may | route from peer | 3239 | | determine new peer | will have changed | 3240 | | | | 3241 | C-Mode Monitoring | Provides hint that | Provides hint that | 3242 | | change has occurred | change has occurred | 3243 | | | | 3244 | Data Plane | Not applicable | NSLP informs GIMPS | 3245 | Monitoring | | that a change may | 3246 | | | have occurred | 3247 | | | | 3248 | Probing | Discovers changed | Discovers changed | 3249 | | NLI in | NLI in GIMPS-Query | 3250 | | GIMPS-Response | | 3251 +----------------------+----------------------+---------------------+ 3253 7.1.3 Local Repair 3255 Once a node has detected that a change may have occurred, there are 3256 three possible cases: 3258 1. Only a change in the Response direction is indicated. There is 3259 nothing that can be done locally; GIMPS must propagate a 3260 notification to its peer. 3262 2. A Query direction change has been detected and a Response 3263 direction change cannot be ruled out. Although some local repair 3264 may be appropriate, it is difficult to decide what, since the 3265 path change may actually have taken place remotely from the 3266 detecting node (so that this node is no longer on the path at 3267 all). 3269 3. A Query direction change has been detected, but there is no 3270 change in the Responding direction. In this case, the detecting 3271 node is the true crossover router, i.e. the point in the network 3272 where old and new paths diverge. It is the correct node to 3273 initiate the local repair process. 3275 In case (3), i.e. at the crossover node, the local repair process is 3276 initiated by the GIMPS level as follows: 3278 o GIMPS marks its routing state information for this flow as 3279 'invalid', unless the route change was actually detected by D-mode 3280 probing (in which case the new state has already been installed). 3282 o GIMPS notifies the local NSLP that local repair is necessary. 3284 It is assumed that the second step will typically trigger the NSLP to 3285 generate a message, and the attempt to send it will stimulate a 3286 GIMPS-Query/Response. This signaling application message will 3287 propagate, also discovering the new route, until it rejoins the old 3288 path; the node where this happens may also have to carry out local 3289 repair actions. 3291 A problem is that there is usually no robust technique to distinguish 3292 case (2) from case (3), because of the relative weakness of the 3293 techniques in determining that such changes have not occurred. (They 3294 can be effective in determining that a change has occurred; however, 3295 even where they can tell that the route from the peer has not 3296 changed, they cannot rule out a change beyond that peer.) There is 3297 therefore a danger that multiple nodes within the network would 3298 attempt to carry out local repair in parallel. 3300 One possible technique to address this problem is that a GIMPS node 3301 that detects case (3) locally, rather than initiating local repair 3302 immediately, still sends a route change notification, just in case 3303 (2) actually applies. If the peer locally detects no downstream 3304 route change, it can signal this in the Query direction (e.g. by 3305 setting another flag in the Common-Header of a GIMPS message). This 3306 acts to damp the possibility of a 'local repair storm', at the cost 3307 of an additional peer-peer round trip time. 3309 7.1.4 Local Signaling Application State Removal 3311 After a route change, a signaling application may wish to remove 3312 state at another node which is no longer on the path. However, since 3313 it is no longer on the path, in principle GIMPS can no longer send 3314 messages to it. (In general, provided this state is soft, it will 3315 time out anyway; however, the timeouts involved may have been set to 3316 be very long to reduce signaling load.) The requirement to remove 3317 state in a specific peer node is identified in [27]. 3319 This requirement can be met provided that GIMPS is able to 'remember' 3320 the old path to the signaling application peer for the period while 3321 the NSLP wishes to be able to use it. Since NSLP peers are a single 3322 GIMPS hop apart, the necessary information is just the old entry in 3323 the node's routing state table for that flow. Rather than requiring 3324 the GIMPS level to maintain multiple generations of this information, 3325 it can just be provided to the signaling application in the same node 3326 (in an opaque form), which can store it if necessary and provide it 3327 back to the GIMPS layer in case it needs to be used. This 3328 information is denoted as 'SII-Handle' in the abstract API of 3329 Appendix D; however, the details are an implementation issue which do 3330 not affect the rest of the protocol. 3332 7.1.5 Operation with Heterogeneous NSLPs 3334 A potential problem with route change detection is that the detecting 3335 GIMPS node may not implement all the signaling applications that need 3336 to be informed. Therefore, it would need to be able to send a 3337 notification back along the unchanged path to trigger the nearest 3338 signaling application aware node to take action. If multiple 3339 signaling applications are in use, it would be hard to define when to 3340 stop propagating this notification. However, given the rules on 3341 message interception and routing state maintenance in Section 4.3 and 3342 Section 4.4, this situation cannot arise: all NSLP peers which store 3343 routing state about each other are exactly one GIMPS hop apart. 3345 The converse problem is that the ability of GIMPS to detect route 3346 changes by purely local monitoring of forwarding tables is more 3347 limited. (This is probably an appropriate limitation of GIMPS 3348 functionality. If we need a protocol for distributing notifications 3349 about local changes in forwarding table state, a flow signaling 3350 protocol is probably not the right starting point.) 3352 7.2 Policy-Based Forwarding and Flow Wildcarding 3354 Signaling messages almost by definition need to contain address and 3355 port information to identify the flow they are signaling for. We can 3356 divide this information into two categories: 3358 Message-Routing-Information: This is the information needed to 3359 determine how a message is routed within the network. It may 3360 include a number of flow N-tuple parameters, and is carried as an 3361 object in each GIMPS message (see Section 5.1). 3363 Additional Packet Classification Information: This is any further 3364 higher layer information needed to select a subset of packets for 3365 special treatment by the signaling application. The need for this 3366 is highly signaling application specific, and so this information 3367 is invisible to GIMPS (if indeed it exists); it will be carried 3368 only in the corresponding NSLP. 3370 The correct pinning of signaling messages to the data path depends on 3371 how well the Query messages in datagram mode can be made to be routed 3372 correctly. Two strategies are used: 3374 The messages themselves match the flow in destination address and 3375 possibly other fields (see Section 5.3 and Section 5.8 for further 3376 discussion). In many cases, this will cause the messages to be 3377 routed correctly even by GIMPS-unaware nodes. 3379 A GIMPS-aware node carrying out policy based forwarding on higher 3380 layer identifiers (in particular, the protocol and port numbers 3381 for IPv4) should take into account the entire Message-Routing- 3382 Information object in selecting the outgoing interface rather than 3383 relying on the IP layer. 3385 Message-Routing-Information formats may allow a degree of 3386 'wildcarding', for example by applying a prefix length to the source 3387 or destination address, or by leaving certain fields unspecified. A 3388 GIMPS-aware node must verify that all flows matching the Message- 3389 Routing-Information would be routed identically in the downstream 3390 direction, or else reject the message with a "MRI Too Wild" error 3391 message (Appendix C.5.4.13). 3393 7.3 NAT Traversal 3395 As already noted, GIMPS messages must carry packet addressing and 3396 higher layer information as payload data in order to define the flow 3397 signalled for. (This applies to all GIMPS messages, regardless of 3398 how they are encapsulated or which direction they are travelling in.) 3399 At an addressing boundary the data flow packets will have their 3400 headers translated; if the signaling payloads are not likewise 3401 translated, the signaling messages will refer to incorrect (and 3402 probably meaningless) flows after passing through the boundary. In 3403 addition, some GIMPS messages (those used in the discovery process) 3404 carry addressing information about the GIMPS nodes themselves, and 3405 this must also be processed appropriately when traversing a NAT. 3407 The simplest solution to this problem is to require that a NAT is 3408 GIMPS-aware, and to allow it to modify datagram mode messages based 3409 on the contents of the Message-Routing-Information payload. (This is 3410 making the implicit assumption that NATs only rewrite the header 3411 fields included in this payload, and not higher layer identifiers.) 3412 Provided this is done consistently with the data flow header 3413 translation, signaling messages will be valid each side of the 3414 boundary, without requiring the NAT to be signaling application 3415 aware. An outline of the set of operations necessary on a downstream 3416 datagram mode message is as follows: 3418 1. Verify that bindings for the data flow are actually in place. 3420 2. Create bindings for subsequent C-mode signaling (based on the 3421 information in the Network-Layer-Information and Stack- 3422 Configuration-Data objects). 3424 3. Create a new Message-Routing-Information object with fields 3425 modified according to the data flow bindings. 3427 4. Create new Network-Layer-Information and Stack-Configuration-Data 3428 objects with fields to force upstream D-mode messages through the 3429 NAT, and to allow C-mode exchanges using the C-mode signaling 3430 bindings. 3432 5. Add a new NAT-Traversal payload, listing the objects which have 3433 been modified and including the unmodified Message-Routing- 3434 Information. 3436 6. Forward the message with these new payloads. 3438 The original Message-Routing-Information payload is retained in the 3439 message, but encapsulated in the new TLV type. Further information 3440 can be added corresponding to the Network-Layer-Information payload, 3441 either the original payload itself or, in the case of a GIMPS node 3442 that wished to do topology hiding, opaque tokens (or it could be 3443 omitted altogether). In the case of a sequence of NATs, this part of 3444 the NAT-Traversal object would become a list. Note that a 3445 consequence of this approach is that the routing state tables at the 3446 actual signaling application peers (either side of the NAT) are no 3447 longer directly compatible. In particular, the values of Message- 3448 Routing-Information are different, which is why the unmodified MRI is 3449 propagated in the NAT-Traversal payload to allow subsequent C-mode 3450 messages to be interpreted correctly.. 3452 The case of traversing a GIMPS-unaware NAT is for further study. 3453 There is a dual problem of whether the GIMPS peers either side of the 3454 boundary can work out how to address each other, and whether they can 3455 work out what translation to apply to the Message-Routing-Information 3456 from what is done to the signaling packet headers. The fundamental 3457 problem is that GIMPS messages contain 3 or 4 interdependent 3458 addresses which all have to be consistently translated, and existing 3459 generic NAT traversal techniques such as STUN [22] can process only 3460 two. 3462 7.4 Interaction with IP Tunnelling 3464 The interaction between GIMPS and IP tunnelling is very simple. An 3465 IP packet carrying a GIMPS message is treated exactly the same as any 3466 other packet with the same source and destination addresses: in other 3467 words, it is given the tunnel encapsulation and forwarded with the 3468 other data packets. 3470 Tunnelled packets will not be identifiable as GIMPS messages until 3471 they leave the tunnel, since any router alert option and the standard 3472 GIMPS protocol encapsulation (e.g. port numbers) will be hidden 3473 behind the standard tunnel header. If signaling is needed for the 3474 tunnel itself, this has to be initiated as a separate signaling 3475 session by one of the tunnel endpoints - that is, the tunnel counts 3476 as a new flow. Because the relationship between signaling for the 3477 'microflow' and signaling for the tunnel as a whole will depend on 3478 the signaling application in question, we are assuming that it is a 3479 signaling application responsibility to be aware of the fact that 3480 tunnelling is taking place and to carry out additional signaling if 3481 necessary; in other words, one tunnel endpoint must be signaling 3482 application aware. 3484 In some cases, it is the tunnel exit point (i.e. the node where 3485 tunnelled data and downstream signaling packets leave the tunnel) 3486 that will wish to carry out the tunnel signaling, but this node will 3487 not have knowledge or control of how the tunnel entry point is 3488 carrying out the data flow encapsulation. This information could be 3489 carried as additional data (an additional GIMPS payload) in the 3490 tunnelled signaling packets if the tunnel entry point was at least 3491 GIMPS-aware. This payload would be the GIMPS equivalent of the RSVP 3492 SESSION_ASSOC object of [13]. Whether this functionality should 3493 really be part of GIMPS and if so how the payload should be handled 3494 will be considered in a later version. 3496 7.5 IPv4-IPv6 Transition and Interworking 3498 GIMPS itself is essentially IP version neutral (version dependencies 3499 are isolated in the formats of the Message-Routing-Information, 3500 Network-Layer-Information and Stack-Configuration-Data objects, and 3501 GIMPS also depends on the version independence of the protocols that 3502 support messaging associations). In mixed environments, GIMPS 3503 operation will be influenced by the IP transition mechanisms in use. 3504 This section provides a high level overview of how GIMPS is affected, 3505 considering only the currently predominant mechanisms. 3507 Dual Stack: (This applies both to the basic approach described in 3508 [28] as well as the dual-stack aspects of more complete 3509 architectures such as [32].) In mixed environments, GIMPS should 3510 use the same IP version as the flow it is signaling for; hosts 3511 which are dual stack for applications and routers which are dual 3512 stack for forwarding should have GIMPS implementations which can 3513 support both IP versions. 3515 In theory, for some connection mode encapsulation options, a 3516 single messaging association could carry signaling messages for 3517 flows of both IP versions, but the saving seems of limited value. 3518 The IP version used in datagram mode is closely tied to the IP 3519 version used by the data flow, so it is intrinsically impossible 3520 for a IPv4-only or IPv6-only GIMPS node to support signaling for 3521 flows using the other IP version. 3523 Applications with a choice of IP versions might select a version 3524 based on which could be supported in the network by GIMPS, which 3525 could be established by running parallel discovery procedures. In 3526 theory, a GIMPS message related to a flow of one IP version could 3527 flag support for the other; however, given that IPv4 and IPv6 3528 could easily be separately routed, the correct GIMPS peer for a 3529 given flow might well depend on IP version anyway, making this 3530 flagged information irrelevant. 3532 Packet Translation: (Applicable to SIIT [7] and NAT-PT [14].) Some 3533 transition mechanisms allow IPv4 and IPv6 nodes to communicate by 3534 placing packet translators between them. From the GIMPS 3535 perspective, this should be treated essentially the same way as 3536 any other NAT operation (e.g. between 'public' and 'private' 3537 addresses) as described in Section 7.3. In other words, the 3538 translating node needs to be GIMPS-aware; it will run GIMPS with 3539 IPv4 on some interfaces and with IPv6 on others, and will have to 3540 translate the Message-Routing-Information payload between IPv4 and 3541 IPv6 formats for flows which cross between the two. The 3542 translation rules for the fields in the payload (including e.g. 3543 DiffServ-codepoint and flow-label) are as defined in [7]. 3545 Tunnelling: (Applicable to 6to4 [15] and a whole host of other 3546 tunnelling schemes.) Many transition mechanisms handle the 3547 problem of how an end to end IPv6 (or IPv4) flow can be carried 3548 over intermediate IPv4 (or IPv6) regions by tunnelling; the 3549 methods tend to focus on minimising the tunnel administration 3550 overhead. 3552 From the GIMPS perspective, the treatment should be as similar as 3553 possible to any other IP tunnelling mechanism, as described in 3554 Section 7.4. In particular, the end to end flow signaling will 3555 pass transparently through the tunnel, and signaling for the 3556 tunnel itself will have to be managed by the tunnel endpoints. 3557 However, additional considerations may arise because of special 3558 features of the tunnel management procedures. For example, [16] 3559 is based on using an anycast address as the destination tunnel 3560 endpoint. It might be unwise to carry out signaling for the 3561 tunnel to such an address, and the GIMPS implementation there 3562 would not be able to use it as a source address for its own 3563 signaling messages (e.g. GIMPS-responses). Further analysis will 3564 be contained in a future version of this specification. 3566 8. Security Considerations 3568 The security requirement for the GIMPS layer is to protect the 3569 signaling plane against identified security threats. For the 3570 signaling problem as a whole, these threats have been outlined in 3571 [25]; the NSIS framework [24] assigns a subset of the responsibility 3572 to the NTLP. The main issues to be handled can be summarised as: 3574 Message Protection: Signaling message content should be protected 3575 against eavesdropping, modification, injection and replay while in 3576 transit. This applies both to GIMPS payloads, and GIMPS should 3577 also provide such protection as a service to signaling 3578 applications between adjacent peers. 3580 Routing State Integrity Protection: It is important that signaling 3581 messages are delivered to the correct nodes, and nowhere else. 3582 Here, 'correct' is defined as 'the appropriate nodes for the 3583 signaling given the Message-Routing-Information'. In the case 3584 where the MRI is the Flow Identification for path-coupled 3585 signaling, 'appropriate' means 'the same nodes that the 3586 infrastructure will route data flow packets through'. (GIMPS has 3587 no role in deciding whether the data flow itself is being routed 3588 correctly; all it can do is ensure the signaling is routed 3589 consistently with it.) GIMPS uses internal state to decide how to 3590 route signaling messages, and this state needs to be protected 3591 against corruption. 3593 Prevention of Denial of Service Attacks: GIMPS nodes and the network 3594 have finite resources (state storage, processing power, 3595 bandwidth). The protocol should try to minimise exhaustion 3596 attacks against these resources and not allow GIMPS nodes to be 3597 used to launch attacks on other network elements. 3599 The main missing issue is handling authorisation for executing 3600 signaling operations (e.g. allocating resources). This is assumed to 3601 be done in each signaling application. 3603 In many cases, GIMPS relies on the security mechanisms available in 3604 messaging associations to handle these issues, rather than 3605 introducing new security measures. Obviously, this requires the 3606 interaction of these mechanisms with the rest of the GIMPS protocol 3607 to be understood and verified, and some aspects of this are discussed 3608 in Section 5.7. 3610 8.1 Message Confidentiality and Integrity 3612 GIMPS can use messaging association functionality, such as TLS or 3613 IPsec, to ensure message confidentiality and integrity. In many 3614 cases, confidentiality of GIMPS information itself is not likely to 3615 be a prime concern, in particular since messages are often sent to 3616 parties which are unknown ahead of time, although the content visible 3617 even at the GIMPS level gives significant opportunities for traffic 3618 analysis. Signaling applications may have their own mechanism for 3619 securing content as necessary; however, they may find it convenient 3620 to rely on protection provided by messaging associations, since it 3621 runs unbroked between signaling application peers. 3623 8.2 Peer Node Authentication 3625 Cryptographic protection (of confidentiality or integrity) requires a 3626 security association with session keys, which can be established 3627 during an authentication and key exchange protocol run based on 3628 shared secrets, public key techniques or a combination of both. 3629 Authentication and key agreement is possible using the protocols 3630 associated with the messaging association being secured (TLS 3631 incorporates this functionality directly; IKE, IKEv2 or KINK can 3632 provide it for IPsec). GIMPS nodes rely on these protocols to 3633 authenticate the identity of the next hop, and GIMPS has no 3634 authentication capability of its own. 3636 However, with discovery, there are few effective ways to know what is 3637 the legitimate next or previous hop as opposed to an impostor. In 3638 other words, cryptographic authentication here only provides 3639 assurance that a node is 'who' it is (i.e. the legitimate owner of 3640 identity in some namespace), not 'what' it is (i.e. a node which is 3641 genuinely on the flow path and therefore can carry out signaling for 3642 a particular flow). Authentication provides only limited protection, 3643 in that a known peer is unlikely to lie about its role. Additional 3644 methods of protection against this type of attack are considered in 3645 Section 8.3 below. 3647 It is an implementation issue whether peer node authentication should 3648 be made signaling application dependent; for example, whether 3649 successful authentication could be made dependent on presenting 3650 authorisation to act in a particular signaling role (e.g. signaling 3651 for QoS). The abstract API of Appendix D does not specify such 3652 policy and authentication interactions between GIMPS and the NSLP it 3653 is serving. However, it does allow applications to inspect the 3654 authenticated identity of the peer to which a message will be sent 3655 before transmission. 3657 8.3 Routing State Integrity 3659 The internal state in a node (see Section 4.2), specifically the peer 3660 identification, is used to route messages. If this state is 3661 corrupted, signaling messages may be misdirected. 3663 In the case where the message routing method is path-coupled, the 3664 messages need to be routed identically to the data flow described by 3665 the Flow Identifier, and the routing state table is the GIMPS view of 3666 how these flows are being routed through the network in the immediate 3667 neighbourhood of the node. Routes are only weakly secured (e.g. 3668 there is usually no cryptographic binding of a flow to a route), and 3669 there is no authoritative information about flow routes other than 3670 the current state of the network itself. Therefore, consistency 3671 between GIMPS and network routing state has to be ensured by directly 3672 interacting with the routing mechanisms to ensure that the signaling 3673 peers are the appropriate ones for any given flow. An overview of 3674 security issues and techniques in this context is provided in [31]. 3676 In one direction, peer identification is installed and refreshed only 3677 on receiving a GIMPS-Reponse message (compare Figure 4). This must 3678 echo the cookie from a previous GIMPS-Query message, which will have 3679 been sent along the flow path (in datagram mode, i.e. end-to-end 3680 addressed). Hence, only the true next peer or an on-path attacker 3681 will be able to generate such a message, provided freshness of the 3682 cookie can be checked at the querying node. 3684 In the other direction, peer identification can be installed directly 3685 on receiving a GIMPS-Query message containing addressing information 3686 for the signaling source. However, any node in the network could 3687 generate such a message (indeed, almost any node in the network could 3688 be the genuine upstream peer for a given flow). To protect against 3689 this, three strategies are possible: 3691 Filtering: the receiving node may be able to reject signaling 3692 messages which claim to be for flows with flow source addresses 3693 which would be ruled out by ingress filtering. An extension of 3694 this technique would be for the receiving node to monitor the data 3695 plane and to check explicitly that the flow packets are arriving 3696 over the same interface and if possible from the same link layer 3697 neighbour as the datagram mode signaling packets. (If they are 3698 not, it is likely that at least one of the signaling or flow 3699 packets is being spoofed.) Signaling applications should only 3700 install state on the route taken by the signaling itself. 3702 Authentication (weak or strong): the receiving node may refuse to 3703 install upstream state until it has completed a GIMPS-Confirm 3704 handshaked with the peer. This echoes the response cookie of the 3705 GIMPS-Response, and discourages nodes from using forged source 3706 addresses. A stronger approach is to require full peer 3707 authentication within the messaging association, the reasoning 3708 being that an authenticated peer can be trusted not to pretend 3709 that it is on path when it is not. 3711 SID segregation: The routing state lookup for a given MRI and NSLPID 3712 also takes the SID into account. A malicious node can only 3713 overwrite existing routing state if it can guess the corresponding 3714 SID; it can insert state with random SID values, but generally 3715 this will not be used to route messages for which state has 3716 already been legitimately established. 3718 The second technique also plays a role in denial of service 3719 prevention, see below. In practice, a combination of all techniques 3720 may be appropriate. 3722 8.4 Denial of Service Prevention 3724 GIMPS is designed so that in general each Query message only 3725 generates at most one Response, so that a GIMPS node cannot become 3726 the source of a denial of service amplification attack. (There is a 3727 special case of retransmitted Response messages, see Section 5.3.3.) 3729 However, GIMPS can still be subjected to denial-of-service attacks 3730 where an attacker using forged source addresses forces a node to 3731 establish state without return routability, causing a problem similar 3732 to TCP SYN flood attacks. Furthermore, an adversary might use 3733 modified or replayed unprotected signaling messages as part of such 3734 an attack. There are two types of state attacks and one 3735 computational resource attack. In the first state attack, an 3736 attacker floods a node with messages that the node has to store until 3737 it can determine the next hop. If the destination address is chosen 3738 so that there is no GIMPS-capable next hop, the node would accumulate 3739 messages for several seconds until the discovery retransmission 3740 attempt times out. The second type of state-based attack causes 3741 GIMPS state to be established by bogus messages. A related 3742 computational/network-resource attack uses unverified messages to 3743 cause a node to make AAA queries or attempt to cryptographically 3744 verify a digital signature. (RSVP is vulnerable to this type of 3745 attack.) Relying only on upper layer security, for example based on 3746 CMS, might open a larger door for denial of service attacks since the 3747 messages are often only one-shot-transactions which do not use 3748 multiple roundtrips and DoS protection mechanisms. 3750 We use a combination of two defences against these attacks: 3752 1. The responding node need not establish a session or discover its 3753 next hop on receiving the GIMPS-Query message, but can wait for a 3754 GIMPS-Confirm message on a secure channel. If the channel 3755 exists, the additional delay is one one-way delay and the total 3756 is no more than the minimal theoretically possible delay of a 3757 three-way handshake, i.e., 1.5 node-to-node round-trip times. 3758 The delay gets significantly larger if a new connection needs to 3759 be established first. 3761 2. The Response to the Query message contains a cookie, which is 3762 repeated in the Confirm. State is only established for messages 3763 that contain a valid cookie. The setup delay is also 1.5 round- 3764 trip times. (This mechanism is similar to that in SCTP [8] and 3765 other modern protocols.) 3767 Once a node has decided to establish routing state, there may still 3768 be transport and security state to be established between peers. 3769 This state setup is also vulnerable to additional denial of service 3770 attacks. GIMPS relies on the lower layer protocols that make up 3771 messaging associations to mitigate such attacks. The current 3772 description assumes that the querying node is always the one wishing 3773 to establish a messaging association, so it is typically the 3774 responding node that needs to be protected. 3776 8.5 Summary of Requirements on Cookie Mechanisms 3778 The requirements on the Query cookie can be summarised as follows: 3780 Liveness: The cookie must be live (must change from one handshake to 3781 the next). To prevent replay attacks. 3783 Unpredictability: The cookie must not be guessable (e.g. not from a 3784 sequence or timestamp). To prevent direct forgery based on seeing 3785 a history of captured messages. 3787 Easily validated: It must be efficient for the Q-Node to validate 3788 that a particular cookie matches an in-progress handshake, for a 3789 routing state machine which already exists. To discard responses 3790 to spoofed queries. 3792 Uniqueness: The cookie must be unique to a given handshake (since it 3793 is actually used to match the Response to a handshake anyway, e.g. 3794 during messaging association re-use). 3796 Likewise, the requirements on the Responder cookie can be summarised 3797 as follows: 3799 Liveness: The cookie must be live (must change from one handshake to 3800 the next). To prevent replay attacks. 3802 Creation simplicity: The cookie must be lightweight to generate. To 3803 avoid resource exhaustion at the responding node. 3805 Validation simplicity: It must be simple for the R-node to validate 3806 that an R-cookie was generated by itself (and no-one else), 3807 without storing state about the handshake it was generated for. 3809 Binding: The cookie must be bound to the routing state that will be 3810 installed. To prevent use with different routing state e.g. in a 3811 modified Confirm. The routing state here includes: 3813 The NLI of the Query 3815 The MRI/NSLPID for the messaging 3817 The interface on which the Query was received (probably) 3819 A suitable implementation for the Q-Cookie is a cryptographically 3820 random number which is unique for this routing state machine 3821 handshake. 3823 A suitable implementation for the R-Cookie is as follows: 3825 R-Cookie = liveness data + hash (locally known secret, 3826 Q-Node NLI, MRI, NSLPID, 3827 reception interface, 3828 liveness data) 3830 There are a couple of alternatives for the liveness data. One is to 3831 use a timestamp like SCTP. Another is to use a local secret with 3832 (rapid) rollover, and the liveness data is the generation number of 3833 the secret, like IKEv2. In both cases, the liveness data has to be 3834 carried outside the hash, to allow the hash to be verified at the 3835 Responder. Another approach is to replace the hash with encryption 3836 under a locally known secret, in which case the liveness data does 3837 not need to be carried in the clear. Any symmetric cipher immune to 3838 known plaintext attacks can be used. 3840 8.6 Residual Threats 3842 Taking the above security mechanisms into account, the main residual 3843 threats against NSIS are three types of on-path attack. 3845 An on-path attacker who can intercept the initial Query can do most 3846 things it wants to the subsequent signalling. It is very hard to 3847 protect against this at the GIMPS level; the only defence is to use 3848 strong messaging association security to see whether the Responding 3849 node is authorised to take part in NSLP signalling exchanges. To 3850 some extent, this behaviour is logically indistinguishable from 3851 correct operation, so it is easy to see why defence is difficult. 3852 Note than an on-path attacker of this sort can do anything to the 3853 traffic as well as the signalling. Therefore, the additional threat 3854 induced by the signalling weakness seems tolerable. 3856 At the NSLP level, there is a concern about transitivity of trust of 3857 correctness of routing along the signalling chain. The NSLP at the 3858 querying node can have good assurance that it is communicating with 3859 an on-path peer (or a node delegated by the on-path node). However, 3860 it has no assurance that the node beyond the responder is also on- 3861 path, or that the MRI (in particular) is not being modified by the 3862 responder to refer to a different flow. Therefore, if it sends 3863 signalling messages with payloads (e.g. authorisation tokens) which 3864 are "valuable" to nodes beyond the first hop, it is up to the NSLP to 3865 ensure that the appropriate chain of trust exists, which must in 3866 general use messaging association (strong) security. 3868 There is a further residual attack by a node which is not on the path 3869 of the flow, but is on the path of the Response, or is able to use a 3870 Response from one handshake to interfere with another. The attacker 3871 modifies the Response to cause the Querying node to form an adjacency 3872 with it rather than the true downstream node. In principle, this 3873 attack can be prevented by including an additional cryptographic 3874 object in the Response message which ties the Response to the initial 3875 Query and the routing state and can be verified by the Querying node. 3877 9. IANA Considerations 3879 This section outlines the content of a future IANA considerations 3880 section. 3882 The GIMPS specification requires the creation of registries, as 3883 follows: 3885 GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a 3886 1 byte message type field (initially distinguishing Query/ 3887 Response/Confirm/Data/Error and MA-Hello messages). 3889 NSLP Identifiers: Each signaling application requires one of more 3890 NSLPIDs (different NSLPIDs may be used to distinguish different 3891 classes of signaling node, for example to handle different 3892 aggregation levels or different processing subsets). An NSLPID 3893 must be associated with a unique RAO value; further considerations 3894 are discussed in [34]. 3896 Object Types: There is a 12-bit field in the object header 3897 (Appendix C.3.1). Distinguish different ranges for different 3898 allocation styles (standards action, expert review etc.) and 3899 different applicability scopes (experimental/private). When a new 3900 object type is defined, the extensibility bits (A/B, see 3901 Appendix C.3.2) must also be defined. 3903 Extensibility Flags: There are 4 reserved flag bits in the object 3904 header (Appendix C.3.1). These are reserved for the definition of 3905 more complex extensibility encoding schemes. 3907 Message Routing Methods: GIMPS allows the idea of multiple message 3908 routing methods (see Section 3.3). The message routing method is 3909 indicated in the leading 2 bytes of the MRI object 3910 (Appendix C.4.1). 3912 MA-Protocol-IDs: The GIMPS design allows the set of possible 3913 protocols to be used in a messaging association to be extended, as 3914 discussed in Section 5.7. Every new mode of using a protocol is 3915 given a single byte MA-Protcol-ID, which is used as a tag in the 3916 Stack-Proposal and Stack-Configuration-Data objects 3917 (Appendix C.4.4 and Appendix C.4.5). Allocating a new MA- 3918 Protocol-ID requires defining the higher layer addressing 3919 information (if any) in the Stack-Configuration-Data object that 3920 is needed to define its configuration. Note that the 3921 MA-Protocol-ID is not an IP Protocol number (indeed, some of the 3922 possible messaging association protocols - such as TLS - do not 3923 have an IP Protocol number). 3925 Error Classes: There is a 1 byte field at the start of the Value 3926 field of the Error object (Appendix C.5.1). Five values for this 3927 field have already been defined. Further general classes of error 3928 could be defined. Note that the value here is primarily to aid 3929 human or management interpretation of otherwise unknown error 3930 codes. 3932 Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode 3933 in the Value field of the Error object (Appendix C.5.1). When a 3934 new error code is allocated, the Error Class and the format of any 3935 associated error-specific information must also be defined. 3937 10. Change History 3939 10.1 Changes In Version -07 3941 1. The open issues section has finally been removed in favour of the 3942 authoritative list of open issues in an online issue tracker at h 3943 ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index. 3945 2. Clarified terminology on peering and adjacencies that there may 3946 be NSIS nodes between GIMPS peers that do some message 3947 processing, but that are not explicitly visible in the peer state 3948 tables. 3950 3. Added a description of the loose-end MRM (Section 5.8.2 and 3951 Appendix C.4.1.2). 3953 4. Added a description of an upstream Query encapsulation for the 3954 path-coupled MRM, Section 5.8.1.3, including rationale for and 3955 restrictions on its use. 3957 5. The formal description of the protocol in Section 6 has been 3958 significantly updated and extended in terms of detail. 3960 6. Modified the description of the interaction between NSLPs and 3961 GIMPS for handling inbound messages for which no routing state 3962 exists, to allow the NSLP to indicate whether state setup should 3963 proceed and to provide NSLP payloads for the Response or 3964 forwarded message (Section 3.5, Section 4.3.2 and Appendix D). 3966 7. Included new text, Section 5.6, on the processing and 3967 encapsulation of error messages. Also added formats and an error 3968 message catalogue in Appendix C.5, including a modified format 3969 for the overall GIMPS-Error message and the GIMPS-Error-Data 3970 object. 3972 8. Removed the old section 5.3.3 on NSLPID/RAO setting on the 3973 assumption that this will be covered in the extensibility 3974 document. 3976 9. Included a number of other minor corrections and clarifications. 3978 10.2 Changes In Version -06 3980 Version -06 does not introduce any major structural changes to the 3981 protocol definition, although it does clarify a number of details and 3982 resolve some outstanding open issues. The primary changes are as 3983 follows: 3985 1. Added a new high level Section 3.3 which gathers together the 3986 various aspects of the message routing method concept. 3988 2. Added a new high level Section 3.4 which explains the concept 3989 and significance of the session identifier. Also clarified that 3990 the routing state always depends on the session identifier. 3992 3. Added notes about the level of address validation performed by 3993 GIMPS in Section 4.1.2 and extensions to the API in Appendix D. 3995 4. Split the old Node-Addressing object into a Network-Layer- 3996 Information object and Stack-Configuration-Data object. The 3997 former refers to basic information about a node, and the latter 3998 carries information about messaging association configuration. 3999 Redefined the content of the various handshake messages 4000 accordingly in Section 4.4.1 and Section 5.1. 4002 5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge 4003 of routing state and messaging associations. Also, moved the 4004 routing state lifetime into the Network-Layer-Information object 4005 and added a messaging association lifetime to the Stack- 4006 Configuration-Data object (Section 5.2). 4008 6. Added specific message types for errors and MA-Refresh in 4009 Section 5.1. The error object is now GIMPS-specific 4010 (Appendix C.5.1). 4012 7. Moved the Flow-Identifier information about the message routing 4013 method from the general description of the object to the path- 4014 coupled MRM section (Section 5.8.1.1), and made a number of 4015 clarifications to the bit format (Appendix C.4.1.1). 4017 8. Removed text about assumptions on the version numbering of 4018 NSLPs, and restricted the scope of the description of TLV objct 4019 formats and extensibility flags to GIMPS rather than the whole 4020 of NSIS (Appendix C). 4022 9. Added a new Section 5.5 explaining the possible relationships 4023 between message types and encapsulation formats. 4025 10. Added a new Section 6 in outline form, to capture the formal 4026 specification of the protocol operation. 4028 11. Added new security sections on cookie requirements (Section 8.5) 4029 and residual threats (Section 8.6). 4031 10.3 Changes In Version -05 4033 Version -05 reformulates the specification, to describe routing state 4034 maintenance in terms of exchanging explicitly identified Query/ 4035 Response/Confirm messages, leaving the upstream/downstream 4036 distinction as a specific detail of how Query messages are 4037 encapsulated. This necessitated widespread changes in the 4038 specification text, especially Section 4.2.1, Section 4.4, 4039 Section 5.1 and Section 5.3 (although the actual message sequences 4040 are unchanged). A number of other issues, especially in the area of 4041 message encapsulation, have also been closed. The main changes are 4042 the following: 4044 1. Added a reference to [33] as a concrete example of an 4045 alternative message routing method. 4047 2. Added further text (particularly in Section 2) on what GIMPS 4048 means by the concept of 'session'. 4050 3. Firmed up the selection of UDP as the encapsulation choice for 4051 datagram mode, removing the open issue on this topic. 4053 4. Defined the interaction between GIMPS and signaling applications 4054 for communicating about the cryptographic security properties of 4055 how a message will be sent or has been received (see 4056 Section 4.1.2 and Appendix D). 4058 5. Closed the issue on whether Query messages should use the 4059 signaling or flow source address in the IP header; both options 4060 are allowed by local policy and a flag in the common header 4061 indicates which was used. (See Section 5.8.1.2.) 4063 6. Added the necessary information elements to allow the IP hop 4064 count between adjacent GIMPS peers to be measures and reported. 4065 (See Section 5.2.2 and Appendix C.4.3.) 4067 7. The old open-issue text on selection of IP router alert option 4068 values has been moved into the main specification to capture the 4069 technical considerations that should be used in assigning such 4070 values (in old section 5.3.3). 4072 8. Resolved the open issue on lost Confirm messages by allowing a 4073 choice of timer-based retransmission of the Response, or an 4074 error message from the responding node which causes the 4075 retransmission of the Confirm (see Section 5.3.3). 4077 9. Closed the open issue on support for message scoping (this is 4078 now assumed to be a NSLP function). 4080 10. Moved the authoritative text for most of the remaining open 4081 issues to an online issue tracker. 4083 10.4 Changes In Version -04 4085 Version -04 includes mainly clarifications of detail and extensions 4086 in particular technical areas, in part to support ongoing 4087 implementation work. The main details are as follows: 4089 1. Substantially updated Section 4, in particular clarifying the 4090 rules on what messages are sent when and with what payloads 4091 during routing and messaging association setup, and also adding 4092 some further text on message transfer attributes. 4094 2. The description of messaging association protocol negotiation 4095 including the related object formats has been centralised in a 4096 new Section 5.7, removing the old Section 6.6 and also closing 4097 old open issues 8.5 and 8.6. 4099 3. Made a number of detailed changes in the message format 4100 definitions (Appendix C), as well as incorporating initial rules 4101 for encoding message extensibility information. Also included 4102 explicit formats for a general purpose Error object, and the 4103 objects used to negotiate messaging association protocols. 4104 Updated the corresponding open issues section (old section 9.3) 4105 with a new item on NSLP versioning. 4107 4. Updated the GIMPS API (Appendix D), including more precision on 4108 message transfer attributes, making the NSLP hint about storing 4109 reverse path state a return value rather than a separate 4110 primitive, and adding a new primitive to allow signaling 4111 applications to invalidate GIMPS routing state. Also, added a 4112 new parameter to SendMessage to allow signaling applications to 4113 'bypass' a message statelessly, preserving the source of an 4114 input message. 4116 5. Added an outline for the future content of an IANA 4117 considerations section (Section 9). Currently, this is 4118 restricted to identifying the registries and allocations 4119 required, without defining the allocation policies and other 4120 considerations involved. 4122 6. Shortened the background design discussion in Section 3. 4124 7. Made some clarifications in the terminology section relating to 4125 how the use of C-mode does and does not mandate the use of 4126 transport or security protection. 4128 8. The ABNF for message formats in Section 5.1 has been re-written 4129 with a grammar structured around message purpose rather than 4130 message direction, and additional explanation added to the 4131 information element descriptions in Section 5.2. 4133 9. The description of the datagram mode transport in Section 5.3 4134 has been updated. The encapsulation rules (covering IP 4135 addressing and UDP port allocation) have been corrected, and a 4136 new subsection on message retransmission and rate limiting has 4137 been added, superceding the old open issue on the same subject 4138 (section 8.10). 4140 10. A new open issue on IP TTL measurement to detect non-GIMPS 4141 capable hops has been added (old section 9.5). 4143 10.5 Changes In Version -03 4145 Version -03 includes a number of minor clarifications and extensions 4146 compared to version -02, including more details of the GIMPS API and 4147 messaging association setup and the node addressing object. The full 4148 list of changes is as follows: 4150 1. Added a new section pinning down more formally the interaction 4151 between GIMPS and signaling applications (Section 4.1), in 4152 particular the message transfer attributes that signaling 4153 applications can use to control GIMPS (Section 4.1.2). 4155 2. Added a new open issue identifying where the interaction between 4156 the security properties of GIMPS and the security requirements of 4157 signaling applications should be identified (old section 9.10). 4159 3. Added some more text in Section 4.2.1 to clarify that GIMPS has 4160 the (sole) responsibility for generating the messages that 4161 refresh message routing state. 4163 4. Added more clarifying text and table to GHC and IP TTL handling 4164 discussion of Section 4.3.4. 4166 5. Split Section 4.4 into subsections for different scenarios, and 4167 added more detail on Node-Addressing object content and use to 4168 handle the case where association re-use is possible in 4169 Section 4.4.2. 4171 6. Added strawman object formats for Node-Addressing and Stack- 4172 Proposal objects in Section 5.1 and Appendix C. 4174 7. Added more detail on the bundling possibilities and appropriate 4175 configurations for various transport protocols in Section 5.4.1. 4177 8. Included some more details on NAT traversal in Section 7.3, 4178 including a new object to carry the untranslated address-bearing 4179 payloads, the NAT-Traversal object. 4181 9. Expanded the open issue discussion in old section 9.3 to include 4182 an outline set of extensibility flags. 4184 10.6 Changes In Version -02 4186 Version -02 does not represent any radical change in design or 4187 structure from version -01; the emphasis has been on adding details 4188 in some specific areas and incorporation of comments, including early 4189 review comments. The full list of changes is as follows: 4191 1. Added a new Section 1.1 which summarises restrictions on scope 4192 and applicability; some corresponding changes in terminology in 4193 Section 2. 4195 2. Closed the open issue on including explicit GIMPS state teardown 4196 functionality. On balance, it seems that the difficulty of 4197 specifying this correctly (especially taking account of the 4198 security issues in all scenarios) is not matched by the saving 4199 of state enabled. 4201 3. Removed the option of a special class of message transfer for 4202 reliable delivery of a single message. This can be implemented 4203 (inefficiently) as a degenerate case of C-mode if required. 4205 4. Extended Appendix C with a general discussion of rules for 4206 message and object formats across GIMPS and other NSLPs. Some 4207 remaining open issues are noted in old section 9.3 (since 4208 removed). 4210 5. Updated the discussion of RAO/NSLPID relationships to take into 4211 account the proposed message formats and rules for allocation of 4212 NSLP id, and propose considerations for allocation of RAO 4213 values. 4215 6. Modified the description of the information used to route 4216 messages (first given in Section 4.2.1 but also throughout the 4217 document). Previously this was related directly to the flow 4218 identification and described as the Flow-Routing-Information. 4219 Now, this has been renamed Message-Routing-Information, and 4220 identifies a message routing method and any associated 4221 addressing. 4223 7. Modified the text in Section 4.3 and elsewhere to impose sanity 4224 checks on the Message-Routing-Information carried in C-mode 4225 messages, including the case where these messages are part of a 4226 GIMPS-Query/Response exchange. 4228 8. Added rules for message forwarding to prevent message looping in 4229 a new Section 4.3.4, including rules on IP TTL and GIMPS hop 4230 count processing. These take into account the new RAO 4231 considerations described above. 4233 9. Added an outline mechanism for messaging association protocol 4234 stack negotiation, with the details in a new Section 6.6 and 4235 other changes in Section 4.4 and the various sections on message 4236 formats. 4238 10. Removed the open issue on whether storing reverse routing state 4239 is mandatory or optional. This is now explicit in the API 4240 (under the control of the local NSLP). 4242 11. Added an informative annex describing an abstract API between 4243 GIMPS and NSLPs in Appendix D. 4245 10.7 Changes In Version -01 4247 The major change in version -01 is the elimination of 4248 'intermediaries', i.e. imposing the constraint that signaling 4249 application peers are also GIMPS peers. This has the consequence 4250 that if a signaling application wishes to use two classes of 4251 signaling transport for a given flow, maybe reaching different 4252 subsets of nodes, it must do so by running different signaling 4253 sessions; and it also means that signaling adaptations for passing 4254 through NATs which are not signaling application aware must be 4255 carried out in datagram mode. On the other hand, it allows the 4256 elimination of significant complexity in the connection mode handling 4257 and also various other protocol features (such as general route 4258 recording). 4260 The full set of changes is as follows: 4262 1. Added a worked example in Section 3.5. 4264 2. Stated that nodes which do not implement the signaling 4265 application should bypass the message (Section 4.3). 4267 3. Decoupled the state handling logic for routing state and 4268 messaging association state in Section 4.4. Also, allow 4269 messaging associations to be used immediately in both directions 4270 once they are opened. 4272 4. Added simple ABNF for the various GIMPS message types in a new 4273 Section 5.1, and more details of the common header and each 4274 object in Section 5.2, including bit formats in Appendix C. The 4275 common header format means that the encapsulation is now the 4276 same for all transport types (Section 5.4.1). 4278 5. Added some further details on datagram mode encapsulation in 4279 Section 5.3, including more explanation of why a well known port 4280 is needed. 4282 6. Removed the possibility for fragmentation over DCCP 4283 (Section 5.4.1), mainly in the interests of simplicity and loss 4284 amplification. 4286 7. Removed all the tunnel mode encapsulations (old sections 5.3.3 4287 and 5.3.4). 4289 8. Fully re-wrote the route change handling description 4290 (Section 7.1), including some additional detection mechanisms 4291 and more clearly distinguishing between upstream and downstream 4292 route changes. Included further details on GIMPS/NSLP 4293 interactions, including where notifications are delivered and 4294 how local repair storms could be avoided. Removed old 4295 discussion of propagating notifications through signaling 4296 application unaware nodes (since these are now bypassed 4297 automatically). Added discussion on how to route messages for 4298 local state removal on the old path. 4300 9. Revised discussion of policy-based forwarding (Section 7.2) to 4301 account for actual FLow-Routing-Information definition, and also 4302 how wildcarding should be allowed and handled. 4304 10. Removed old route recording section (old Section 6.3). 4306 11. Extended the discussion of NAT handling (Section 7.3) with an 4307 extended outline on processing rules at a GIMPS-aware NAT and a 4308 pointer to implications for C-mode processing and state 4309 management. 4311 12. Clarified the definition of 'correct routing' of signaling 4312 messages in Section 8 and GIMPS role in enforcing this. Also, 4313 opened the possibility that peer node authentication could be 4314 signaling application dependent. 4316 13. Removed old open issues on Connection Mode Encapsulation 4317 (section 8.7); added new open issues on Message Routing (old 4318 Section 9.3 of version -05, later moved to Section 3.3) and 4319 Datagram Mode congestion control. 4321 14. Added this change history. 4323 11. References 4325 11.1 Normative References 4327 [1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 4329 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4330 Levels", BCP 14, RFC 2119, March 1997. 4332 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4333 Specifications: ABNF", RFC 2234, November 1997. 4335 [4] Kent, S. and R. Atkinson, "Security Architecture for the 4336 Internet Protocol", RFC 2401, November 1998. 4338 [5] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 4339 the Differentiated Services Field (DS Field) in the IPv4 and 4340 IPv6 Headers", RFC 2474, December 1998. 4342 [6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 4343 RFC 2711, October 1999. 4345 [7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 4346 RFC 2765, February 2000. 4348 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 4349 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 4350 Paxson, "Stream Control Transmission Protocol", RFC 2960, 4351 October 2000. 4353 [9] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 4354 draft-ietf-dccp-spec-11 (work in progress), March 2005. 4356 [10] Conta, A., "Internet Control Message Protocol (ICMPv6) for the 4357 Internet Protocol Version 6 (IPv6) Specification", 4358 draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. 4360 11.2 Informative References 4362 [11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 4363 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 4364 Specification", RFC 2205, September 1997. 4366 [12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 4367 RFC 2409, November 1998. 4369 [13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 4370 Operation Over IP Tunnels", RFC 2746, January 2000. 4372 [14] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 4373 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 4375 [15] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4376 IPv4 Clouds", RFC 3056, February 2001. 4378 [16] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 4379 RFC 3068, June 2001. 4381 [17] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 4382 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 4383 September 2001. 4385 [18] Grossman, D., "New Terminology and Clarifications for 4386 Diffserv", RFC 3260, April 2002. 4388 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 4389 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 4390 Session Initiation Protocol", RFC 3261, June 2002. 4392 [20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 4393 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 4394 RFC 3320, January 2003. 4396 [21] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 4397 Haukka, "Security Mechanism Agreement for the Session 4398 Initiation Protocol (SIP)", RFC 3329, January 2003. 4400 [22] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4401 - Simple Traversal of User Datagram Protocol (UDP) Through 4402 Network Address Translators (NATs)", RFC 3489, March 2003. 4404 [23] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 4405 Security Mechanism (GTSM)", RFC 3682, February 2004. 4407 [24] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 4408 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 4409 June 2005. 4411 [25] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 4412 Steps in Signaling (NSIS)", RFC 4081, June 2005. 4414 [26] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 4415 (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), 4416 May 2005. 4418 [27] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- 4419 of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in 4420 progress), February 2005. 4422 [28] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 4423 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in 4424 progress), March 2005. 4426 [29] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 4427 draft-ietf-secsh-architecture-22 (work in progress), 4428 March 2005. 4430 [30] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 4431 (work in progress), June 2005. 4433 [31] Nikander, P., "Mobile IP version 6 Route Optimization Security 4434 Design Background", draft-ietf-mip6-ro-sec-03 (work in 4435 progress), May 2005. 4437 [32] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 4438 (DSTM)", draft-bound-dstm-exp-03 (work in progress), July 2005. 4440 [33] Stiemerling, M., "Loose End Message Routing Method for NATFW 4441 NSLP", draft-stiemerling-nsis-natfw-mrm-01 (work in progress), 4442 February 2005. 4444 [34] Loughney, J., "NSIS Extensibility Model", 4445 draft-loughney-nsis-ext-00 (work in progress), May 2005. 4447 Authors' Addresses 4449 Henning Schulzrinne 4450 Columbia University 4451 Department of Computer Science 4452 450 Computer Science Building 4453 New York, NY 10027 4454 US 4456 Phone: +1 212 939 7042 4457 Email: hgs+nsis@cs.columbia.edu 4458 URI: http://www.cs.columbia.edu 4459 Robert Hancock 4460 Siemens/Roke Manor Research 4461 Old Salisbury Lane 4462 Romsey, Hampshire SO51 0ZN 4463 UK 4465 Email: robert.hancock@roke.co.uk 4466 URI: http://www.roke.co.uk 4468 Appendix A. Acknowledgements 4470 This document is based on the discussions within the IETF NSIS 4471 working group. It has been informed by prior work and formal and 4472 informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob 4473 Braden, Marcus Brunner, Benoit Campedel, Elwyn Davies, Christian 4474 Dickmann, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth, 4475 Cheng Hong, Cornelia Kappler, Georgios Karagiannis, Chris Lang, John 4476 Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew McDonald, 4477 Glenn Morrow, Dave Oran, Andreas Pashaldis, Tom Phelan, Takako Sanda, 4478 Charles Shen, Melinda Shore, Martin Stiemerling, Mike Thomas, Hannes 4479 Tschofenig, Sven van den Bosch, Michael Welzl, and Lars Westberg. In 4480 particular, Hannes Tschofenig provided a detailed set of review 4481 comments on the security section, and Andrew McDonald provided the 4482 formal description for the initial packet formats. Chris Lang's 4483 implementation work provided objective feedback on the clarity and 4484 feasibility of the specification, and he also provided the state 4485 machine description and the initial error catalogue and formats. We 4486 look forward to inputs and comments from many more in the future. 4488 Appendix B. Example Message Routing State Table 4490 Figure 10 shows a signaling scenario for a single flow being managed 4491 by two signaling applications using the path-coupled message routing 4492 method. The flow sender and receiver and one router support both, 4493 two other routers support one each. 4495 A B C D E 4496 +------+ +-----+ +-----+ +-----+ +--------+ 4497 | Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow | 4498 |Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver| 4499 | | +-+ +-+ |GIMPS| |GIMPS| |GIMPS| | | 4500 +------+ +-----+ +-----+ +-----+ +--------+ 4502 ------------------------------>> 4503 Flow Direction 4505 Figure 10: A Signaling Scenario 4507 The routing state table at node B is as follows: 4509 +--------------------+----------+----------+----------+-------------+ 4510 | Message Routing | Session | NSLP ID | Response | Query | 4511 | Information | ID | | Directio | Direction | 4512 | | | | n | | 4513 +--------------------+----------+----------+----------+-------------+ 4514 | Method = Path | 0xABCD | NSLP1 | IP-#A | (null) | 4515 | Coupled; Flow ID = | | | | | 4516 | {IP-#A, IP-#E, | | | | | 4517 | protocol, ports} | | | | | 4518 | | | | | | 4519 | Method = Path | 0x1234 | NSLP2 | IP-#A | Pointer to | 4520 | Coupled; Flow ID = | | | | B-D | 4521 | {IP-#A, IP-#E, | | | | messaging | 4522 | protocol, ports} | | | | association | 4523 +--------------------+----------+----------+----------+-------------+ 4525 The Response direction state is just the same address for each 4526 application. For the Query direction, NSLP1 only requires datagram 4527 mode messages and so no explicit routing state towards C is needed. 4528 NSLP2 requires a messaging association for its messages towards node 4529 D, and node C does not process NSLP2 at all, so the peer state for 4530 NSLP2 is a pointer to a messaging association that runs directly from 4531 B to D. Note that E is not visible in the state table (except 4532 implicitly in the address in the message routing information); 4533 routing state is stored only for adjacent peers. (In addition to the 4534 peer identification, IP hop counts are stored for each peer where the 4535 state itself if not null; this is not shown in the table.) 4537 Appendix C. Bit-Level Formats and Error Messages 4539 This appendix provides initial formats for the various component 4540 parts of the GIMPS messages defined abstractly in Section 5.2. 4542 C.1 General GIMPS Formatting Guidelines 4544 Each GIMPS message consists of a header and a sequence of objects. 4545 The GIMPS header has a specific format, described in more detail in 4546 Appendix C.2 below. An NSLP message is one object within a GIMPS 4547 message. Note that GIMPS provides the message length information and 4548 signaling application identification. 4550 Every object has the following general format: 4552 o The overall format is Type-Length-Value (in that order). 4554 o Some parts of the type field are set aside for control flags which 4555 define how unknown types should be handled; this is discussed in 4556 Appendix C.3.2. 4558 o Length has the units of 32 bit words, and measures the length of 4559 Value. If there is no Value, Length=0. 4561 o Value is (therefore) a whole number of 32 bit words. If there is 4562 any padding required, the length and location must be defined by 4563 the object-specific format information; objects which contain 4564 variable length (e.g. string) types may need to include additional 4565 length subfields to do so. 4567 o Any part of the object used for padding or defined as reserved 4568 must be set to 0 on transmission and must be ignored on reception. 4570 C.2 The GIMPS Common Header 4572 This header precedes all GIMPS messages. It has a fixed format, as 4573 shown below. 4575 0 1 2 3 4576 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 4577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4578 | Version | GIMPS hops | Message length | 4579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4580 | Signaling Application ID | Type |S|R| Reserved | 4581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4583 Message length = the total number of words in the message after 4584 the common header itself 4585 Type = the GIMPS message type (Query, Response, etc.) 4586 S flag = set if the IP source address is the signaling 4587 source address, clear if it was derived from the 4588 MRI 4589 R flag = set if a response to this message is explicitly 4590 requested 4592 C.3 General Object Characteristics 4594 C.3.1 TLV Header 4596 Each object begins with a fixed header giving the object type and 4597 object length. The bits marked 'A' and 'B' are extensibility flags 4598 which are defined below; the remaining bits marked 'r' are reserved. 4600 0 1 2 3 4601 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 4602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4603 |A|B|r|r| Type |r|r|r|r| Length | 4604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4606 C.3.2 Object Extensibility 4608 The leading two bits of the common TLV header are used to signal the 4609 desired treatment for objects whose treatment has not been defined in 4610 the protocol specification in question (i.e. whose Type field is 4611 unknown at the receiver). The following four categories of object 4612 have been identified, and are loosely described here. 4614 AB=00 ("Mandatory"): If the object is not understood, the entire 4615 message containing it must be rejected with a "Object Type Error" 4616 error message (Appendix C.5.4.10) with subcode 1 ("Unrecognised 4617 Object"). 4619 AB=01 ("Ignore"): If the object is not understood, it should be 4620 deleted and then the rest of the message processed as usual. 4622 AB=10 ("Forward"): If the object is not understood, it should be 4623 retained unchanged in any message forwarded as a result of message 4624 processing, but not stored locally. 4626 The combination AB=11 is reserved. Note that the concept of 4627 retaining an unknown object and including it in refresh messages 4628 further up or down the signalling path does not apply to GIMPS, since 4629 refresh operations only take place between adjacent peers. 4631 C.4 GIMPS TLV Objects 4633 In the following object diagrams, '//' is used to indicate a variable 4634 sized field and ':' is used to indicate a field that is optionally 4635 present. 4637 C.4.1 Message-Routing-Information 4639 Type: Message-Routing-Information 4641 Length: Variable (depends on message routing method) 4643 0 1 2 3 4644 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 4645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4646 | Message-Routing-Method | | 4647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4648 // Method-specific addressing information (variable) // 4649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4651 C.4.1.1 Path-Coupled MRM 4653 In the case of basic path-coupled routing, the addressing information 4654 takes the following format: 4656 0 1 2 3 4657 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 4658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4659 |IP-Ver |P|T|F|S|A|B|D|Reserved | 4660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4661 // Source Address // 4662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4663 // Destination Address // 4664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4665 | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| 4666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4667 : Reserved | Flow Label : 4668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4669 : SPI : 4670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4671 : Source Port : Destination Port : 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4674 The flags are: 4675 P - IP Protocol should be interpreted 4676 T - DS-Field should be interpreted; see [5] and [18] 4677 F - Flow Label is present and should be interpreted 4678 S - SPI is present and should be interpreted; see [4] 4679 A/B - Source/Destination Port (see below) 4680 D - Direction of message relative to MRI 4682 The source and destination addresses are always present and of the 4683 same type; their length depends on the value in the IP-Ver field. In 4684 the normal case where the MRI refers only to traffic between specific 4685 host addresses, the Source/Dest Prefix values would both be 32/128 4686 for IPv4/6 respectively. 4688 In the case of IPv6, the Protocol field refers to the true upper 4689 layer protocol carried by the packets, i.e. excluding any IP option 4690 headers. This is therefore not necessarily the same as the Next 4691 Header value from the base IPv6 header. 4693 F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit 4694 word for the FLow Label is absent. 4696 The S/A/B flags can only be set if P is set. The SPI field is only 4697 present if the S flag is set. 4699 If either of A, B is set, the word containing the port numbers is 4700 included in the object. However, the contents of each field is only 4701 significant if the corresponding flag is set; otherwise, the contents 4702 of the field is regarded as padding, and the MRI refers to all ports 4703 (i.e. acts as a wildcard). If the flag is set and Port=0x0000, the 4704 MRI will apply to a specific port, whose value is not yet known. If 4705 neither of A or B is set, the word is absent. 4707 The Direction flag has the following meaning: the value 0 means 'in 4708 the same direction as the flow' (or "downstream"), and the value 1 4709 means 'in the opposite direction to the flow' (or "upstream"). 4711 C.4.1.2 Loose-End MRM 4713 In the case of the loose-end message routing method, the addressing 4714 information takes the following format: 4716 0 1 2 3 4717 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 4718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4719 |IP-Ver |D| Reserved | 4720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4721 // Source Address // 4722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4723 // Destination Address // 4724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4726 The only flag defined is: 4727 D - Direction relative to MRI (always 0 for "downstream") 4729 The source and destination addresses are always present and of the 4730 same type; their length depends on the value in the IP-Ver field. 4732 C.4.2 Session Identification 4734 Type: Session-Identification 4736 Length: Fixed (4 32-bit words) 4738 0 1 2 3 4739 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 4740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4741 | | 4742 + + 4743 | | 4744 + Session ID + 4745 | | 4746 + + 4747 | | 4748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4750 C.4.3 Network-Layer-Information 4752 Type: Network-Layer-Information 4754 Length: Variable (depends on length of Peer-Identity and IP version) 4756 0 1 2 3 4757 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 4758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4759 | PI-Length | IP-TTL |IP-Ver | Reserved | 4760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4761 | Routing State Validity Time | 4762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4763 // Peer Identity // 4764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4765 // Interface Address // 4766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4768 Routing State Validity Time = the time for which the routing state 4769 for this flow can be considered correct without a 4770 refresh. Given in milliseconds. 4771 PI-Length = the byte length of the Peer-Identity field 4772 (note that the Peer-Identity field itself is padded 4773 to a whole number of words) 4774 IP-TTL = initial or reported IP-TTL 4775 IP-Ver = the IP version for the Interface-Address field 4777 C.4.4 Stack Proposal 4779 Type: Stack-Proposal 4781 Length: Variable (depends on number of profiles and size of each 4782 profile) 4784 0 1 2 3 4785 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 4786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4787 | Prof-Count | Reserved | 4788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4789 // Profile 1 // 4790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4791 : : 4792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4793 // Profile 2 // 4794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4796 Prof-Count = The number of profiles in the proposal 4798 Each profile is itself a sequence of protocol layers, and the profile 4799 is formatted as a list as follows: 4801 o The first byte is a count of the number of layers in the profile. 4803 o This is followed by a sequence of 1-byte MA-Protocol-IDs as 4804 described in Section 5.7. 4806 o The profile is padded to a word boundary with 0, 1, 2 or 3 zero 4807 bytes. 4809 C.4.5 Stack-Configuration-Data 4811 Type: Stack-Configuration-Data 4813 Length: Variable (depends on number of protocols and size of each 4814 protocol configuration data) 4816 0 1 2 3 4817 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 4818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4819 | HL-Count | Reserved | 4820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4821 | MA-Hold-Time | 4822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4823 // Higher-Layer-Information 1 // 4824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4825 : : 4826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4827 // Higher-Layer-Information N // 4828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4829 MA-Hold-Time = the time for which the messaging association will 4830 be held open without traffic or a hello message. 4831 Given in milliseconds. 4832 HL-Count = the number of higher-layer-information fields 4833 (these contain their own length information) 4835 The higher layer information fields are formatted as follows: 4837 o There is a 1-byte MA-Protocol-ID, as described in Section 5.7. 4839 o There is a 1-byte length field defining the amount of 4840 configuration data that follows after the length field. 4842 o There is a variable length of configuration data. 4844 o There are 0, 1, 2, or 3 bytes of zero padding to the next word 4845 boundary. 4847 Note that the contents of the configuration data may differ depending 4848 on whether the object is in a GIMPS-Query or GIMPS-Response. 4850 C.4.6 Query Cookie 4852 Type: Query-Cookie 4854 Length: Variable (selected by querying node) 4856 0 1 2 3 4857 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 4858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4859 | | 4860 // Query Cookie // 4861 | | 4862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4863 The contents are implementation defined. See Section 8.5 for further 4864 discussion. 4866 C.4.7 Responder Cookie 4868 Type: Responder-Cookie 4870 Length: Variable (selected by responding node) 4872 0 1 2 3 4873 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 4874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4875 | | 4876 // Responder Cookie // 4877 | | 4878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4880 The contents are implementation defined. See Section 8.5 for further 4881 discussion. 4883 C.4.8 NAT Traversal 4885 Type: NAT-Traversal 4887 Length: Variable (depends on length of contained fields) 4889 This object is used to support the NAT traversal mechanisms described 4890 in Section 7.3. 4892 0 1 2 3 4893 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 4894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4895 | MRI-Length | Type-Count | NAT-Count | Reserved | 4896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 // Original Message-Routing-Information // 4898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4899 // List of translated objects // 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4901 | Length of opaque NLI info. | | 4902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4903 // NLI information replaced by NAT #1 | 4904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4905 : : 4906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4907 | Length of opaque NLI info. | | 4908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 4909 // NLI information replaced by NAT #N | 4910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4912 MRI-Length = the word length of the included MRI payload 4913 Type-Count = the number of GIMPS payloads translated by the 4914 NAT; the Type numbers are included as a list 4915 (padded with 2 null bytes if necessary) 4916 NAT-Count = the number of NATs traversed by the message, and the 4917 number of opaque NLI-related payloads at the end 4918 of the object 4920 C.4.9 NSLP Data 4922 Type: NSLP-Data 4924 Length: Variable (depends on NSLP) 4926 0 1 2 3 4927 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 4928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4929 | | 4930 // NSLP Data // 4931 | | 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4934 C.5 Errors 4935 C.5.1 Error Object 4937 Type: Error 4939 Length: Variable (depends on error) 4941 0 1 2 3 4942 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 4943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4944 | Error Class | Error Code | Error Subcode | 4945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4946 |S|M|C|D|Q| Reserved | MRI Length | Info Count | 4947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4948 | | 4949 + Common Header + 4950 | | 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 | | 4953 + + 4954 | | 4955 + Session Id + 4956 | | 4957 + + 4958 | | 4959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4960 // Message Routing Information // 4961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4962 // Additional Information // 4963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4964 // Debugging Comment // 4965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4967 The flags are: 4968 S - Session ID object present 4969 M - MRI object present 4970 C - Debug Comment present after header. 4971 D - Original message was received in D-Mode 4972 Q - Original message was received Q-Mode encapsulated 4973 (can't be set if D=0). 4975 A GIMPS Error object contains an error-class (see Appendix C.5.3), an 4976 error-code, an error-subcode, and as much information about the 4977 message which triggered the error as is available. This information 4978 must include the Common header of the original message and should 4979 also include the Session Id and MRI objects if these could be decoded 4980 correctlty. These objects are included in their entirety, except for 4981 the TLV Header. 4983 The Info Count field contains the number of Additional Information 4984 fields in the object. This count is usually 1, but may be more for 4985 certain messages; the precise set of fields to include is defined 4986 with the error code/subcode. The field formats are given in 4987 Appendix C.5.2 and their use for the different errors is given in the 4988 error catalogue Appendix C.5.4. The Debugging Comment is a null- 4989 terminated UTF-8 string, padded if necessary to a whole number of 32- 4990 bit words with more null characters. 4992 C.5.2 Additional Information Fields 4994 The Common Header may optionally be followed by some Additional 4995 Information objects. The possible formats of these objects are shown 4996 below. 4998 Message Length Info: 5000 0 1 2 3 5001 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 5002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5003 | Calculated Length | Reserved | 5004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5006 Calculated Length = the length of the original message calculated 5007 by adding up all the objects in the message. 5009 MTU Info: 5011 0 1 2 3 5012 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 5013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5014 | Link MTU | Reserved | 5015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5017 This object provides information about the MTU for a link along 5018 which a message could not be sent. 5020 Object Type Info: 5022 0 1 2 3 5023 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 5024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5025 | Object Type | Reserved | 5026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5028 This object provides information about the type of object which 5029 caused the error. 5031 Object Value Info: 5033 0 1 2 3 5034 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 5035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5036 | Rsvd | Real Object Length | Offset | 5037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5038 // Object // 5039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5041 Real Object Length: Since the length in the original TLV header 5042 may be inaccurate, this field provides the actual 5043 length of the object (including the TLV Header) 5044 included in the error message. 5045 Offset: The byte in the object at which the GIMPS node 5046 found the error. 5047 Object: The invalid TLV object (including the TLV Header) 5049 This object carries information about a TLV object which was found 5050 to be invalid in the original message. An error message may contain 5051 more than one Object Value Info object. 5053 C.5.3 Error Classes 5055 The first byte of the error object, "Error Class", indicates the 5056 severity level. The currently defined severity levels are: 5058 Informational: response data which should not be thought of as 5059 changing the condition of the protocol state machine. 5061 Success: response data which indicates that the message being 5062 responded to has been processed successfully in some sense. 5064 Protocol-Error: the message has been rejected because of a protocol 5065 error (e.g. an error in message format). 5067 Transient-Failure: the message has been rejected because of a 5068 particular local node status which may be transient (i.e. it may 5069 be worthwhile to retry after some delay). 5071 Permanent-Failure: the message has been rejected because of local 5072 node status which will not change without additional out of band 5073 (e.g. management) operations. 5075 Additional error class values are reserved. 5077 The allocation of error classes to particular errors is not precise; 5078 the above descriptions are deliberately informal. Actually error 5079 processing should take into account the specific error in question; 5080 the error class may be useful supporting information (e.g. in network 5081 debugging). 5083 C.5.4 Error Catalogue 5085 This section lists all the possible GIMPS errors, including when they 5086 are raised and what additiona information fields should be carried in 5087 the error object. 5089 C.5.4.1 Unrecognised Message Type 5091 Class: Protocol-Error 5092 Code: 0 5093 Additional Info: None 5095 This message is sent if a GIMPS node receives a message of an 5096 unrecognised type. Note that in this case the original MRI and 5097 Session ID are not included in the Error Object. 5099 C.5.4.2 Incorrect Message Length 5101 Class: Protocol-Error 5102 Code: 1 5103 Additional Info: Message Length Info 5105 This message is sent if a GIMPS node receives a message containing a 5106 common header with an incorrect message length field. The message 5107 includes a single Message Length Info object containing the 5108 calculated length of the message. Note that in this case the 5109 original MRI and Session ID are not included in the Error Object. 5111 C.5.4.3 Hop Limit Exceeded 5113 Class: Permanent-Failure 5114 Code: 2 5115 Additional Info: None 5117 This message is sent if a GIMPS node receives a message with a GIMPS 5118 Hop Limit of zero, or a GIMPS node decrements a packet's GIMPS Hop 5119 Limit to zero. This message indicates either a routing loop or too 5120 small an initial Hop Limit value. 5122 C.5.4.4 Incorrect Encapsulation 5124 Class: Protocol-Error 5125 Code: 3 5126 Additional Info: None 5128 This message is sent if a GIMPS node receives a message which uses an 5129 incorrect encapsulation method (e.g. a Query arrives over an MA). 5131 C.5.4.5 Incorrectly Delivered Message 5133 Class: Protocol-Error 5134 Code: 4 5135 Additional Info: None 5137 This message is sent if a GIMPS node receives a message over an MA 5138 which is not associated with the MRI/NSLPID/SID combination in the 5139 message. 5141 C.5.4.6 No Routing State 5143 Class: Protocol-Error 5144 Code: 5 5145 Additional Info: None 5147 This message is sent if a node receives a message for which there is 5148 no matching routing state (and therefore no appropriate Q/R-SM). 5149 This can occur either at a Querying node which receives an unexpected 5150 Response message, or at a Responding node which receives an 5151 unexpected Data message. 5153 C.5.4.7 Unknown NSLPID 5155 Class: Permanent-Failure 5156 Code: 6 5157 Additional Info: None 5159 This message is sent if a router receives a directly addressed 5160 message for an NSLP which it does not support. 5162 C.5.4.8 Endpoint Found 5164 Class: Informational 5165 Code: 7 5166 Additional Info: None 5168 This message is sent if a GIMPS node at a flow endpoint receives a 5169 message for an NSLP which it does not support. 5171 C.5.4.9 Message Too Large 5172 Class: Permanent-Failure 5173 Code: 8 5174 Additional Info: MTU Info 5176 A router receives a message which it can't forward because it exceeds 5177 the next hop MTU. 5179 C.5.4.10 Object Type Error 5181 Class: Protocol-Error 5182 Code: 9 5183 Additional Info: Object Type Info 5185 This message is sent if a GIMPS node receives a message containing a 5186 TLV object with an incorrect header. The message includes the type 5187 of the object at fault. This error code is split into subcodes as 5188 follows: 5190 0: Duplicate Object: This subcode is used if a GIMPS node receives a 5191 message containing multiple instances of an object which may only 5192 appear once in a message (in the current specification this 5193 applies to all objects). 5195 1: Unrecognised Object: If a GIMP node receives a message containing 5196 an object which it does not recognise it must examine the objects 5197 A & B flags. This subcode is used if the A & B flags are both 5198 zero. Note that this error is unlikely to be received in response 5199 to a Data message. This is a pathological case. 5201 2: Missing Object: This subcode is used if a GIMPS node receives a 5202 message which is missing one or more mandatory objects. This 5203 message is also sent if a Stack Proposal is sent without a 5204 matching Stack Configuration Data object, or vice versa. 5206 C.5.4.11 Object Value Error 5208 Class: Protocol-Error 5209 Code: 10 5210 Additional Info: Object Value Info 5212 This message is sent if a router receives a packet containing an 5213 object which cannot be properly parsed. The message contains a 5214 single Object Value Info object, unless otherwise stated below. This 5215 error code is split into subcodes as follows: 5217 0: Incorrect Length: The overall length does not match the object 5218 length calculated from the object contents. 5220 1: Value Not Supported: The value of a field is not supported by the 5221 GIMPS node. 5223 2: Invalid Flag-Field Combination: An object contains an invalid 5224 combination of flags and/or fields. At the moment this only 5225 relates to the Path-Coupled MRM object, but in future there may be 5226 more. 5228 3: Empty List: At the moment this only relates to Stack proposal 5229 Profiles. The error message is sent if a stack proposal with a 5230 length > 0 (a length of 0 is not a supported value) contains only 5231 null bytes. 5233 4: Invalid Cookie: The message contains a cookie which could not be 5234 verified by the node. 5236 5: SP-SCD Mismatch: This subcode is used if a GIMPS node receives a 5237 message in which the data in the Stack Proposal object is 5238 inconsistent with the information in the Stack Configuration Data 5239 object. In this case, both the Stack Proposal object and Stack 5240 Configuration Data object are included in the message, in separate 5241 Object Value Info fields. 5243 C.5.4.12 Invalid IP TTL 5245 Class: Permanent-Failure 5246 Code: 11 5247 Additional Info: None 5249 This error indicates that a message was received with an IP-TTL 5250 outside an acceptable range; for example, that an upstream Query was 5251 received with an IP-TTL of less than 254 (i.e. more than one IP hop 5252 from the sender). The actual IP distance can be derived from the IP- 5253 TTL information in the NLI object carried in the same message. 5255 C.5.4.13 MRI Too Wild 5257 Class: Permanent-Failure 5258 Code: 12 5259 Additional Info: Object Value Info 5261 This error indicates that a message was received with an MRI that 5262 contained too much wildcarding (e.g. too short a destination address 5263 prefix) to be forwarded correctly down a single path). 5265 Appendix D. API between GIMPS and NSLP 5267 D.1 API Concepts 5269 This appendix provides an initial abstract API between GIMPS and 5270 NSLPs. 5272 This does not constrain implementors, but rather helps clarify the 5273 interface between the different layers of the NSIS protocol suite. 5274 In addition, although some of the data types carry the information 5275 from GIMPS Information Elements, this does not imply that the format 5276 of that data as sent over the API has to be the same. 5278 Conceptually the API has similarities to the UDP sockets API, 5279 particularly that for unconnected UDP sockets. An extension for an 5280 API like that for UDP connected sockets could be considered. In this 5281 case, for example, the only information needed in a SendMessage 5282 primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle 5283 (which can be null). Other information which was persistent for a 5284 group of messages could be configured once for the socket. Such 5285 extensions may make a concrete implementation more scalable and 5286 efficient but do not change the API semantics, and so are not 5287 considered further here. 5289 D.2 SendMessage 5291 This primitive is passed from an NSLP to GIMPS. It is used whenever 5292 the NSLP wants to initiate sending a message. 5294 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 5295 NSLP-Id, Session-ID, MRI, 5296 SII-Handle, Transfer-Attributes, Timeout, IP-TTL ) 5298 The following arguments are mandatory. 5300 NSLP-Data: The NSLP message itself. 5302 NSLP-Data-Size: The length of NSLP-Data. 5304 NSLP-Message-Handle: A handle for this message, that can be used 5305 later by GIMPS to reference it in status reports (in particular, 5306 notification about what security attributes will be used for the 5307 message, or error notifications). A NULL handle may be supplied 5308 if the NSLP is not interested in receiving MessageStatus 5309 notifications for this message. 5311 NSLP-Id: An identifier indicating which NSLP this is. 5313 Session-ID: The NSIS session identifier. Note that it is assumed 5314 that the signaling application provides this to GIMPS rather than 5315 GIMPS providing a value itself. 5317 MRI: Message routing information for use by GIMPS in determining the 5318 correct next GIMPS hop for this message. It contains, for 5319 example, the flow source/destination addresses and the type of 5320 routing to use for the signaling message. The message routing 5321 information implies the message routing method to be used and also 5322 includes the direction of the message. 5324 The following arguments are optional. 5326 SII-Handle: A handle, previously supplied by GIMPS, to a data 5327 structure (identifying peer addresses and interfaces) that should 5328 be used to explicitly route the message to a particular GIMPS next 5329 hop. If supplied, GIMPS should validate that it is consistent 5330 with the MRI. 5332 Transfer-Attributes: Attributes defining how the message should be 5333 handled (see Section 4.1.2). The following attributes can be 5334 considered: 5336 Reliability: Values 'unreliable' (default) or 'reliable'. 5338 Security: This attribute allows the NSLP to specify what level of 5339 security protection is requested for the message (selected from 5340 'integrity' and 'confidentiality'), and can also be used to 5341 specify what authenticated signaling source and destination 5342 identities should be used to send the message. The 5343 possibilities can be learned by the NSLP from prior 5344 MessageStatus or RecvMessage notifications. If an NSLP- 5345 Message-Handle is provided, GIMPS will inform the NSLP of what 5346 values it has actually chosen for this attribute via a 5347 MessageStatus callback. This might take place either 5348 synchronously (where GIMPS is just selecting from available 5349 messaging associations), or asynchronously (when a new 5350 messaging association needs to be created). 5352 Local Processing: This attribute contains hints from the NSLP 5353 about what local policy should be applied to the message; in 5354 particular, its transmission priority relative to other 5355 messages, or whether GIMPS should attempt to set up or maintain 5356 forward routing state. 5358 Timeout: Length of time GIMPS should attempt to send this message 5359 before indicating an error. 5361 IP-TTL: The value of the IP TTL that should be used when sending this 5362 message (may be overridden by GIMPS policy for particular 5363 messages). 5365 D.3 RecvMessage 5367 This primitive is passed from GIMPS to an NSLP. It is used whenever 5368 GIMPS receives a message from the network. This primitive can return 5369 a value from the NSLP which indicates whether the NSLP wishes GIMPS 5370 to retain message routing state. 5372 RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI, 5373 Adjacency-Check, 5374 SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance ) 5376 NSLP-Data: The NSLP message itself (may be empty). 5378 NSLP-Data-Size: The length of NSLP-Data (may be zero). 5380 NSLP-Id: An identifier indicating which NSLP this is message is for. 5382 Session-ID: The NSIS session identifier. 5384 MRI: Message routing information that was used by GIMPS in forwarding 5385 this message. It contains, for example, the flow source/ 5386 destination addresses, the type of routing used for the signaling 5387 message, and the direction of the message relative to the MRI. 5388 Implicitly defines the message routing method that was used. 5390 Adjacency-Check: This boolean is True if GIMPS is checking with the 5391 NSLP to see if a signaling adjacency should be formed (see 5392 Section 4.3.2). If True, the signaling application should return 5393 the following values via the RecvMessage call: 5395 A boolean to indicate whether or not the adjacency should be 5396 formed. 5398 Optionally, an NSLP-Payload to carry in a generated GIMPS- 5399 Response or forwarded Query/Data message respectively. 5401 SII-Handle: A handle to a data structure, identifying peer addresses 5402 and interfaces. Can be used to identify route changes and for 5403 explicit routing to a particular GIMPS next hop. 5405 Transfer-Attributes: The reliability and security attributes that 5406 were associated with the reception of this particular message. As 5407 well as the attributes associated with SendMessage, GIMPS may 5408 indicate the level of verification of the addresses in the MRI. 5409 Two flags can be indicated: 5411 * Whether the signalling source address is one of the flow 5412 endpoints (i.e. whether this is the first or last GIMPS hop); 5414 * Whether the signalling source address has been validated by a 5415 return routability check. 5417 IP-TTL: The value of the IP TTL (or Hop Limit) this message was 5418 received with (if available). 5420 IP-Distance: The number of IP hops from the peer signaling node which 5421 sent this message along the path, or 0 if this information is not 5422 available. 5424 D.4 MessageStatus 5426 This primitive is passed from GIMPS to an NSLP. It is used to notify 5427 the NSLP that a message that it requested to be sent could not be 5428 dispatched, or to inform the NSLP about the transfer attributes that 5429 have been selected for the message (specifically, security 5430 attributes). The NSLP can respond to this message with a return code 5431 to abort the sending of the message if the attributes are not 5432 acceptable. 5434 MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type) 5436 NSLP-Message-Handle: A handle for the message provided by the NSLP at 5437 the time of sending. 5439 Transfer-Attributes: The reliability and security attributes that 5440 will be used to transmit this particular message. 5442 Error-Type: Indicates the type of error that occurred. For example, 5443 'no next node found'. 5445 D.5 NetworkNotification 5447 This primitive is passed from GIMPS to an NSLP. It indicates that a 5448 network event of possible interest to the NSLP occurred. 5450 NetworkNotification ( MRI, Network-Notification-Type ) 5452 MRI: Provides the message routing information to which the network 5453 notification applies. 5455 Network-Notification-Type: Indicates the type of event that caused 5456 the notification, e.g. downstream route change, upstream route 5457 change, detection that this is the last node. 5459 D.6 SetStateLifetime 5461 This primitive is passed from an NSLP to GIMPS. It indicates the 5462 lifetime for which GIMPS should retain its routing state. It can 5463 also give a hint that the NSLP is no longer interested in the state. 5465 SetStateLifetime ( MRI, Direction, State-Lifetime ) 5467 MRI: Provides the message routing information to which the routing 5468 state lifetime applies. 5470 Direction: A flag indicating whether this relates to state for the 5471 upstream or downstream direction (in relation to the MRI). 5473 State-Lifetime: Indicates the lifetime for which the NSLP wishes 5474 GIMPS to retain its routing state (may be zero, indicating that 5475 the NSLP has no further interest in the GIMPS state). 5477 D.7 InvalidateRoutingState 5479 This primitive is passed from an NSLP to GIMPS. It indicates that 5480 the NSLP has knowledge that the next signaling hop known to GIMPS may 5481 no longer be valid, either because of changes in the network routing 5482 or the processing capabilities of NSLP nodes. It is an indication to 5483 GIMPS to restart the discovery process. 5485 InvalidateRoutingState ( NSLP-Id, MRI, Direction, Urgency ) 5486 NSLP-Id: The NSLP originating the message. May be null (in which 5487 case the invalidation applies to all signaling applications). 5489 MRI: The flow for which routing state should be invalidated. 5491 Direction: A flag indicating whether this relates to state for the 5492 upstream or downstream direction (in relation to the MRI). 5494 Urgency: A hint as to whether rediscovery should take place 5495 immediately, or only when the next signaling message is to be 5496 sent. 5498 Intellectual Property Statement 5500 The IETF takes no position regarding the validity or scope of any 5501 Intellectual Property Rights or other rights that might be claimed to 5502 pertain to the implementation or use of the technology described in 5503 this document or the extent to which any license under such rights 5504 might or might not be available; nor does it represent that it has 5505 made any independent effort to identify any such rights. Information 5506 on the procedures with respect to rights in RFC documents can be 5507 found in BCP 78 and BCP 79. 5509 Copies of IPR disclosures made to the IETF Secretariat and any 5510 assurances of licenses to be made available, or the result of an 5511 attempt made to obtain a general license or permission for the use of 5512 such proprietary rights by implementers or users of this 5513 specification can be obtained from the IETF on-line IPR repository at 5514 http://www.ietf.org/ipr. 5516 The IETF invites any interested party to bring to its attention any 5517 copyrights, patents or patent applications, or other proprietary 5518 rights that may cover technology that may be required to implement 5519 this standard. Please address the information to the IETF at 5520 ietf-ipr@ietf.org. 5522 Disclaimer of Validity 5524 This document and the information contained herein are provided on an 5525 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5526 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5527 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5528 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5529 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5532 Copyright Statement 5534 Copyright (C) The Internet Society (2005). This document is subject 5535 to the rights, licenses and restrictions contained in BCP 78, and 5536 except as set forth therein, the authors retain all their rights. 5538 Acknowledgment 5540 Funding for the RFC Editor function is currently provided by the 5541 Internet Society.