Next Steps in Signaling H. Schulzrinne Internet-Draft Columbia U. Expires: August 25, 2005 R. Hancock Siemens/RMR February 21, 2005 GIMPS: General Internet Messaging Protocol for Signaling draft-ietf-nsis-ntlp-05 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Messaging Protocol for Signaling (GIMPS), which provides a universal Schulzrinne & Hancock Expires August 25, 2005 [Page 1] Internet-Draft GIMPS February 2005 service for diverse signaling applications. GIMPS does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIMPS and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Restrictions on Scope . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation and Terminology . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Overall Design Approach . . . . . . . . . . . . . . . . . 8 3.2 Example of Operation . . . . . . . . . . . . . . . . . . . 10 4. GIMPS Processing Overview . . . . . . . . . . . . . . . . . 14 4.1 GIMPS Service Interface . . . . . . . . . . . . . . . . . 14 4.2 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Basic Message Processing . . . . . . . . . . . . . . . . . 18 4.4 Routing State and Messaging Association Maintenance . . . 22 5. Message Formats and Transport . . . . . . . . . . . . . . . 28 5.1 GIMPS Messages . . . . . . . . . . . . . . . . . . . . . . 28 5.2 Information Elements . . . . . . . . . . . . . . . . . . . 29 5.3 Datagram Mode Transport . . . . . . . . . . . . . . . . . 33 5.4 Connection Mode Transport . . . . . . . . . . . . . . . . 38 5.5 Messaging Association Negotiation . . . . . . . . . . . . 40 6. Advanced Protocol Features . . . . . . . . . . . . . . . . . 43 6.1 Route Changes and Local Repair . . . . . . . . . . . . . . 43 6.2 Policy-Based Forwarding and Flow Wildcarding . . . . . . . 49 6.3 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 49 6.4 Interaction with IP Tunnelling . . . . . . . . . . . . . . 51 6.5 IPv4-IPv6 Transition and Interworking . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . 54 7.1 Message Confidentiality and Integrity . . . . . . . . . . 54 7.2 Peer Node Authentication . . . . . . . . . . . . . . . . . 55 7.3 Routing State Integrity . . . . . . . . . . . . . . . . . 55 7.4 Denial of Service Prevention . . . . . . . . . . . . . . . 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 59 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 61 9.1 Additional Discovery Mechanisms . . . . . . . . . . . . . 61 9.2 Alternative Message Routing Requirements . . . . . . . . . 61 9.3 Message Format Issues . . . . . . . . . . . . . . . . . . 62 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 64 10.1 Changes In Version -05 . . . . . . . . . . . . . . . . . 64 10.2 Changes In Version -04 . . . . . . . . . . . . . . . . . 65 10.3 Changes In Version -03 . . . . . . . . . . . . . . . . . 66 10.4 Changes In Version -02 . . . . . . . . . . . . . . . . . 67 Schulzrinne & Hancock Expires August 25, 2005 [Page 2] Internet-Draft GIMPS February 2005 10.5 Changes In Version -01 . . . . . . . . . . . . . . . . . 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 11.1 Normative References . . . . . . . . . . . . . . . . . . 71 11.2 Informative References . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 B. Example Message Routing State Table . . . . . . . . . . . . 75 C. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . 77 C.1 General NSIS Formatting Guidelines . . . . . . . . . . . . 77 C.2 The GIMPS Common Header . . . . . . . . . . . . . . . . . 78 C.3 General Object Characteristics . . . . . . . . . . . . . . 78 C.4 GIMPS Specific TLV Objects . . . . . . . . . . . . . . . . 79 C.5 Generic NSIS TLV Objects . . . . . . . . . . . . . . . . . 85 D. API between GIMPS and NSLP . . . . . . . . . . . . . . . . . 87 D.1 SendMessage . . . . . . . . . . . . . . . . . . . . . . . 87 D.2 RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 89 D.3 MessageStatus . . . . . . . . . . . . . . . . . . . . . . 90 D.4 NetworkNotification . . . . . . . . . . . . . . . . . . . 90 D.5 SetStateLifetime . . . . . . . . . . . . . . . . . . . . . 90 D.6 InvalidateRoutingState . . . . . . . . . . . . . . . . . . 91 Intellectual Property and Copyright Statements . . . . . . . 92 Schulzrinne & Hancock Expires August 25, 2005 [Page 3] Internet-Draft GIMPS February 2005 1. Introduction Signaling involves the manipulation of state held in network elements. 'Manipulation' could mean setting up, modifying and tearing down state; or it could simply mean the monitoring of state which is managed by other mechanisms. This specification concentrates specifically on the case of "path-coupled" signaling, which involves network elements which are located on the path taken by a particular data flow, possibly including but not limited to the flow endpoints. Indeed, there are almost always more than two participants in a path-coupled-signaling session, although there is no need for every router on the path to participate. Path-coupled signaling thus excludes end-to-end higher-layer application signaling (except as a degenerate case) such as ISUP (telephony signaling for Signaling System #7) messages being transported by SCTP between two nodes. In the context of path-coupled signaling, examples of state management include network resource allocation (for "resource reservation"), firewall configuration, and state used in active networking; examples of state monitoring are the discovery of instantaneous path properties (such as available bandwidth, or cumulative queuing delay). Each of these different uses of path-coupled signaling is referred to as a signaling application. Every signaling application requires a set of state management rules, as well as protocol support to exchange messages along the data path. Several aspects of this support are common to all or a large number of signaling applications, and hence should be developed as a common protocol. The framework given in [20] provides a rationale for a function split between the common and application specific protocols, and gives outline requirements for the former, the 'NSIS Transport Layer Protocol' (NTLP). This specification provides a concrete solution for the NTLP. It is based on the use of existing transport and security protocols under a common messaging layer, the General Internet Messaging Protocol for Signaling (GIMPS). Different signaling applications may make use of different services provided by GIMPS. However, GIMPS does not handle signaling application state itself; in that crucial respect, it differs from application signaling protocols such as the control component of FTP, SIP and RTSP. Instead, GIMPS manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signaling messages on behalf of signaling applications in both directions along the flow path. Schulzrinne & Hancock Expires August 25, 2005 [Page 4] Internet-Draft GIMPS February 2005 1.1 Restrictions on Scope This section briefly lists some important restrictions on GIMPS applicability and functionality. In some cases, these are implicit consequences of the functionality split developed in the framework; in others, they are restrictions on the types of scenario in which GIMPS can operate correctly. Flow splitting: In some cases, e.g. where packet-level load sharing has been implemented, the path taken by a single flow in the network may not be well defined. If this is the case, GIMPS cannot route signaling meaningfully. (In some circumstances, GIMPS can detect this condition, but even this cannot be guaranteed.) Multicast: GIMPS does not handle multicast flows. This includes 'classical' IP multicast and any of the 'small group multicast' schemes recently proposed. Schulzrinne & Hancock Expires August 25, 2005 [Page 5] Internet-Draft GIMPS February 2005 2. Requirements Notation and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. The terminology used in this specification is fully defined in this section. The basic entities relevant at the GIMPS level are shown in Figure 1. Source GIMPS (adjacent) peer nodes Destination IP address IP addresses = Signaling IP address = Flow Source/Destination Addresses = Flow Source (depending on signaling direction) Destination Address | | Address V V +--------+ +------+ Data Flow +------+ +--------+ | Flow |-----------|------|-------------|------|-------->| Flow | | Sender | | | | | |Receiver| +--------+ |GIMPS |============>|GIMPS | +--------+ | Node |<============| Node | +------+ Signaling +------+ GN1 Flow GN2 >>>>>>>>>>>>>>>>> = Downstream direction <<<<<<<<<<<<<<<<< = Upstream direction Figure 1: Basic Terminology [Data] Flow: A set of packets identified by some fixed combination of header fields. Flows are unidirectional (a bidirectional communication is considered a pair of unidirectional flows). Session: A single application layer flow of information for which some network control state information is to be manipulated or monitored. IP mobility may cause the mapping between sessions and flows to change, and IP multihoming may mean there is more than one flow for a given session. GIMPS implements the session concept by allowing signaling applications to associate messages with a Session Identifier; however, GIMPS does not place any constraints on how this association should be done. [Flow] Sender: The node in the network which is the source of the packets in a flow. Could be a host, or a router (e.g. if the flow is actually an aggregate). Schulzrinne & Hancock Expires August 25, 2005 [Page 6] Internet-Draft GIMPS February 2005 [Flow] Receiver: The node in the network which is the sink for the packets in a flow. Downstream: In the same direction as the data flow. Upstream: In the opposite direction to the data flow. GIMPS Node: Any node along the data path supporting GIMPS (regardless of what signaling applications it supports). Adjacent peer: The next GIMPS node along the data path, in the upstream or downstream direction. Whether two nodes are adjacent is determined implicitly by the GIMPS peer discovery mechanisms; it is possible for adjacencies to 'skip over' intermediate GIMPS nodes if it can be determined that they have no interest in the signaling messages being exchanged. Datagram mode: A mode of sending GIMPS messages between nodes without using any transport layer state or security protection. Datagram mode uses UDP encapsulation, with IP addresses derived either from the flow definition or previously discovered adjacency information; the details depend on the direction of the message. Connection mode: A mode of sending GIMPS messages directly between nodes using point to point "messaging associations" (see below). Connection mode allows the re-use of existing transport and security protocols where such functionality is required. Messaging association: A single connection between two explicitly identified GIMPS adjacent peers, i.e. between a given signaling source and destination address. A messaging association may use a specific transport protocol and known ports. If security protection is required, it may use a specific network layer security association, or use a transport layer security association internally. A messaging association is bidirectional; signaling messages can be sent over it in either direction, and can refer to flows of either direction. Message Routing Method: Even in the path-coupled case, there can be different alogorithms for discovering the route that signaling messages should take. These are referred to as message routing methods, and GIMPS supports alternatives within a common protocol framework. See also Section 4.2.1. Transfer Attributes: A description of the requirements which a signaling application has for the delivery of a particular message; for example, whether the message should be delivered reliably. See Section 4.1.2. Schulzrinne & Hancock Expires August 25, 2005 [Page 7] Internet-Draft GIMPS February 2005 3. Design Overview 3.1 Overall Design Approach The generic requirements identified in the NSIS framework [20] for transport of path-coupled signaling messages are essentially two-fold: "Routing": Determine how to reach the adjacent signaling node along each direction of the data path (the GIMPS peer), and if necessary explicitly establish the identity of that peer; "Transport": Deliver the signaling information to that peer. To meet the routing requirement, one possibility is for the node to use local routing state information to determine the identity of the GIMPS peer explicitly. GIMPS defines a 3-way handshake (Query/Response/optional Confirm) which sets up the necessary routing state between adjacent peers; the Query message is encapsulated in a special way, depending on the message routing method, in order to probe the network infrastructure so that the correct peer will intercept it. If the routing state does not exist, it may be possible for GIMPS to send a message anyway, with the same encapsulation tricks as used for a Query. Once the routing decision has been made, the node has to select a mechanism for transport of the message to the peer. GIMPS divides the transport problems into two categories, the easy and the difficult ones. It handles the easy cases internally, and uses well-understood reliable transport protocols for the harder cases. Here, with details discussed later, "easy" messages are those that are sized well below the lowest MTU along a path, are infrequent enough not to cause concerns about congestion and flow control, and do not need transport or network-layer security protection or guaranteed delivery. In [20] all of these routing and transport requirements are assigned to a single notional protocol, the 'NSIS Transport Layer Protocol' (NTLP). The strategy of splitting the transport problem leads to a layered structure for the NTLP, as a specialised GIMPS 'messaging' layer running over standard transport and security protocols, as shown in Figure 2. This also shows GIMPS offering its services to upper layers at an abstract interface, the GIMPS API, further discussed in Section 4.1. Internally, GIMPS has two modes of operation: Schulzrinne & Hancock Expires August 25, 2005 [Page 8] Internet-Draft GIMPS February 2005 Datagram mode is used for small, infrequent messages with modest delay constraints; it is also used at least for the Query message of the 3-way handshake. Connection mode is used for larger data objects or where fast state setup in the face of packet loss is desirable, or where channel security is required. ^^ +-------------+ || | Signaling | NSIS +------------|Application 2| Signaling | Signaling +-------------+ Application |Application 1| | Level +-------------+ | || | | VV | | =========|===================|===== <-- GIMPS API | | ^^ +------------------------------------------------+ || |+-----------------------+ +--------------+ | || || GIMPS | | GIMPS State | | || || Encapsulation |<<<>>>| Maintenance | | || |+-----------------------+ +--------------+ | || |GIMPS: Messaging Layer | || +------------------------------------------------+ NSIS | | | | Transport ............................. Level . Transport Layer Security . ("NTLP") ............................. || | | | | || +----+ +----+ +----+ +----+ || |UDP | |TCP | |SCTP| |DCCP|.... || +----+ +----+ +----+ +----+ || | | | | || ............................. || . IP Layer Security . || ............................. VV | | | | =========================|=======|=======|=======|=============== | | | | +----------------------------------------------+ | IP | +----------------------------------------------+ Figure 2: Protocol Stacks for Signaling Transport Datagram mode uses UDP, as this is the only encapsulation which does Schulzrinne & Hancock Expires August 25, 2005 [Page 9] Internet-Draft GIMPS February 2005 not require shared state to be established between the peers. The connection mode can in principal use any stream or message-oriented transport protocol; this specification currently defines the use of TCP as the initial choice. It may employ specific network layer security associations (such as IPsec), or an internal transport layer security association (such as TLS). It is possible to mix these two modes along a chain of nodes, without coordination or manual configuration. This allows, for example, the use of datagram mode at the edges of the network and connection mode in the core of the network. Such combinations may make operation more efficient for mobile endpoints, while allowing multiplexing of signaling messages across shared security associations and transport connections between core routers. It must be understood that the routing and transport decisions made by GIMPS are not totally independent. If the message transfer has requirements that enforce the use of connection mode (e.g. the message is so large that fragmentation is required), this can only be used between explicitly identified nodes. In such cases, GIMPS must carry out the 3-way handshake initially in datagram mode to identify the peer and then set up the necessary transport connection if it does not already exist. It must also be understood that the signaling application does not make the datagram vs. connection mode selection directly; rather, this decision is made by GIMPS on the basis of the message characteristics and the transfer attributes stated by the application. The distinction is not visible at the GIMPS service interface. In general, the state associated with connection mode messaging to a particular peer (signaling destination address, protocol and port numbers, internal protocol configuration and state information) is referred to as a "messaging association". There may be any number of messaging associations between two GIMPS peers (although the usual case is 0 or 1), and they are set up and torn down by management actions within GIMPS itself. 3.2 Example of Operation This section presents an example of GIMPS usage in a relatively simple (in particular, NAT-free) signaling scenario, to illustrate its main features. Consider the case of an RSVP-like signaling application which allocates resources for a flow from sender to receiver. We will consider how GIMPS transfers messages between two adjacent peers along the path, GN1 and GN2 (see Figure 1). In this example, the end-to-end exchange is initiated by the signaling application Schulzrinne & Hancock Expires August 25, 2005 [Page 10] Internet-Draft GIMPS February 2005 instance in the sender; we take up the story at the point where the first message is being processed (above the GIMPS layer) by the signaling application in GN1. 1. The signaling application in GN1 determines that this message is a simple description of resources that would be appropriate for the flow. It determines that it has no special security or transport requirements for the message, but simply that it should be transferred to the next downstream signaling application peer on the path that the flow will take. 2. The message payload is passed to the GIMPS layer in GN1, along with a definition of the flow and description of the message transfer attributes {downstream, unsecured, unreliable}. GIMPS determines that this particular message does not require fragmentation and that it has no knowledge of the next peer for this flow and signaling application; however, it also determines that this application is likely to require secured upstream and downstream transport of large messages in the future. This determination is a function of node-local policy, and some options for how it may be communicated between NSLP and GIMPS implementations within a node are indicated in Appendix D. 3. GN1 therefore constructs a GIMPS-Query message, which is a UDP datagram carrying the signaling application payload and additional payloads at the GIMPS level to be used to initiate the setup of a messaging association. The Query is injected into the network, addressed towards the flow destination and with a Router Alert Option included. 4. The Query message passes through the network towards the flow receiver, and is seen by each router in turn. GIMPS-unaware routers will not recognise the RAO value and will forward the message unchanged; GIMPS-aware routers which do not support the signaling application in question will also forward the message basically unchanged, although they may need to process more of the message to decide this. 5. The message is intercepted at GN2. The GIMPS layer identifies the message as relevant to a local signaling application, and passes the signaling application payload and flow description upwards to it. There, the signaling application in GN2 continues to process this message as in GN1 (compare step 1), and this will eventually result in the message reaching the flow receiver. 6. In parallel, the GIMPS instance in GN2 recognises, by the fact that the message is a GIMPS-Query, that GN1 is attempting to discover GN2 in order to set up a messaging association for Schulzrinne & Hancock Expires August 25, 2005 [Page 11] Internet-Draft GIMPS February 2005 future signaling for the flow. There are two possible cases for sending back the necessary GIMPS-Response: A. GN1 and GN2 already have an appropriate association. GN2 simply records the identity of GN1 as its upstream peer for that flow and signaling application, and sends a GIMPS-Response back to GN1 over the association identifying itself as the peer for this flow. B. No messaging association exists. Again, GN2 records the identity of GN1 as before, but sends a GIMPS-Response upstream to GN1, identifying itself and agreeing to the association setup. The protocol exchanges needed to complete this will proceed in the background, controlled by GN1. 7. Eventually, another signaling application message works its way upstream from the receiver to GN2. This message contains a description of the actual resources requested, along with authorisation and other security information. The signaling application in GN2 passes this payload to the GIMPS level, along with the flow definition and transfer attributes {upstream, secured, reliable}. 8. The GIMPS layer in GN2 identifies the upstream peer for this flow and signaling application as GN1, and determines that it has a messaging association with the appropriate properties. The message is queued on the association for transmission (this may mean some delay if the negotiations begun in step 6.B have not yet completed). Further messages can be passed in each direction in the same way. The GIMPS layer in each node can in parallel carry out maintenance operations such as route change detection (this can be done by sending additional GIMPS-Query messages, see Section 6.1 for more details). Note that when GIMPS messages are carried in connection mode, they are treated just like any other traffic by intermediate routers between the GIMPS peers. Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used. In connection mode, signaling messages are only ever delivered between peers established in GIMPS-Query/Response exchanges. Any route change is not detected until another GIMPS-Query/Response procedure takes place; in the meantime, signaling messages are misdelivered. GIMPS is responsible for prompt detection of route changes to minimise the period during which this can take place. Schulzrinne & Hancock Expires August 25, 2005 [Page 12] Internet-Draft GIMPS February 2005 It should be understood that several of these details of GIMPS operations can be varied, either by local policy or according to signaling application requirements, and they are also subject to development and refinement as the protocol design proceeds. The authoritative details are contained in the remainder of this document. Schulzrinne & Hancock Expires August 25, 2005 [Page 13] Internet-Draft GIMPS February 2005 4. GIMPS Processing Overview This section defines the basic structure and operation of GIMPS. It is divided into four parts. Section 4.1 describes the way in which GIMPS interacts with (local) signaling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIMPS maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and associated routing state already exist; this includes the simple scenario of pure datagram mode operation, where no messaging associations are necessary in the first place. Finally, Section 4.4 describes how routing state is maintained and how messaging associations are initiated and terminated. 4.1 GIMPS Service Interface This section defines the service interface that GIMPS presents to signaling applications in terms of abstract properties of the message transfer. Note that the same service interface is presented at every GIMPS node; however, applications may invoke it differently at different nodes (e.g. depending on local policy). In addition, the service interface is defined independently of any specific transport protocol, or even the distinction between datagram and connection mode. The initial version of this specification defines how to support the service interface using a connection mode based on TCP; if additional transport protocol support is added, this will support the same interface and so be invisible to applications (except as a possible performance improvement). A more detailed specification of this service interface is given in Appendix D. 4.1.1 Message Handling Fundamentally, GIMPS provides a simple message-by-message transfer service for use by signaling applications: individual messages are sent, and individual messages are received. Messages consist of an opaque signaling application payload, and control information expressing the application's requirements about how the message should be routed. Additional message transfer attributes control the specific transport and security properties that the signaling application desires for the message. The distinction between GIMPS connection and datagram modes is not visible at the service interface. In addition, the invocation of GIMPS functionality to handle fragmentation and reassembly, bundling together of small messages (for efficiency), and congestion control are not directly visible at the service interface; GIMPS will take whatever action is necessary based on the properties of the messages Schulzrinne & Hancock Expires August 25, 2005 [Page 14] Internet-Draft GIMPS February 2005 and local node state. Messages for different sessions (i.e. with different Session IDs, see Section 4.2.1) are treated entirely independently of each other by GIMPS. Messages for the same session which are to be delivered reliably (see below) to the same peer will be delivered in order. If the receiving application delays reading these messages, this will (eventually) cause a flow-control condition at the sending node. 4.1.2 Message Transfer Attributes Message transfer attributes are used to define certain performance-related aspects of message processing. The attributes available are as follows: Reliability: This attribute may be 'true' or 'false'. For the case 'true', messages will be delivered to the signaling application in the peer exactly once or not at all; if there is a chance that the message was not delivered, an error will be indicated to the local signaling application identifying the routing information for the message in question. For the case 'false', a message may be delivered, once, several times or not at all, with no error indications in any case. Security: This attribute defines the security properties that the signaling application requires for the message, including the type of protection required, and what authenticated identities should be used for the signaling source and destination. This information maps onto the corresponding properties of the security associations established between the peers in connection mode, It can be specified explicitly by the signaling application, or reported by GIMPS to the signaling application (either on receiving a message, or just before sending a message but after configuring or selecting the messaging association to be used for it). Further details are discussed in Appendix D. Local Processing: An NSLP may provide hints to GIMPS to enable more efficient or appropriate processing. The NSLP may select a priority from a range of locally defined values to influence the sequence in which messages leave a node. Any priority mechanism must respect the ordering requirements for reliable messages within a session, and priority values are not carried in the protocol or available at the signaling peer or intermediate nodes. An NSLP may also indicate that reverse path routing state will not be needed for this flow, to inhibit the node requesting its downstream peer to create it. Schulzrinne & Hancock Expires August 25, 2005 [Page 15] Internet-Draft GIMPS February 2005 4.2 GIMPS State 4.2.1 Message Routing State For each flow, the GIMPS layer can maintain message routing state to manage the processing of outgoing messages. This state is conceptually organised into a table with the following structure. The primary key (index) for the table is the combination of the information about how the message is to be routed, the session being signalled for, and the signaling application itself: Message Routing Information (MRI): This defines the method to be used to route the message, and any associated addressing information. In the commonest case, the message routing method is to follow the path that is being taken by the data flow, and the associated addressing is the flow header N-tuple (i.e. the Flow-Identifier of [20]). Other message routing methods are possible, as described for example in [29]. Signaling Application Identification (NSLPID): This is an IANA assigned identifier of the signaling application which is generating messages for this flow. The inclusion of this identifier allows the routing state to be different for different signaling applications (e.g. because of different adjacencies). Session Identification (SID): This is a cryptographically random and (probabilistically) globally unique identifier of the application layer session that is using the flow. For a given flow, different signaling applications may or may not use the same session identifier. Often there will only be one flow for a given session, but in mobility/multihoming scenarios there may be more than one and they may be differently routed. For a given MRI and NSLPID the message routing state should not be SID-dependent. The SID is included in the key as a barrier to routing state being corrupted by a malicious upstream node. The state information for a given key consists of two items, namely the information needed to send messages to the peers in each direction respectively. In each case, the information could be an IP address and UDP port, or a pointer to a valid messaging association, either of which can be learned from a prior GIMPS handshake. Additional information about the number of IP hops to the peer is also stored in the table for each direction. An example of a routing state table for a simple scenario is given in Appendix B. It is also possible for the state information for either direction to Schulzrinne & Hancock Expires August 25, 2005 [Page 16] Internet-Draft GIMPS February 2005 be null. There are several possible cases: o The signaling application has indicated that no messages will actually be sent in that direction. o The node is a flow endpoint, so there can be no signaling peer in one or other direction. o The node can use other techniques to route the message. For example, it could encapsulate it the same way as a Query message and rely on the peer to intercept it. In addition, the SID itself is not actually required for message processing; in that case, no state information at all needs to be stored in the table. Both items of state have associated timers for how long the identification can be considered accurate; when these timers expire, the peer identification is purged if it has not been refreshed. Message routing state is installed and refreshed by the exchange of GIMPS-Query/Response messages as described in Section 4.4. For a given flow, the GIMPS node which initiated the state setup is responsible for scheduling a Query/Response exchange to refresh it, and to allow its peer to do likewise. This should be done while GIMPS determines the signaling application is still active. GIMPS may opportunistically synchronise these 'internal' refresh operations with those in the signaling application if it wishes. Note also that the information is described as a table of flows, but that there is no implied constraint on how the information is stored. For example, in a network using pure destination address routing (without load sharing or any form of policy-based forwarding), the downstream peer information might be possible to store in an aggregated form in the same manner as the IP forwarding table. In addition, many of the per-flow entries may point to the same per-peer state (e.g. the same messaging association) if the flows go through the same adjacent peer. However, in general, and especially if GIMPS peers are several IP hops away, there is no way to identify the correct downstream peer for a flow and signaling application from the local forwarding table using prefix matching, and the same applies always to upstream peer state because of the possibility of asymmetric routing: per-flow routing state has to be stored, just as for RSVP [9]. 4.2.2 Messaging Association State The per-flow message routing state is not the only state stored by GIMPS. There is also the state required to manage the messaging Schulzrinne & Hancock Expires August 25, 2005 [Page 17] Internet-Draft GIMPS February 2005 associations. Since these associations are typically per-peer rather than per-flow, they are stored in a separate table, including the following information: o messages pending transmission while an association is being established; o an inactivity timer for how long the association has been idle. In addition, per-association state is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIMPS, and they do not affect the rest of the protocol description. 4.3 Basic Message Processing This section describes how signaling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. Firstly, message reception, local processing and message transmission are described for the case where the node handles the NSLPID in the message. Secondly, the case where the message is forwarded directly in the IP or GIMPS layer (because there is no matching signaling application on the node) is given. An overview is given in Figure 3. Note that the same messages are used both for maintaining internal GIMPS state and carrying signaling application payloads. The state maintenance takes place as a result of processing specific GIMPS payloads in these messages. The processing of these payloads is the subject of Section 4.4. 4.3.1 Message Reception Messages can be received in connection or datagram mode, and from upstream or downstream peers. Reception in connection mode is simple: incoming packets undergo the security and transport treatment associated with the messaging association, and the messaging association provides complete messages to the GIMPS layer for further processing. Unless the message is protected by a query/response cookie exchange (see Section 4.4), the routing state table is checked to ensure that this messaging association is associated with the MRI/NSLPID combination. Reception in datagram mode depends on the message type. 'Normal' messages arrive UDP encapsulated and addressed directly to the receiving signaling node, at an address and port learned during a Schulzrinne & Hancock Expires August 25, 2005 [Page 18] Internet-Draft GIMPS February 2005 previous handshake. Each datagram contains a single complete message which is passed to the GIMPS layer for further processing, just as in the connection mode case. +---------------------------------------------------------+ | >> Signaling Application Processing >> | | | +--------^---------------------------------------V--------+ ^ V ^ NSLP Payloads V ^ V +--------^---------------------------------------V--------+ | >> GIMPS >> | | ^ ^ ^ Processing V V V | +--x-----------N--Q---------------------Q--N-----------x--+ x N Q Q N x x N Q>>>>>>>>>>>>>>>>>>>>>Q N x x N Q Bypass at Q N x +--x-----+ +--N--Q--+ GIMPS level +--Q--N--+ +-----x--+ | C-mode | | D-mode | | D-mode | | C-mode | |Handling| |Handling| |Handling| |Handling| +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ x N Q Q N x x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x x N Q Bypass at Q N x +--x--N--+ +-----Q--+ router +--Q-----+ +--N--x--+ |IP Host | | RAO | alert level | RAO | |IP Host | |Handling| |Handling| |Handling| |Handling| +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ x N Q Q N x +--x--N-----------Q--+ +--Q-----------N--x--+ | IP Layer | | IP Layer | | (Receive Side) | | (Transmit Side) | +--x--N-----------Q--+ +--Q-----------N--x--+ x N Q Q N x x N Q Q N x x N Q Q N x NNNNNNNNNNNNNN = 'Normal' datagram mode messages QQQQQQQQQQQQQQ = Datagram mode messages which are Queries or likewise encapsulated xxxxxxxxxxxxxx = connection mode messages RAO = Router Alert Option Figure 3: Message Paths through a GIMPS Node Where GIMPS is sending messages to be intercepted by the appropriate Schulzrinne & Hancock Expires August 25, 2005 [Page 19] Internet-Draft GIMPS February 2005 peer rather than directly addressed to it (in particular, Query messages), these are UDP encapsulated with an IP router alert option. Each signaling node will therefore 'see' all such messages. The case where the NSLPID does not match a local signaling application is considered below in Section 4.3.4; otherwise, it is passed up to the GIMPS layer for further processing as in the other cases. 4.3.2 Local Processing Once a message has been received, by any method, it is processed locally within the GIMPS layer. The GIMPS processing to be done depends on the payloads carried; most of the GIMPS-internal payloads are associated with state maintenance and are covered in Section 4.4. One GIMPS-internal payload which is carried in each message and requires processing is the GIMPS hop count. This is decremented on input processing, and checked to be greater than zero on output processing. The primary purpose of the GIMPS hop count is to prevent message looping. The remainder of the GIMPS message consists of an NSLP payload. This is delivered locally to the signaling application identified at the GIMPS level; the format of the NSLP payload is not constrained by GIMPS, and the content is not interpreted. Signaling applications can generate their messages for transmission, either asynchronously, or in response to an input message, and GIMPS can also generate messages autonomously. Regardless of the source, outgoing messages are passed downwards for message transmission. 4.3.3 Message Transmission When a message is available for transmission, GIMPS uses internal policy and the stored routing state to determine how to handle it. The following processing applies equally to locally generated messages and messages forwarded from within the GIMPS or signaling application levels. The main decision is whether the message must be sent in connection mode or datagram mode. Reasons for using the former could be: o NSLP requirements: for example, the signaling application has requested channel secured delivery, or reliable delivery; o protocol specification: for example, this document specifies that a message that requires fragmentation MUST be sent over a messaging association; Schulzrinne & Hancock Expires August 25, 2005 [Page 20] Internet-Draft GIMPS February 2005 o local GIMPS policy: for example, a node may prefer to send messages over a messaging association to benefit from adaptive congestion control. In principle, as well as determining that some messaging association must be used, GIMPS could select between a set of alternatives, e.g. for load sharing or because different messaging associations provide different transport or security attributes. If the use of a messaging association is selected, the message is queued on the association (found from the upstream or downstream peer state table), and further output processing is carried out according to the details of the protocol stack used for the association. If no appropriate association exists, the message is queued while one is created (see Section 4.4). If no association can be created, this is an error condition, and should be indicated back to the NSLP. If a messaging association is not required, the message is sent in datagram mode. The processing in this case depends on the message type and whether routing state exists or not. o If the message is not a Query, and routing state exists, it is UDP encapsulated and sent directly to that address. o If the message is a Query, the it is UDP encapsulated with IP address and router alert option determined from the MRI and NSLPID (the details depend on the message routing method itself). o If no routing state exists, GIMPS can attempt to use the same IP/UDP encapsulation as in the Query case. If this is not possible (e.g. because the encapsulation algorithm for the message routing method is only defined valid for one message direction), then this is an error condition which is reported back to the local signaling application. 4.3.4 Bypass Forwarding A GIMPS node may have to handle messages for which it has no signaling application corresponding to the message NSLPID. There are several possible cases depending mainly on the RAO setting (see Section 5.3.2.1 for more details): 1. A datagram mode message contains an RAO value which is relevant to NSIS but not the specific node, but the IP layer is unable to recognise whether it needs to be passed to GIMPS for further processing or whether the packet should be forwarded just like a normal IP datagram. Schulzrinne & Hancock Expires August 25, 2005 [Page 21] Internet-Draft GIMPS February 2005 2. A datagram mode message contains an RAO value which is relevant to the node, but the specific signaling application for the actual NSLPID in the message is not processed there. 3. A message is delivered directly to the node for which there is no corresponding signaling application. (According to the rules of the current specification, this should never happen. However, future versions might find a use for such a feature.) In all cases, the role of GIMPS is to forward the message essentially unchanged. However, a GIMPS implementation must ensure that the IP TTL field and GIMPS hop count are managed correctly to prevent message looping, and this should be done consistently independently of whether the processing (e.g. for case (1)) takes place on the fast path or in GIMPS-specific code. The rules are that in cases (1) and (2), the IP TTL is decremented just as if the message was a normal IP forwarded packet; in cases (2) and (3) the GIMPS hop count is decremented as in the case of normal input processing. These rules are summarised in the following table: +-------------+-------------+-------------------+-------------------+ | Match RAO? | Match | IP TTL Handling | GHC Handling | | | NSLPID? | | | +-------------+-------------+-------------------+-------------------+ | No | N/A (NSLPID | Decrement; | Ignore | | | not | forward message | | | | examined) | | | | | | | | | Yes | No | Decrement; | Decremented | | | | forward message | | | | | | | | Message | No | Reset | Decrement and | | directly | | | forward at GIMPS | | addressed | | | level (not | | | | | possible in | | | | | current | | | | | specification) | | | | | | | Yes, or | Yes | Locally delivered | N/A (ignored) | | message | | | | | directly | | | | | addressed | | | | +-------------+-------------+-------------------+-------------------+ 4.4 Routing State and Messaging Association Maintenance The main responsibility of the GIMPS layer is to manage the routing Schulzrinne & Hancock Expires August 25, 2005 [Page 22] Internet-Draft GIMPS February 2005 state and messaging associations which are used in the basic message processing described above. Routing state is installed and maintained by datagram mode messages containing specific GIMPS payloads. Messaging associations are dependent on the existence of routing state, but are actually set up by the normal procedures of the transport and security protocols that comprise them. Timers control routing state and messaging association refresh and expiration. There are two different cases for state installation and refresh: 1. Where routing state is being discovered or a new association is to be established; and 2. Where an existing association can be re-used, including the case where routing state for the association is being refreshed. These cases are now considered in turn, along with the case of general management procedures. 4.4.1 State Setup The complete sequence of possible messages for state setup between adjacent peers is shown in Figure 4 and described in detail in the following text. The initial message in any routing state maintenance operation is a GIMPS-Query message, sent from the querying node and intercepted at the responding node. This has addressing and other identifiers appropriate for the flow and signaling application that state maintenance is being done for, addressing information about the node itself, and it is allowed to contain an NSLP payload. The querying node also includes additional payloads: a Query Cookie, and optionally a proposal for possible messaging association protocol stacks. The role of the cookies in this and subsequent messages is to protect against certain denial of service attacks and to correlate the various events in the message sequence. In the responding node, the GIMPS level processing of the GIMPS-Query triggers the generation of a 'GIMPS-Response' message. This is a 'normally' encapsulated datagram mode message with additional payloads. It contains addressing information about the responding node, it echoes the Query Cookie, and can contain an NSLP payload (possibly a response to the NSLP payload in the initial message). In case a messaging association was requested, it must also contain a Responder Cookie and counter proposal for the stack configuration. Otherwise, it may still include a Responder Cookie if the node's routing state setup policy requires it (see below). Schulzrinne & Hancock Expires August 25, 2005 [Page 23] Internet-Draft GIMPS February 2005 +----------+ +----------+ | Querying | |Responding| | Node | | Node | +----------+ +----------+ GIMPS-query ----------------------> ............. Router Alert Option . Routing . MRI/SID/NSLPID . state . Q-Node Addressing . installed . Query Cookie . at . [Q-Stack Proposal] . R-node(1) . [NSLP Payload] ............. ...................................... . The responder can use an existing . . messaging association if available . . from here onwards to short-circuit . . messaging association setup . ...................................... GIMPS-response ............. <---------------------- . Routing . MRI/SID/NSLPID . state . R-Node Addressing (D Mode only) . installed . Query cookie . at . [R-Stack Proposal] . Q-node . [Responder Cookie] ............. [NSLP Payload] .................................... . If a messaging association needs . . to be created, it is set up here . .................................... GIMPS-confirm ----------------------> MRI/SID/NSLPID Q-Node Addressing (D Mode only) Responder Cookie ............. [R-Stack Proposal] . Routing . [NSLP Payload] . state . . installed . . at . . R-node(2) . ............. Figure 4: Message Sequence at State Setup Schulzrinne & Hancock Expires August 25, 2005 [Page 24] Internet-Draft GIMPS February 2005 Setup of a new messaging association begins when both peer addressing information is available at the Querying node, and a new messaging association is actually needed. The setup has to be contemporaneous with a specific GIMPS-Query/Response exchange, because the addressing information used may have a limited lifetime (either because it depends on limited lifetime NAT bindings, or because it refers to agile destination ports for the transport protocols). Setup of the messaging association always starts from the Querying node, but the association itself can be used equally in both directions. The GIMPS-Confirm is the first message sent over the association and echoes the Responder Cookie and Stack Proposal from the GIMPS-Response (the latter is to prevent certain bidding-down attacks on messaging association security); the assocation can be used in the upstream direction for that flow and NSLPID after the Confirm has been received. The negotiation of what protocols to use for the messaging association is controlled by the Stack-Proposal and Node-Addressing information exchanged, and the processing of these objects is described in more detail in Section 5.5. The querying node installs the responder address as peer state information after verifying the Query Cookie in the GIMPS-Response. The responding node can install the querying address as peer state information at two points in time: 1. after the receipt of the initial GIMPS-Query, or 2. after a GIMPS-Confirm message containing the Responder Cookie. The detailed constraints on precisely when state information is installed are driven by local policy driven by security considerations on prevention of denial-of-service attacks and state poisoning attacks, which are discussed further in Section 7. 4.4.2 Association Re-use It is a general design goal of GIMPS that, so far as possible, messaging associations should be re-used for multiple flows and sessions, rather than a new association set up for each. This is to ensure that the association cost scales like the number of peers rather than the number of flows or messages, and to avoid the latency of new association setup where possible. However, association re-use requires the identification of an existing association which matches the same routing state and desired properties that would be the result of a full handshake in D-mode, and this identification must be done as reliably and securely as continuing with the full procedure. Note that this requirement is Schulzrinne & Hancock Expires August 25, 2005 [Page 25] Internet-Draft GIMPS February 2005 complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (with different addresses). Association re-use is controlled by two fields in the Node-Addressing object (NAO), which is carried in GIMPS-query and GIMPS-response messages. The NAO includes: Peer-Identity: For a given node, this is a stable quantity (interface independent) with opaque syntax. It should be chosen so as to have a high probability of uniqueness between peers. Note that there is no cryptographic protection of this identity (attempting to provide this would essentially duplicate the functionality in the messaging association security protocols). Interface-Address: This is an IP address associated with the interface through which the flow associated with the signaling is routed. This can be considered as a routable identifier through which the signaling node can be reached; further discussion is contained in Section 5.5. By default, a messaging association is associated with the NAO that was provided by the peer at the time the assocation was set up. There may be more than one association for a given NAO (e.g. with different properties). Association re-use is controlled by matching the NAO provided in a GIMPS message with those associated with existing associations. This can be done on receiving either a GIMPS-Query or GIMPS-Response (the former is more likely): o If there is a perfect match to the NAO of an existing association, that association can be re-used (provided it has the appropriate properties in other respects). This is indicated by sending the following messages in the handshake over that association, omitting the NAO information. This will only fail (i.e. lead to re-use of an assocation to the 'wrong' node) if signaling nodes have colliding Peer-Identities, and one is reachable at the same Interface-Address as another. (This could be done by an on-path attacker.) o In all other cases, the full handshake is executed in datagram mode as usual. There are in fact four cases: 1. Nothing matches: this is clearly a new peer. 2. Only the Peer-Identity matches: this may be either a new interface on an existing peer, or a changed address mapping Schulzrinne & Hancock Expires August 25, 2005 [Page 26] Internet-Draft GIMPS February 2005 behind a NAT, or an attacker attempting to hijack the Peer-Identity. These should be rare events, so the expense of a new assocation setup is acceptable. If the authenticated peer identities match after assocation setup, the two Interface-Addresses may be bound to the assocation. 3. Only the Interface-Address matches: this is probably a new peer behind the same NAT as an existing one. A new assocation setup is required. 4. The full NAO matches: this is a degenerate case, where one node recognises an existing peer, but wishes to allow the option to set up a new association in any case. 4.4.3 Background Maintenance Refresh and expiration of all types of state is controlled by timers. State in the routing table has a per-flow, per-direction timer, which expires after a routing state lifetime. It is the responsibility of the Querying node to generate a GIMPS-Query message before this timer expires, if it believes that the flow is still active. Receipt of the message at the responding node will refresh peer addressing state for one direction, and receipt of a GIMPS-Response at the querying node will refresh it for the other. Note that responding nodes do not control the refresh of routing state themselves, they are dependent on their peer for this. Messaging associations can be managed by either end; management consists of tearing down unneeded associations. Whether an association is needed is a local policy decision, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity (e.g. if there are flows still in place which might generate messages that would use it). Messaging associations can always be set up on demand, and messaging association status is not made directly visible outside the GIMPS layer. Therefore, even if GIMPS tears down and later re-establishes a messaging association, signaling applications cannot distinguish this from the case where the association is kept permanently open. (To maintain the transport semantics decribed in Section 4.1, GIMPS must close transport connections carrying reliable messages gracefully or report an error condition, and must not open a new association for a given session and peer while messages on a previous association may still be outstanding.) Schulzrinne & Hancock Expires August 25, 2005 [Page 27] Internet-Draft GIMPS February 2005 5. Message Formats and Transport 5.1 GIMPS Messages All GIMPS messages begin with a common header, which includes a version number, information about message type, signaling application, and additional control information. The remainder of the message is encoded in an RSVP-style format, i.e., as a sequence of type-length-value (TLV) objects. This subsection describes the possible GIMPS messages and their contents at a high level; a more detailed description of each information element is given in Section 5.2. The following gives the syntax of GIMPS messages in ABNF [3]. GIMPS-Message: A message is either a one of the stages in the 3-way handshake, or a simple message carrying NSLP data. GIMPS-Message = GIMPS-Query / GIMPS-Response / GIMPS-Confirm / GIMPS-Data GIMPS-Query: A GIMPS-Query is always sent in datagram mode. As well as the common header, it contains certain mandatory control objects, and may contain a signaling application payload. A stack proposal is mandatory if the message exchange relates to setup of a messaging association. GIMPS-Query = Common-Header Message-Routing-Information Session-Identification Node-Addressing Query-Cookie [ Stack-Proposal ] [ Routing-State-Lifetime ] [ NSLP-Data ] GIMPS-Response: A GIMPS-Response may be sent in datagram or connection mode (if a messaging association is being re-used). It echoes the MRI, SID and Query-Cookie of the Query, and carries its own Node-Addresing information; if the message exchange relates to setup of a messaging association (which can only take place in datagram mode), a Responder cookie is mandatory, and it must also contain its own Stack-Proposal. GIMPS-Response = Common-Header Message-Routing-Information Session-Identification Node-Addressing Schulzrinne & Hancock Expires August 25, 2005 [Page 28] Internet-Draft GIMPS February 2005 Query-Cookie [ Responder-Cookie [ Stack-Proposal ] ] [ Routing-State-Lifetime ] [ NSLP-Data ] GIMPS-Confirm: A GIMPS-Confirm may be sent in datagram or connection mode (if a messaging association has been re-used). It echoes the MRI, SID and Responder-Cookie of the Response; if the message exchange relates to setup of a new messaging association or reuse of an existing one (which can only take place in connection mode), the message must also echo the Stack-Proposal from the GIMPS-Response so it can be verified that this has not been tampered with. GIMPS-Confirm = Common-Header Message-Routing-Information Session-Identification Node-Addressing Responder-Cookie [ Stack-Proposal ] [ Routing-State-Lifetime ] [ NSLP-Data ] GIMPS-Data: A plain data message contains no control objects, but only the MRI and SID assocated with the NSLP data being transferred. Node-Addressing information is only carried in the datagram mode case. GIMPS-Data = Common-Header Message-Routing-Information Session-Identification [ Node-Addressing ] NSLP-Data 5.2 Information Elements This section describes the content of the various information elements that can be present in each GIMPS message, both the common header, and the individual TLVs. The format description in terms of bit patterns is provided in Appendix C. 5.2.1 The Common Header Each message begins with a fixed format common header, which contains the following information: Schulzrinne & Hancock Expires August 25, 2005 [Page 29] Internet-Draft GIMPS February 2005 Version: The version number of the GIMPS protocol. Length: The number of words in the message following the common header. Signaling application identifier (NSLPID): This describes the specific signaling application, such as resource reservation or firewall control. GIMPS hop counter: A hop counter to prevent a message from looping indefinitely. Message type: The message type (Query, Response, etc.) Source addressing mode: A flag to indicate whether the IP source address of the message was set to be the signaling source address, or whether it was derived from the message routing information in the payload. 5.2.2 TLV Objects All data following the common header is encoded as a sequence of type-length-value objects. Currently, each object can occur at most once; the set of required and permitted objects is determined by the message type and further information in the common header. These items are contained in each GIMPS message: Message-Routing-Information (MRI): Information sufficient to define how the signaling message should be routed through the network. Message-Routing-Information = message-routing-method method-specific-information The format of the method-specific-information depends on the message-routing-method requested by the signaling application. In the basic path-coupled case, it is just the Flow Identifier as in [20]. Minimally, this could just be the flow destination address; however, to account for policy based forwarding and other issues a more complete set of header fields should be used (see Section 6.2 and Section 6.3 for further discussion). The MRI is essentially a read only object for GIMPS processing. It is set by the NSLP in the message sender and used by GIMPS to select the message addressing, but not otherwise modified. Note that every message routing method must implicitly define a directionality (upstream vs. downstream), corresponding to the Schulzrinne & Hancock Expires August 25, 2005 [Page 30] Internet-Draft GIMPS February 2005 two directions in the routing state table, and the MRI must include control information which says in which direction this message is being sent. Flow-Identifier = network-layer-version source-address prefix-length destination-address prefix-length IP-protocol traffic-class [ flow-label ] [ ipsec-SPI / L4-ports] Additional control information defines whether the flow-label, SPI and port information are present, the direction of the message relative to this flow, and whether the IP-protocol and traffic-class fields should be interpreted as significant. Session-Identification (SID): The GIMPS session identifier is a long, cryptographically random identifier chosen by the node which originates the signaling exchange. The length is open, but 128 bits should be more than sufficient to make the probability of collisions orders of magnitude lower than other failure reasons. The session identifier should be considered immutable end-to-end along the flow path (GIMPS never changes it, and signaling applications should propagate it unchanged on messages for the same session). The following items are optional: Node addressing: This can include a peer identity and IP address for the sending node, as well as higher layer addressing information for the negotiation of messaging association protocols. It also includes IP TTL information to allow the hop count between GIMPS peers to be measured and reported. Node-Addressing = peer-identity IP-TTL [ interface-address ] [ *higher-layer-addressing ] The peer-identity and interface-address are used for matching existing associations, as discussed in Section 4.4.2. Any technique may be used to generate it, so long as it is stable. The interface-address should be a routable address where the sending node can be reached over UDP or messaging association protocols. Where this object is used in a GIMPS-Query, it should specifically be set to the address of the interface that will be used for the outbound flow, to allow its use in route change Schulzrinne & Hancock Expires August 25, 2005 [Page 31] Internet-Draft GIMPS February 2005 handling, see Section 6.1. The purpose and structure of the higher-layer-addressing fields is described in Section 5.5. Note that the higher-layer-addressing fields are only present in datagram encapsulated messages; when this object is carried in connection mode, these information elements are neither necessary or meaningful. The setting and interpretation of the IP-TTL field depends on the message direction (as determined from the MRI) and encapsulation. * If the message is downstream, the IP-TTL is set to the TTL that will be set in the IP header for the message (if this can be determined), or else 0. * On receiving a downstream message in datagram mode, the IP-TTL is compared to the TTL in the IP header, and the result is stored as the IP-hop-count-to-peer for the upstream peer in the routing state table for that flow. Otherwise, the field is ignored. * If the message is upstream, the IP-TTL is set to the value of the IP-hop-count-to-peer stored in the routing state table, or 0 if there is no value yet stored. * On receiving an upstream message, the IP-TTL is stored as the IP-hop-count-to-peer for the downstream peer. In all cases, the TTL value reported to signaling applications is the one stored with the routing state for that flow, after it has been updated (if appropriate) from processing the message in question. Stack Proposal: This field contains information about which combinations of transport and security protocols are proposed for use in messaging associations, and is also discussed further in Section 5.5. Stack-Proposal = *stack-profile stack-profile = *protocol-layer Each protocol-layer field identifies a protocol with a unique tag; any address-related (mutable) information associated with the protocol will be carried in a higher-layer-addressing field in the Node-Addressing TLV (see above). Schulzrinne & Hancock Expires August 25, 2005 [Page 32] Internet-Draft GIMPS February 2005 Query-Cookie/Responder-Cookie: A query-cookie is contained in a GIMPS-Query message and must be echoed in a GIMPS-Response; a response-cookie is optional in a GIMPS-Response message, and if present must be echoed in the following GIMPS-Confirm message. Cookies are variable length (chosen by the cookie generator) and need to be designed so that a node can determine the validity of a cookie without keeping state. A future version of this specification will include references to techniques for generating such cookies. Routing-State-Lifetime: The lifetime of GIMPS routing state in the absence of refreshes, measured in seconds. Defaults to 30 seconds. NSLP-Data: The NSLP payload to be delivered to the signaling application. GIMPS does not interpret the payload content. 5.3 Datagram Mode Transport This section describes the various encapsulation options for datagram mode messages. Although there are several variant possibilities, depending on message type, message routing method, and local policy, the general design principle is that the sole purpose of the encapsulation is to ensure that the message is delivered to or intercepted at the correct peer. Beyond that, no significance is attached to the type of encapsulation or the values of addresses or ports used for it. This allows new options to be developed in the future to handle particular deployment requirements without modifying the overall protocol specification. 5.3.1 Normal Encapsulation Normal encapsulation is used for all datagram mode messages where the signaling peer is already known from previous signaling. This includes Response and Confirm messages, and Data messages except if these are being sent without using local routing state. Normal encapsulation is simple: the complete set of GIMPS payloads is concatenated together with the common header, and placed in the data field of a UDP datagram. UDP checksums should be enabled. The message is IP addressed directly to the adjacent peer; the UDP port numbering should be compatible with that used on Query messages (see below), that is, the same for messages in the same direction and swapped otherwise. 5.3.2 Query Encapsulation Query encapsulation is used for messages where no routing state is Schulzrinne & Hancock Expires August 25, 2005 [Page 33] Internet-Draft GIMPS February 2005 available or where the routing state is being refreshed, in particular for GIMPS-Query messages. Query encapsulation is similar to normal encapsulation, with changes in IP address selection, IP options, and a defined method for selecting UDP ports. In general, the IP addresses are derived from information in the MRI; the exact rules depend on the message routing method. In addition, the IP header is given a Router Alert Option to assist the peer in intercepting the message depending on the NSLPID. Router alert option value-field setting is discussed in Section 5.3.2.1. The source UDP port is selected by the message sender as the port at which it is prepared to receive UDP messages in reply, and a destination UDP port should be allocated by IANA. Note that GIMPS may send messages addressed as {flow sender, flow receiver} which could make their way to the flow receiver even if that receiver were GIMPS-unaware. This should be rejected (with an ICMP message) rather than delivered to the user application (which would be unable to use the source address to identify it as not being part of the normal data flow). Therefore, a "well-known" port would seem to be required. 5.3.2.1 Intermediate Node Bypass and Router Alert Values We assume that the primary mechanism for intercepting messages is the use of the RAO. The RAO contains a 16 bit value field, within which 35 values have currently been assigned by IANA. This section discusses the technical considerations to be taken into account when assigning values for use by GIMPS. The basic goal is to optimise protocol processing, i.e. to minimise the amount of slow-path processing that nodes have to carry out for messages they are not actually interested in. There are two basic reasons why a GIMPS node might wish to ignore a message: o because it is for a signaling application that the node does not process; o because even though the signaling application is present on the node, the interface on which the message arrives is only processing signaling messages at the aggregate level and not for individual flows (compare [15]). Conversely, note that a node might wish to process a number of different signaling applications, either because it was genuinely multifunctional or because it processed several versions of the same application. (Note from Appendix C.1 that different versions are distinguished by different NSLP identifiers.) Schulzrinne & Hancock Expires August 25, 2005 [Page 34] Internet-Draft GIMPS February 2005 Some or all of this information can be encoded in the RAO value field, which then allows messages to be filtered on the fast path. There is a tradeoff between two approaches here, whose evaluation depends on whether the processing node is specialised or general purpose: Fine-Grained: The signaling application (including specific version) and aggregation level are directly identified in the RAO value. A specialised node which handles only a single NSLP can efficiently ignore all other messages; a general purpose node may have to match the RAO value in a message against a long list of possible values. Coarse-Grained: IANA allocates RAO values for 'popular' applications or groups of applications (such as 'All QoS Signaling Applications'). This speeds up the processing in a general purpose node, but a specialised node may have to carry out further processing on the GIMPS common header to identify the precise messages it needs to consider. These considerations imply that the RAO value should not be tied directly to the NSLP id, but should be selected for the application on broader considerations of likely deployment scenarios. Note that the exact NSLP is given in the GIMPS common header, and some implementations may still be able to process it on the fast path. The semantics of the node dropping out of the signaling path are the same however the filtering is done (see Section 4.3.4). There is a special consideration in the case of the aggregation level. In this case, whether a message should be processed depends on the network region it is in (specifically, the link it is on). There are then two basic possibilities: 1. All routers have essentially the same algorithm for which messages they process, i.e. all messages at aggregation level 0. However, messages have their aggregation level incremented on entry to an aggregation region and decremented on exit. 2. Router interfaces are configured to process messages only above a certain aggregation level and ignore all others. The aggregation level of a message is never changed; signaling messages for end to end flows have level 0, but signaling messages for aggregates are generated with a higher level. The first technique requires aggregating/deaggregating routers to be configured with which of their interfaces lie at which aggregation level, and also requires consistent message rewriting at these boundaries. The second technique eliminates the rewriting, but Schulzrinne & Hancock Expires August 25, 2005 [Page 35] Internet-Draft GIMPS February 2005 requires interior routers to be configured also. It is not clear what the right trade-off between these options is. 5.3.2.2 Query Encapsulation for the Path-Coupled Message Routing Method For the case of the path-coupled message routing method, where the message is travelling in the same ('downstream') direction as the flow defined by the MRI, the IP addressing for Query messages is as follows: o The destination address MUST be the flow destination address as given in the MRI of the message payload. o By default, the source address is the flow source address, again from the message MRI. This provides the best likelihood that the message will be correctly routed through any region which performs per-packet policy-based forwarding or load balancing which takes the source address into account. However, there may be circumstances where the use of the signaling source address is preferable, specifically: * In order to receive ICMP error messages about the Query message (specifically, unreachable port or address). If these are delivered to the flow source rather than the signaling source, it will be very difficult for the querying node to detect that it is the last GIMPS node on the path. * In order to attempt to run GIMPS through an unmodified NAT, which will only process and translate IP addresses in the IP header. Because of these considerations, use of the signaling source address is allowed as an option, which is use based on local policy. A node SHOULD use the flow source address for initial Query messages, but MAY transition to the signaling source address for retransmissions or as a matter of static configuration (e.g. if a NAT is known to be in the path out of a certain interface). A flag in the common header tells the message receiver which option was used. It is vital that the Query message truly mimics the actual data flow, since this is the basis of how the signaling message is attached to the data path. To this end, GIMPS may set the traffic class and (for IPv6) flow label to match the values in the Flow-Identifier if this would be needed to ensure correct routing. These encapsulation rules allow Query messages to be sent in the same direction as the flow, and hence allow routing state to be set up Schulzrinne & Hancock Expires August 25, 2005 [Page 36] Internet-Draft GIMPS February 2005 from the flow source towards the flow destination. In some deployment scenarios (see Section 9.1 for further discussion), it is desirable and logically possible to set up routing state in the reverse direction. Implementing this in the specification would require defining rules for encapsulating a Query message in the upstream direction. Details are for further study. 5.3.3 Retransmission and Rate-Control Datagram mode is built on top of UDP, and hence has no automatic reliability or congestion control capabilities. Signaling applications requiring reliability should be serviced using C-mode, which should also carry the bulk of signaling traffic. However, some form of messaging reliability is required for the GIMPS control messages themselves, as is rate control to handle retransmissions and also bursts of unreliable signaling or state setup requests from the signaling applications. GIMPS-Query messages which do not receive GIMPS-responses should be retransmitted with a binary exponential backoff, with an initial timeout of T1 up to a maximum of T2 seconds. The values of T1 and T2 may be implementation defined; default values are for further study. The value of T1 may be increased on long latency links. Note that GIMPS-Queries may go unanswered either because of message loss, or because there is no reachable GIMPS peer. Therefore, implementations must trade off reliability (large T2) against promptness of error feedback to applications (small T2). GIMPS-Responses should always be sent promptly to avoid spurious retransmissions. Retransmitted GIMPS-Queries should use different Query-Cookie values and will therefore elicit different GIMPS-Responses. If either message carries NSLP data, it may be delivered multiple times to the signaling application. Other datagram mode messages are not generally retransmitted. GIMPS-Responses do not need reliability; if they are lost, the initiating Query will eventually be resent. The case of a lost GIMPS-Confirm is more subtle. Notionally, we can distinguish between two cases: o Where the Responding node is already prepared to store per-flow state after receiving a single (Query) message. This would include any cases where the node has NSLP data queued to send. Here, it is reasonable for the protocol to demand that the Responding node runs a retransmission timer to resend the Response message until a Confirm is received. The problem of an amplification attack stimulated by a malicious Query should be handled by requiring the cookie mechanism to enable the node Schulzrinne & Hancock Expires August 25, 2005 [Page 37] Internet-Draft GIMPS February 2005 receiving the Response to discard it efficiently if it does not match a previously sent Query. o where the responding node is not prepared to store per-flow state until receiving a properly formed Confirm message. The second (which is probably the more commonplace one where Confirm messages are wanted at all), a retransmission timer should not be required. However, we can assume that the next signaling message will be in the direction Querying Node -> Responding Node (if there is no 'next signaling message' the fact that the Confirm has been lost is moot). In this case, the responding node will start to receive messages at the GIMPS level for a flow/NSLP combination for which there is no stored routing state (since this state is only created on receipt of a Confirm). The consequence of this is that the error condition is detected at the Responding node when such a message arrives without the need for a specific timer. Recovery requires a Confirm to be retransmitted and successfully received. The ideal mechanism to cause this would be for the Responding node to be able to reject the incoming message with an error "No Routing State Exists" back to the Querying node, which would interpret this as caused by a lost Confirm; the Querying node needs to be able to regenerate the Confirm from local state without getting a Response (e.g. in particular it needs to remember the Responder Cookie value). The basic rate limiting requirements for datagram mode traffic are deliberately minimal. A single rate limiter applies to all traffic (for all interfaces and message types). It applies to retransmissions as well as new messages, although an implementation may choose to prioritise one over the other. When the rate limiter is imposed, datagram mode messages are queued until transmission is re-enabled, or an error condition may be indicated back to local signaling applications. The rate limiting mechanism is implementation defined, but it is recommended that a token bucket limiter as described in [8] should be used. 5.4 Connection Mode Transport Encapsulation in connection mode is more complex, because of the variation in available transport functionality. This issue is treated in Section 5.4.1. The actual encapsulation is given in Section 5.4.2. 5.4.1 Choice of Transport Protocol It is a general requirement of the NTLP defined in [20] that it Schulzrinne & Hancock Expires August 25, 2005 [Page 38] Internet-Draft GIMPS February 2005 should be able to support bundling (of small messages), fragmentation (of large messages), and message boundary delineation. Not all transport protocols natively support all these features. SCTP [6] satisfies all requirements. DCCP [7] is message based but does not provide bundling or fragmentation. Bundling can be carried out by the GIMPS layer sending multiple messages in a single datagram; because the common header includes length information (number of TLVs), the message boundaries within the datagram can be discovered during parsing. Fragmentation of GIMPS messages over multiple datagrams should be avoided, because of amplification of message loss rates that this would cause. TCP provides both bundling and fragmentation, but not message boundaries. However, the length information in the common header allows the message boundary to be discovered during parsing. The bundling together of small messages is either built into the transport protocol or can be carried out by the GIMPS layer during message construction. Either way, two approaches can be distinguished: 1. As messages arrive for transmission they are gathered into a bundle until a size limit is reached or a timeout expires (cf. the Nagle algorithm of TCP or similar optional functionality in SCTP). This provides maximal efficiency at the cost of some latency. 2. Messages awaiting transmission are gathered together while the node is not allowed to send them (e.g. because it is congestion controlled). The second type of bundling is always appropriate. For GIMPS, the first type is inappropriate for 'trigger' (i.e. state-changing) messages, but may be appropriate for refresh messages. These distinctions are known only to the signaling applications, but could be indicated (as an implementation issue) by setting the priority transfer attribute. It can be seen that all of these protocol options can be supported by the basic GIMPS message format already presented. GIMPS messages requiring fragmentation must be carried using a reliable transport protocol, TCP or SCTP. This specification defines only the use of TCP, but it can be seen that the other possibilities could be included without additional work on message formatting. Schulzrinne & Hancock Expires August 25, 2005 [Page 39] Internet-Draft GIMPS February 2005 5.4.2 Encapsulation Format The GIMPS message, consisting of common header and TLVs, is carried directly in the transport protocol (possibly incorporating transport layer security protection). Further GIMPS messages can be carried in a continuous stream (for TCP), or up to the next transport layer message boundary (for SCTP/DCCP/UDP). This situation is shown in Figure 5; it applies to both upstream and downstream messages. +---------------------------------------------+ | L2 Header | +---------------------------------------------+ | IP Header | ^ | Source address = signaling source | ^ | Destination address = signaling destination | . +---------------------------------------------+ . | L4 Header | . ^ | (Standard TCP/SCTP/DCCP/UDP header) | . ^ +---------------------------------------------+ . . | GIMPS Message | . . ^ | (Common header and TLVs as in section 5.1) | . . ^ Scope of +---------------------------------------------+ . . . security | Additional GIMPS messages, each with its | . . . protection | own common header, either as a continuous | . . . (depending | stream, or continuing to the next L4 | . . . on channel . message boundary . . . . security . . V V V mechanism . . V V V in use) Figure 5: Connection Mode Encapsulation 5.5 Messaging Association Negotiation 5.5.1 Overview A key attribute of GIMPS is that it is flexible in its ability to use existing transport and security protocols. Different transport protocols may have performance attributes appropriate to different environments; different security protocols may fit appropriately with different authentication infrastructures. Even given an initial default mandatory protocol set for GIMPS, the need to support new protocols in the future cannot be ruled out, and secure protocol negotation cannot be added to an existing protocol in a backwards-compatible way. Therefore, some sort of protocol negotiation capability is required. Protocol negotiation is carried out in GIMPS-Query/Response messages, Schulzrinne & Hancock Expires August 25, 2005 [Page 40] Internet-Draft GIMPS February 2005 using Stack-Proposal and Node-Addressing objects. If a new messaging association is required it is then set up, followed by a GIMPS-Confirm. Messaging association re-use is achieved by short-circuiting this exchange by sending the GIMPS-Response or GIMPS-Confirm messages on an existing association (Section 4.4.2); whether to do this is a matter of local policy at the querying or responding node. It is always possible for a node to restrict itself to a single messaging association between two peers. If multiple associations exist, it is a matter of local policy how to distribute messages over them, subject to respecting the transfer attributes requested. The end result of the negotiation is a messaging assocation which is a stack of protocols. Every possible protocol has the following attributes: o A Protocol-Identifier, a 1-byte IANA assigned value. o A specification of the (non-negotiable) policies about how the protocol should be used (for example, connection open direction). o Formats for carrying the protocol addressing and other configuration information in higher-layer-addressing information elements. There are different formats depending on whether the information is carried in the Query or Response (the object for a Confirm echoes the Response). A Stack-Proposal object is simply a list of profiles; each profile is a sequence of Protocol-Identifiers. Stack-Proposals are generally accompanied by Node-Addressing objects; as well as a Peer-Identity and Interface-Address, this carries a higher-layer-addressing information element for every protocol listed in the Stack-Proposal. A node generating a Node-Addressing object is committed to honouring the implied protocol configuration; in particular, it must be prepared to accept incoming datagrams or connections at the Interface-Address/protocol/port combinations advertised. However, the object contents should be retained only for the duration of the Query/Response exchange and any following association setup and afterwards discarded. (They may become invalid because of expired bindings at intermediate NATs, or because the advertising node is using agile ports.) A GIMPS-Query requesting association setup always contains a Stack-Proposal and Node-Addressing object, and unless re-use occurs, the GIMPS-Response does so also. For a GIMPS-Response, the Stack-Proposal must be invariant for the combination of outgoing interface and NSLPID (it must not depend on the GIMPS-Query). Once the messaging association is set up, the querying node repeats the Schulzrinne & Hancock Expires August 25, 2005 [Page 41] Internet-Draft GIMPS February 2005 responder's Stack-Proposal over it in the GIMPS-confirm. The resonding node can verify this to ensure that no bidding-down attack has occurred. Where the Response or Confirm is being sent in connection mode (either because of re-use or because messaging association setup has actually completed), the Node-Addressing object is sent in an abbreviated form, omitting the higher layer information fields. The Interface-Address is retained in the Confirm, to allow matching the messaging association against subsequent Query messages. 5.5.2 Protocol Definition: Forwards-TCP This defines a basic configuration for the use of TCP between peers. Support for this protocol is mandatory; associations using it can carry messages with the transfer attribute Reliable=True. The connection is opened in the forwards direction, from the querying node, towards the responder at a previously advertised port. The higher-layer-addressing formats are: o downstream: no additional data (just the Protocol-Identifier) o upstream: 2 byte port number at which the connection will be accepted. 5.5.3 Additional Protocol Options It is expected that the base GIMPS specification will define a single mandatory protocol for channel security (one of IKE/IPsec or TLS). Further protocols or configurations could be defined in the future for additional performance or flexibility. Examples are: o SCTP or DCCP as alternatives to TCP, with essentially the same configuration. o SigComp [17] for message compression. o ssh [25] or HIP/IPsec [26] for channel security. o Alternative modes of TCP operation, for example where it is set up from the responder to the querying node. Schulzrinne & Hancock Expires August 25, 2005 [Page 42] Internet-Draft GIMPS February 2005 6. Advanced Protocol Features 6.1 Route Changes and Local Repair 6.1.1 Introduction When re-routing takes place in the network, GIMPS and signaling application state needs to be updated for all flows whose paths have changed. The updates to signaling application state are usually signaling application dependent: for example, if the path characteristics have actually changed, simply moving state from the old to the new path is not sufficient. Therefore, GIMPS cannot carry out the complete path update processing. Its responsibilities are to detect the route change, update its own routing state consistently, and inform interested signaling applications at affected nodes. Route change management is complicated by the distributed nature of the problem. Consider the re-routing event shown in Figure 6. An external observer can tell that the main responsibility for controlling the updates will probably lie with nodes A and E; however, D1 is best placed to detect the event quickly at the GIMPS level, and B1 and C1 could also attempt to initiate the repair. On the assumption that NSLPs are soft-state based and operate end to end, and because GIMPS also periodically updates its picture of routing state, route changes will eventually be repaired automatically. However, especially if NSLP refresh times are extended to reduce signaling load, the duration of inconsistent state may be very long indeed. Therefore, GIMPS includes logic to deliver prompt notifications to NSLPs, to allow NSLPs to carry out local repair if possible. Schulzrinne & Hancock Expires August 25, 2005 [Page 43] Internet-Draft GIMPS February 2005 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x +--+ +--+ +--+ x Initial x .|B1|_.......|C1|_.......|D1| x Configuration x . +--+. .+--+. .+--+\. x x . . . . . . x >>xxxxxx . . . . . . xxxxxx>> +-+ . .. .. . +-+ .....|A|/ .. .. .|E|_.... +-+ . . . . . . +-+ . . . . . . . . . . . . . +--+ +--+ +--+ . .|B2|_.......|C2|_.......|D2|/ +--+ +--+ +--+ +--+ +--+ +--+ Configuration .|B1|........|C1|........|D1| after failure . +--+ .+--+ +--+ of D1-E link . \. . \. ./ . . . . . +-+ . .. .. +-+ .....|A|. .. .. .|E|_.... +-+\. . . . . . +-+ >>xxxxxx . . . . . . xxxxxx>> x . . . . . . x x . +--+ +--+ +--+ . x x .|B2|_.......|C2|_.......|D2|/ x x +--+ +--+ +--+ x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ........... = physical link topology >>xxxxxxx>> = flow direction _.......... = indicates outgoing link for flow xxxxxx given by local forwarding table Figure 6: A Re-Routing Event 6.1.2 Route Change Detection There are two aspects to detecting a route change at a single node: o Detecting that the path in the direction of the Query has (or may have) changed. Schulzrinne & Hancock Expires August 25, 2005 [Page 44] Internet-Draft GIMPS February 2005 o Detecting that the path in the direction of the Response has (or may have) changed (in which case the node may no longer be on the path at all). At a single node, these processes are largely independent, although clearly a change in the path in one direction at a node corresponds to a change in path in the opposite direction at its peer. Note that there are two possible aspects of route change: Interface: The interface through which a flow leaves or enters a node may change. Peer: The adjacent peer may change. In general, a route change could include one or the other or both. (In theory it could include neither, although such changes are hard to detect and even harder to do anything useful about.) There are five mechanisms for a GIMPS node to detect that a route change has occurred, which are listed below. They apply differently depending on whether the change is in the Query or Response direction, and these differences are summarised in the following table. Local Trigger: In trigger mode, a node finds out that the next hop has changed. This is the RSVP trigger mechanism where some form of notification mechanism from the routing table to the protocol handler is assumed. Clearly this only works if the routing change is local, not if the routing change happens somewhere a few routing hops away (including the case that the change happens at a GIMPS-unaware node). Extended Trigger: An extended trigger, where the node checks a link-state routing table to discover that the path has changed. This makes certain assumptions on consistency of route computation (but you probably need to make those to avoid routing loops) and only works within a single area for OSPF and similar link-state protocols. Where available, this offers the most accurate and expeditious indication of route changes, but requires more access to the routing internals than a typical OS may provide. GIMPS C-mode Monitoring: A node may find that C-mode packets are arriving (from either peer) with a different TTL or on a different interface. This provides no direct information about the new flow path, but indicates that routing has changed and that rediscovery may be required. Schulzrinne & Hancock Expires August 25, 2005 [Page 45] Internet-Draft GIMPS February 2005 Data Plane Monitoring: The signaling application on a node may detect a change in behaviour of the flow, such as TTL change, arrival on a different interface, or loss of the flow altogether. The signaling application on the node is allowed to notify this information locally to GIMPS. GIMPS Probing: In probing mode, each GIMPS node periodically repeats the discovery (GIMPS-Query/GIMPS-Response) operation. The querying node will discover the route change by a modification in the Node-Addressing information in the GIMPS-Response. This is similar to RSVP behavior, except that there is an extra degree of freedom since not every message needs to repeat the discovery, depending on the likely stability of routes. All indications are that, leaving mobility aside, routes are stable for hours and days, so this may not be necessary on a 30-second interval, especially if the other techniques listed above are available. When these methods discover a route change in the Response direction, this cannot be handled directly by GIMPS at the detecting node, since route discovery proceeds only in the Query direction. Therefore, to exploit these mechanisms, it must be possible for GIMPS to send a notification message to initiate this. (This would be possible for example by setting an additional flag in the Common-Header of a message.) +----------------------+----------------------+---------------------+ | Method | Query direction | Response direction | +----------------------+----------------------+---------------------+ | Local Trigger | Discovers new | Not applicable | | | interface (and peer | | | | if local) | | | | | | | Extended Trigger | Discovers new | May determine that | | | interface and may | route from peer | | | determine new peer | will have changed | | | | | | C-Mode Monitoring | Provides hint that | Provides hint that | | | change has occurred | change has occurred | | | | | | Data Plane | Not applicable | NSLP informs GIMPS | | Monitoring | | that a change may | | | | have occurred | | | | | | Probing | Discovers changed | Discovers changed | | | Node-Addressing in | Node-Addressing in | | | GIMPS-Response | GIMPS-Query | +----------------------+----------------------+---------------------+ Schulzrinne & Hancock Expires August 25, 2005 [Page 46] Internet-Draft GIMPS February 2005 6.1.3 Local Repair Once a node has detected that a change may have occurred, there are three possible cases: 1. Only a change in the Response direction is indicated. There is nothing that can be done locally; GIMPS must propagate a notification to its peer. 2. A Query direction change has been detected and a Response direction change cannot be ruled out. Although some local repair may be appropriate, it is difficult to decide what, since the path change may actually have taken place remotely from the detecting node (so that this node is no longer on the path at all). 3. A Query direction change has been detected, but there is no change in the Responding direction. In this case, the detecting node is the true crossover router, i.e. the point in the network where old and new paths diverge. It is the correct node to initiate the local repair process. In case (3), i.e. at the crossover node, the local repair process is initiated by the GIMPS level as follows: o GIMPS marks its routing state information for this flow as 'invalid', unless the route change was actually detected by D-mode probing (in which case the new state has already been installed). o GIMPS notifies the local NSLP that local repair is necessary. It is assumed that the second step will typically trigger the NSLP to generate a message, and the attempt to send it will stimulate a GIMPS-Query/Response. This signaling application message will propagate, also discovering the new route, until it rejoins the old path; the node where this happens may also have to carry out local repair actions. A problem is that there is usually no robust technique to distinguish case (2) from case (3), because of the relative weakness of the techniques in determining that such changes have not occurred. (They can be effective in determining that a change has occurred; however, even where they can tell that the route from the peer has not changed, they cannot rule out a change beyond that peer.) There is therefore a danger that multiple nodes within the network would attempt to carry out local repair in parallel. One possible technique to address this problem is that a GIMPS node Schulzrinne & Hancock Expires August 25, 2005 [Page 47] Internet-Draft GIMPS February 2005 that detects case (3) locally, rather than initiating local repair immediately, still sends a route change notification, just in case (2) actually applies. If the peer locally detects no downstream route change, it can signal this in the Query direction (e.g. by setting another flag in the Common-Header of a GIMPS message). This acts to damp the possibility of a 'local repair storm', at the cost of an additional peer-peer round trip time. 6.1.4 Local Signaling Application State Removal After a route change, a signaling application may wish to remove state at another node which is no longer on the path. However, since it is no longer on the path, in principle GIMPS can no longer send messages to it. (In general, provided this state is soft, it will time out anyway; however, the timeouts involved may have been set to be very long to reduce signaling load.) The requirement to remove state in a specific peer node is identified in [23]. This requirement can be met provided that GIMPS is able to 'remember' the old path to the signaling application peer for the period while the NSLP wishes to be able to use it. Since NSLP peers are a single GIMPS hop apart, the necessary information is just the old entry in the node's routing state table for that flow. Rather than requiring the GIMPS level to maintain multiple generations of this information, it can just be provided to the signaling application in the same node (in an opaque form), which can store it if necessary and provide it back to the GIMPS layer in case it needs to be used. This information is denoted as 'SII-Handle' in the abstract API of Appendix D; however, the details are an implementation issue which do not affect the rest of the protocol. 6.1.5 Operation with Heterogeneous NSLPs A potential problem with route change detection is that the detecting GIMPS node may not implement all the signaling applications that need to be informed. Therefore, it would need to be able to send a notification back along the unchanged path to trigger the nearest signaling application aware node to take action. If multiple signaling applications are in use, it would be hard to define when to stop propagating this notification. However, given the rules on message interception and routing state maintenance in Section 4.3, Section 4.4 and Section 5.3.2.1, this situation cannot arise: all NSLP peers are exactly one GIMPS hop apart. The converse problem is that the ability of GIMPS to detect route changes by purely local monitoring of forwarding tables is more limited. (This is probably an appropriate limitation of GIMPS functionality. If we need a protocol for distributing notifications Schulzrinne & Hancock Expires August 25, 2005 [Page 48] Internet-Draft GIMPS February 2005 about local changes in forwarding table state, a flow signaling protocol is probably not the right starting point.) 6.2 Policy-Based Forwarding and Flow Wildcarding Signaling messages almost by definition need to contain address and port information to identify the flow they are signaling for. We can divide this information into two categories: Message-Routing-Information: This is the information needed to determine how a message is routed within the network. It may include a number of flow N-tuple parameters, and is carried as an object in each GIMPS message (see Section 5.1). Additional Packet Classification Information: This is any further higher layer information needed to select a subset of packets for special treatment by the signaling application. The need for this is highly signaling application specific, and so this information is invisible to GIMPS (if indeed it exists); it will be carried only in the corresponding NSLP. The correct pinning of signaling messages to the data path depends on how well the downstream messages in datagram mode can be made to be routed correctly. Two strategies are used: The messages themselves match the flow in destination address and possibly other fields (see Section 5.3 and Section 5.3.2 for further discussion). In many cases, this will cause the messages to be routed correctly even by GIMPS-unaware nodes. A GIMPS-aware node carrying out policy based forwarding on higher layer identifiers (in particular, the protocol and port numbers for IPv4) should take into account the entire Message-Routing-Information object in selecting the outgoing interface rather than relying on the IP layer. The current Message-Routing-Information format allows a limited degree of 'wildcarding', for example by applying a prefix length to the source or destination address, or by leaving certain fields unspecified. A GIMPS-aware node must verify that all flows matching the Message-Routing-Information would be routed identically in the downstream direction, or else reject the message with an error. 6.3 NAT Traversal As already noted, GIMPS messages must carry packet addressing and higher layer information as payload data in order to define the flow signalled for. (This applies to all GIMPS messages, regardless of Schulzrinne & Hancock Expires August 25, 2005 [Page 49] Internet-Draft GIMPS February 2005 how they are encapsulated or which direction they are travelling in.) At an addressing boundary the data flow packets will have their headers translated; if the signaling payloads are not likewise translated, the signaling messages will refer to incorrect (and probably meaningless) flows after passing through the boundary. In addition, some GIMPS messages (those used in the discovery process) carry addressing information about the GIMPS nodes themselves, and this must also be processed appropriately when traversing a NAT. The simplest solution to this problem is to require that a NAT is GIMPS-aware, and to allow it to modify datagram mode messages based on the contents of the Message-Routing-Information payload. (This is making the implicit assumption that NATs only rewrite the header fields included in this payload, and not higher layer identifiers.) Provided this is done consistently with the data flow header translation, signaling messages will be valid each side of the boundary, without requiring the NAT to be signaling application aware. An outline of the set of operations necessary on a downstream datagram mode message is as follows: 1. Verify that bindings for the data flow are actually in place. 2. Create bindings for subsequent C-mode signaling (based on the information in the Node-Addressing field). 3. Create a new Message-Routing-Information payload with fields modified according to the data flow bindings. 4. Create a new Node-Addressing payload with fields to force upstream D-mode messages through the NAT, and to allow C-mode exchanges using the C-mode signaling bindings. 5. Add a new NAT-Traversal payload, listing the objects which have been modified and including the unmodified Message-Routing-Information. 6. Forward the message with these new payloads. The original Message-Routing-Information payload is retained in the message, but encapsulated in the new TLV type. Further information can be added corresponding to the Node-Addressing payload, either the original payload itself or, in the case of a GIMPS node that wished to do topology hiding, opaque tokens (or it could be omitted altogether). In the case of a sequence of NATs, this part of the NAT-Traversal object would become a list. Note that a consequence of this approach is that the routing state tables at the actual signaling application peers (either side of the NAT) are no longer directly compatible. In particular, the values of Schulzrinne & Hancock Expires August 25, 2005 [Page 50] Internet-Draft GIMPS February 2005 Message-Routing-Information are different, which is why the unmodified MRI is propagated in the NAT-Traversal payload to allow subsequent C-mode messages to be interpreted correctly.. The case of traversing a GIMPS-unaware NAT is for further study. There is a dual problem of whether the GIMPS peers either side of the boundary can work out how to address each other, and whether they can work out what translation to apply to the Message-Routing-Information from what is done to the signaling packet headers. The fundamental problem is that GIMPS messages contain 3 or 4 interdependent addresses which all have to be consistently translated, and existing generic NAT traversal techniques such as STUN [19] can process only two. 6.4 Interaction with IP Tunnelling The interaction between GIMPS and IP tunnelling is very simple. An IP packet carrying a GIMPS message is treated exactly the same as any other packet with the same source and destination addresses: in other words, it is given the tunnel encapsulation and forwarded with the other data packets. Tunnelled packets will not be identifiable as GIMPS messages until they leave the tunnel, since any router alert option and the standard GIMPS protocol encapsulation (e.g. port numbers) will be hidden behind the standard tunnel header. If signaling is needed for the tunnel itself, this has to be initiated as a separate signa