Next Steps in Signaling H. Schulzrinne
Internet-Draft Columbia U.
Expires: January 19, 2006 R. Hancock
Siemens/RMR
July 18, 2005
GIMPS: General Internet Messaging Protocol for Signaling
draft-ietf-nsis-ntlp-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 19, 2006.
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
service for diverse signaling applications. GIMPS does not handle
signaling application state itself, but manages its own internal
Schulzrinne & Hancock Expires January 19, 2006 [Page 1]
Internet-Draft GIMPS July 2005
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 Modes and Messaging Associations . . . . . . . . . . . . . 9
3.3 Message Routing Methods . . . . . . . . . . . . . . . . . 11
3.4 Signalling Sessions . . . . . . . . . . . . . . . . . . . 12
3.5 Example of Operation . . . . . . . . . . . . . . . . . . . 13
4. GIMPS Processing Overview . . . . . . . . . . . . . . . . . 16
4.1 GIMPS Service Interface . . . . . . . . . . . . . . . . . 16
4.2 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Basic Message Processing . . . . . . . . . . . . . . . . . 19
4.4 Routing State and Messaging Association Maintenance . . . 24
5. Message Formats and Transport . . . . . . . . . . . . . . . 31
5.1 GIMPS Messages . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Information Elements . . . . . . . . . . . . . . . . . . . 33
5.3 Datagram Mode Transport . . . . . . . . . . . . . . . . . 36
5.4 Connection Mode Transport . . . . . . . . . . . . . . . . 39
5.5 Message Type/Encapsulation Relationships . . . . . . . . . 41
5.6 Error Message Processing . . . . . . . . . . . . . . . . . 42
5.7 Messaging Association Negotiation . . . . . . . . . . . . 43
5.8 Specific Message Routing Methods . . . . . . . . . . . . . 45
6. Formal Protocol Specification . . . . . . . . . . . . . . . 50
6.1 Node Processing . . . . . . . . . . . . . . . . . . . . . 51
6.2 Query Node Processing . . . . . . . . . . . . . . . . . . 53
6.3 Responder Node Processing . . . . . . . . . . . . . . . . 59
6.4 Messaging Association Processing . . . . . . . . . . . . . 65
7. Advanced Protocol Features . . . . . . . . . . . . . . . . . 72
7.1 Route Changes and Local Repair . . . . . . . . . . . . . . 72
7.2 Policy-Based Forwarding and Flow Wildcarding . . . . . . . 78
7.3 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 78
7.4 Interaction with IP Tunnelling . . . . . . . . . . . . . . 80
7.5 IPv4-IPv6 Transition and Interworking . . . . . . . . . . 81
8. Security Considerations . . . . . . . . . . . . . . . . . . 83
8.1 Message Confidentiality and Integrity . . . . . . . . . . 83
8.2 Peer Node Authentication . . . . . . . . . . . . . . . . . 84
8.3 Routing State Integrity . . . . . . . . . . . . . . . . . 84
8.4 Denial of Service Prevention . . . . . . . . . . . . . . . 86
8.5 Summary of Requirements on Cookie Mechanisms . . . . . . . 87
Schulzrinne & Hancock Expires January 19, 2006 [Page 2]
Internet-Draft GIMPS July 2005
8.6 Residual Threats . . . . . . . . . . . . . . . . . . . . . 88
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90
10. Change History . . . . . . . . . . . . . . . . . . . . . . . 92
10.1 Changes In Version -07 . . . . . . . . . . . . . . . . . 92
10.2 Changes In Version -06 . . . . . . . . . . . . . . . . . 92
10.3 Changes In Version -05 . . . . . . . . . . . . . . . . . 94
10.4 Changes In Version -04 . . . . . . . . . . . . . . . . . 95
10.5 Changes In Version -03 . . . . . . . . . . . . . . . . . 96
10.6 Changes In Version -02 . . . . . . . . . . . . . . . . . 97
10.7 Changes In Version -01 . . . . . . . . . . . . . . . . . 98
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 101
11.1 Normative References . . . . . . . . . . . . . . . . . . 101
11.2 Informative References . . . . . . . . . . . . . . . . . 101
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 103
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
B. Example Message Routing State Table . . . . . . . . . . . . 106
C. Bit-Level Formats and Error Messages . . . . . . . . . . . . 107
C.1 General GIMPS Formatting Guidelines . . . . . . . . . . . 107
C.2 The GIMPS Common Header . . . . . . . . . . . . . . . . . 107
C.3 General Object Characteristics . . . . . . . . . . . . . . 108
C.4 GIMPS TLV Objects . . . . . . . . . . . . . . . . . . . . 109
C.5 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D. API between GIMPS and NSLP . . . . . . . . . . . . . . . . . 124
D.1 API Concepts . . . . . . . . . . . . . . . . . . . . . . . 124
D.2 SendMessage . . . . . . . . . . . . . . . . . . . . . . . 124
D.3 RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 126
D.4 MessageStatus . . . . . . . . . . . . . . . . . . . . . . 127
D.5 NetworkNotification . . . . . . . . . . . . . . . . . . . 128
D.6 SetStateLifetime . . . . . . . . . . . . . . . . . . . . . 128
D.7 InvalidateRoutingState . . . . . . . . . . . . . . . . . . 128
Intellectual Property and Copyright Statements . . . . . . . 130
Schulzrinne & Hancock Expires January 19, 2006 [Page 3]
Internet-Draft GIMPS July 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 on "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 node 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 protocol support are common to all or a large
number of signaling applications, and hence can be developed as a
common protocol. The NSIS framework given in [24] 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). GIMPS does not handle signaling application state
itself; in that crucial respect, it differs from application
signaling protocols such as SIP, RTSP, and the control component of
FTP. 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 January 19, 2006 [Page 4]
Internet-Draft GIMPS July 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 NSIS
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 implementations could 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 January 19, 2006 [Page 5]
Internet-Draft GIMPS July 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 state information is to be manipulated or monitored. See
Section 3.4 for further detailed discussion.
[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).
[Flow] Receiver: The node in the network which is the sink for the
packets in a flow.
Schulzrinne & Hancock Expires January 19, 2006 [Page 6]
Internet-Draft GIMPS July 2005
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 node along the data path, in the upstream
or downstream direction, with which a GIMPS node explicitly
interacts. The GIMPS peer discovery mechanisms implicitly
determine whether two nodes will be adjacent. It is possible for
adjacencies to 'skip over' intermediate nodes which decide not to
take part in the signaling exchange at the NTLP layer; even if
such nodes process parts of the signaling messages, they store no
state about the session and are never explicitly visible at the
GIMPS level to the nodes either side.
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.
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 algorithms 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 Section 3.3.
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 January 19, 2006 [Page 7]
Internet-Draft GIMPS July 2005
3. Design Overview
3.1 Overall Design Approach
The generic requirements identified in the NSIS framework [24] 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 addressing and identity information about
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, during which signalling application data can
also be exchanged; 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 as used for a
Query message.
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. It handles the easy cases internally, and uses well-
understood 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
security protection or guaranteed delivery.
In [24] 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 8]
Internet-Draft GIMPS July 2005
^^ +-------------+
|| | 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
3.2 Modes and Messaging Associations
Internally, GIMPS has two modes of operation:
Datagram mode ('D 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 9]
Internet-Draft GIMPS July 2005
Connection mode ('C 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.
Datagram mode uses UDP, as this is the only encapsulation which does
not require per-message shared state to be maintained 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). 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. Also, signaling messages are only ever
delivered between peers established in GIMPS-Query/Response
exchanges.
It is possible to mix these two modes along a path. 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 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 D/C 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 10]
Internet-Draft GIMPS July 2005
3.3 Message Routing Methods
The baseline message routing functionality in GIMPS is that
signalling messages follow a route defined by an existing flow in the
network, visiting a subset of the nodes through which it passes.
This is the appropriate behaviour for application scenarios where the
purpose of the signalling is to manipulate resources for that flow.
However, there are scenarios for which other behaviours are
applicable. Two examples are:
Predictive Routing: Here, the intent is to send signaling along a
path that the data flow may or will follow in the future.
Possible cases are pre-installation of state on the backup path
that would be used in the event of a link failure; and predictive
installation of state on the path that will be used after a mobile
node handover.
NAT Address Reservations: This applies to the case where a node
behind a NAT wishes to use NSIS signaling to reserve an address
from which it can be reached by a sender on the other side. This
requires a message to be sent outbound from what will be the flow
receiver although no reverse routing state exists.
Most of the details of GIMPS operation are independent of which
alternative is being used. Therefore, the GIMPS design encapsulates
the routing-dependent details as a message routing method (MRM), and
allows multiple MRMs to be defined. The default is the path-coupled
MRM, which corresponds to the baseline functionality described above;
a second MRM for the NAT Address Reservation case is also defined.
The content of a MRM definition is as follows, using the path-coupled
MRM as an example:
o The format of the information that describes the path that the
signalling should take, the Message Routing Information (MRI).
For the path-coupled MRM, this is just the Flow Identifier (see
Section 5.8.1.1). The MRI always includes an element to
distinguish between the two directions that signalling messages
can take, denoted 'upstream' and 'downstream'.
o A specification of the IP level encapsulation of the messages that
probe the network to discover the adjacent peers. A downstream
encapsulation must be defined; an upstream encapsulation is
optional. For the path-coupled MRM, this information is given in
Section 5.8.1.2 and Section 5.8.1.3.
o A specification of what validation checks GIMPS should apply to
the probe messages, for example to protect against IP address
Schulzrinne & Hancock Expires January 19, 2006 [Page 11]
Internet-Draft GIMPS July 2005
spoofing attacks. The checks may be dependent on the direction
(upstream/downstream) of the message. For the path-coupled MRM,
the downstream validity check is basically a form of ingress
filtering, also discussed in Section 5.8.1.2.
o The mechanism(s) available for route change detection, i.e. any
change in the neighbour relationships that the MRM discovers. The
default case for any MRM is soft-state refresh, but additional
supporting techniques may be possible; see Section 7.1.2.
In addition, it should be noted that NAT traversal almost certainly
requires transformation of the MRI field in GIMPS messages (see
Section 7.3). Although the transformation does not have to be
defined as part of the standard, the impact on existing GIMPS NAT
implementations should be considered.
3.4 Signalling Sessions
GIMPS allows signalling applications to associate each message with a
"signalling session". Informally, given an application layer
exchange of information for which some network control state
information is to be manipulated or monitored, the corresponding
signalling messages should be associated with the same session.
Signalling applications provide the session identifier (SID) whenever
they wish to send a message, and GIMPS reports the SID when a message
is received.
Most GIMPS processing and state information is related to the flow
(defined by the MRI, see above) and NSLPID. There are several
possible relationships between flows and sessions, for example:
o The simplest case is that all messages for the same flow have the
same SID.
o Messages for more than one flow may use the same SID, for example
because one flow is replacing another in a mobility or multihoming
scenario.
o A single flow may have messages for different SIDs, for example
from independently operating signalling applications.
Because of this range of options, GIMPS does not perform any
validation on how signalling applications map between flows and
sessions, nor does it perform any validation on the properties of the
SID itself. In particular, when a new SID is needed, logically it
should be generated by the NSLP. (NSIS implementations could provide
common functionality to generate SIDs for use by any NSLP, but this
is not part of GIMPS.) GIMPS only defines the syntax of the SID as
Schulzrinne & Hancock Expires January 19, 2006 [Page 12]
Internet-Draft GIMPS July 2005
an opaque 128-bit number.
The SID assignment has the following impact on GIMPS processing:
o Messages with the same SID to be delivered reliably between the
same GIMPS peers are delivered in order.
o All other messagse are handled independently.
o GIMPS identifies routing state (upstream and downstream peer) by
the triplet (MRI, NSLPID, SID).
Strictly, the routing state should not depend on the SID. However,
if the routing state is keyed only by (MRI, NSLPID) there is a
trivial denial of service attack (see Section 8.3) where a malicious
off-path node asserts that it is the peer for a particular flow.
Instead, the routing state is also segregated between different SIDs,
which means that the attacking node can only disrupt a signalling
session if it can guess the corresponding SID. A consequence of this
design is that signalling applications should choose SIDs so that
they are cryptographically random, and should not use several SIDs
for the same flow unless strictly necessary, to avoid additional load
from routing state maintenance.
3.5 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 single unicast flow. 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 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
Schulzrinne & Hancock Expires January 19, 2006 [Page 13]
Internet-Draft GIMPS July 2005
transfer attributes {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; see Appendix D.1 for some
additional discussion.
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. The signaling application in GN2 indicates to
GIMPS that it will peer with GN1 and so GIMPS should proceed to
set up any routing state. In addition, the signaling application
continues to process the 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 now knows that it should
maintain routing state and a messaging association for future
signalling with GN1. This is recognised because the message is a
GIMPS-Query, and because the local signaling application has
indicated that it will peer with GN1. There are two basic
possible cases for sending back the necessary GIMPS-Response:
A. GN1 and GN2 already have an appropriate messaging
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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 14]
Internet-Draft GIMPS July 2005
B. No messaging association exists. GN2 sends the GIMPS-
Response in D mode directly to GN1, identifying itself and
agreeing to the association setup. The protocol exchanges
needed to complete this will proceed in the background.
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 {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 7.1 for more
details).
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. The authoritative details are
contained in the remainder of this document.
Schulzrinne & Hancock Expires January 19, 2006 [Page 15]
Internet-Draft GIMPS July 2005
4. GIMPS Processing Overview
This section defines the basic structure and operation of GIMPS.
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 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 and messaging associations
are created and managed.
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 description 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. At the service
interface, the signalling application payload (which is opaque to
GIMPS) is accompanied by control information expressing the
application's requirements about how the message should be routed,
and the application also provides the session identifier (see
Section 3.4). 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
is not directly visible at the service interface; GIMPS will take
Schulzrinne & Hancock Expires January 19, 2006 [Page 16]
Internet-Draft GIMPS July 2005
whatever action is necessary based on the properties of the messages
and local node state.
4.1.2 Message Transfer Attributes
Message transfer attributes are used to define certain performance
and security 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). This attribute can also be used to convey information about
any address validation carried out by GIMPS (for example, whether
a return routability check has been carried out). Further details
are discussed in Appendix D.
Local Processing: An NSLP may provide hints to GIMPS to enable more
efficient or appropriate processing. For example, 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.
4.2 GIMPS State
Schulzrinne & Hancock Expires January 19, 2006 [Page 17]
Internet-Draft GIMPS July 2005
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, the direction in which to send the message,
and any associated addressing information; see Section 3.3.
Session Identification (SID): The signalling session with which this
message should be associated; see Section 3.4.
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).
The information for a given key consists of two items: the routing
state to reach the upstream and the downstream peer, with respect to
the MRI in each case. The routing state includes information about
the peer identity (see Section 4.4.2), and a UDP port number (for
datagram mode) or a reference to one or more messaging associations
(for connection mode). All of this information is learned from prior
GIMPS exchanges.
It is also possible for the state information for either direction to
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 is the endpoint of the signalling path (for example,
because it is acting as a proxy, or because it has determined
explicitly that there are no further signalling nodes in that
direction).
o The node can use other techniques to route the message. For
example, it can encapsulate it the same way as a Query message and
rely on the peer to intercept it.
Schulzrinne & Hancock Expires January 19, 2006 [Page 18]
Internet-Draft GIMPS July 2005
Each item of routing state has an associated validity timer for how
long it can be considered accurate; when this timer expires, it is
purged if it has not been refreshed. Installation and maintenance of
routing state is described in more detail in Section 4.4.
Note also that the routing state is described as a table of flows,
but that there is no implied constraint on how the information is
stored. 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 state has to be stored, just as for RSVP [11].
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
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 a timer for how long since the peer re-stated its desire to keep
the association open (see Section 4.4.3).
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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 19]
Internet-Draft GIMPS July 2005
+---------------------------------------------------------+
| >> 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
4.3.1 Message Reception
Messages can be received in connection or datagram mode, and in the
latter case with two types of message encapsulation.
Schulzrinne & Hancock Expires January 19, 2006 [Page 20]
Internet-Draft GIMPS July 2005
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.1),
the routing state table is checked to ensure that this messaging
association is associated with the MRI/NSLPID/SID combination given
in the message, or else a "Incorrectly Delivered Message" error
message Appendix C.5.4.5 is returned.
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 previously.
Each datagram contains a single complete message which is passed to
the GIMPS layer for further processing, just as in the connection
mode case.
Where GIMPS is sending messages to be intercepted by the appropriate
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 at all
is considered below in Section 4.3.4; otherwise, it is again passed
up to the GIMPS layer for further processing.
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 message type and payloads carried; most of the GIMPS-
internal payloads are associated with state maintenance and are
covered in Section 4.4. There is also a hop count to prevent message
looping, see Section 4.3.4.
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.
Even when a message relates to a local signaling application, an
adjacency may or may not be required based on signaling application
policy, and the application of this policy may depend on the NSLP
payload. Therefore, when this decision has to be made, the NSLP
payload is delivered and the signaling application has two options:
o to proceed setting up the adjacency. The application may provide
an NSLP payload (which will be used in any GIMPS-Response).
Schulzrinne & Hancock Expires January 19, 2006 [Page 21]
Internet-Draft GIMPS July 2005
o to bypass the message and drop out of the signaling path. The
application may provide an NSLP payload (which will be used in the
message which is then forwarded in the same direction by GIMPS).
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. (However, note that special rules apply to the
transmission of error messages generated by GIMPS. These are given
in Section 5.6.)
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;
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 routing state table, and
further output processing is carried out according to the details of
the protocol stacks used. 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 local NSLP.
If a messaging association is not required, the message is sent in
datagram mode. The processing in this case depends on the message
Schulzrinne & Hancock Expires January 19, 2006 [Page 22]
Internet-Draft GIMPS July 2005
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 the address from the routing
state table.
o If the message is a Query, then it is UDP encapsulated with IP
address and router alert option determined from the MRI and NSLPID
(further details depend on the message routing method).
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 NSLP.
4.3.4 Bypass Forwarding
A 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
for more details):
1. A datagram mode message contains an RAO value which is relevant
to NSIS but not to 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.
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. While
future versions might find a use for such a feature, currently
this causes an "Incorrectly Delivered Message" error message
(Appendix C.5.4.5) from the GIMPS peer.)
Schulzrinne & Hancock Expires January 19, 2006 [Page 23]
Internet-Draft GIMPS July 2005
+-------------+-------------+-------------------+-------------------+
| 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; reject |
| directly | | | with error |
| addressed | | | |
| | | | |
| Yes, or | Yes | Message is | N/A (ignored) |
| message | | locally delivered | |
| directly | | | |
| addressed | | | |
+-------------+-------------+-------------------+-------------------+
In all cases, the role of GIMPS is to forward the message
essentially unchanged, and it will not become a peer to the node
sending the message. 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 table above.
4.4 Routing State and Messaging Association Maintenance
The main responsibility of GIMPS is to manage the routing state and
messaging associations which are used in the basic message processing
described above. Routing state is installed and maintained by
specific GIMPS messages. 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
Schulzrinne & Hancock Expires January 19, 2006 [Page 24]
Internet-Draft GIMPS July 2005
2. Where an existing association can be re-used, including the case
where routing state for the flow is being refreshed.
These cases are now considered in turn, followed by the case of
background 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 message 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 25]
Internet-Draft GIMPS July 2005
+----------+ +----------+
| Querying | |Responding|
| Node | | Node |
+----------+ +----------+
GIMPS-Query
----------------------> .............
Router Alert Option . Routing .
MRI/SID/NSLPID . state .
Q-Node Network Layer Info . installed .
Query Cookie . at .
[Q-Node Stack-Proposal . R-node(1) .
Q-Node Stack-Config Data] .............
[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 Network Layer Info (D Mode only)
. installed . Query cookie
. at . [R-Node Stack-Proposal
. Q-Node . R-Node Stack-Config Data]
............. [Responder Cookie]
[NSLP Payload]
....................................
. If a messaging association needs .
. to be created, it is set up here .
....................................
GIMPS-Confirm
---------------------->
MRI/SID/NSLPID .............
Q-Node Network Layer Info . Routing .
Responder Cookie . state .
[R-Node Stack-Proposal] . installed .
[NSLP Payload] . at .
. R-node(2) .
.............
Figure 4: Message Sequence at State Setup
Schulzrinne & Hancock Expires January 19, 2006 [Page 26]
Internet-Draft GIMPS July 2005
Reception of a GIMPS-Query triggers the generation of a GIMPS-
Response message. This is a 'normally' encapsulated datagram mode
message with additional payloads. It contains network layer
information about the responding node, 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 messaging association protocol stacks. Even if a
messaging association is not requested, the Response may still
include a Responder Cookie if the node's routing state setup policy
requires it (see below).
Setup of a new messaging association begins when peer addressing
information is available 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). The negotiation of what
protocols to use for the messaging association is controlled by the
Stack-Proposal and Stack-Configuration-Data information exchanged,
and the processing of these objects is described in more detail in
Section 5.7. With the protocol options currently defined, setup of
the messaging association always starts from the Querying node,
although more flexible configurations are possible within the overall
GIMPS design. In any case, once set up 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 former is used to allow the receiver to validate the
contents of the message (see Section 8.5), and the latter is to
prevent certain bidding-down attacks on messaging association
security. The association can be used in the upstream direction for
that flow and NSLPID after the Confirm has been received.
The querying node installs the responder address as routing 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 precise constraints on when state information is installed are a
matter of security policy considerations on prevention of denial-of-
service attacks and state poisoning attacks, which are discussed
Schulzrinne & Hancock Expires January 19, 2006 [Page 27]
Internet-Draft GIMPS July 2005
further in Section 8. Because the responding node may choose to
delay state installation as in case (2), the GIMPS-Confirm must
contain sufficient information to allow it to be processed
identically to the original Query. This places some special
requirements on NAT traversal and cookie functionality, which are
discussed in Section 7.3 and Section 8 respectively.
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 only like the number of
peers, and to avoid the latency of new association setup where
possible.
However, 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
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 (and so with different addresses).
Association re-use is controlled by the Network-Layer-Information
(NLI) object, which is carried in GIMPS-Query/Confirm and optionally
GIMPS-Response messages. The NLI object 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.7.
By default, a messaging association is associated with the NLI object
that was provided by the peer in the Query/Response/Confirm at the
time the association was set up. There may be more than one
association for a given NLI object (e.g. with different properties).
Association re-use is controlled by matching the NLI provided in a
Schulzrinne & Hancock Expires January 19, 2006 [Page 28]
Internet-Draft GIMPS July 2005
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 NLI 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
remaining messages in the handshake over that association. This
will only fail (i.e. lead to re-use of an association 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 possibilities:
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
behind a NAT, or an attacker attempting to hijack the Peer-
Identity. These should be rare events, so the expense of a
new association setup is acceptable. If the authenticated
peer identities match after association setup, the two
Interface-Addresses may be bound to the association.
3. Only the Interface-Address matches: this is probably a new
peer behind the same NAT as an existing one. A new
association setup is required.
4. The full NLI object 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 (for example to
create an association with different transport or security
properties).
4.4.3 State Maintenance Procedures
Refresh and expiration of all types of state is controlled by timers.
Each item of routing state expires after a validity lifetime which is
negotiated during the Query/Response/Confirm handshake. The NLI
object in the Query contains a proposal for the lifetime value, and
the NLI in the Response contains the value the Responding node
requires. 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; otherwise, the Responding node may delete
Schulzrinne & Hancock Expires January 19, 2006 [Page 29]
Internet-Draft GIMPS July 2005
the state. 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.
There is no mechanism at the GIMPS level for explicit teardown of
routing state.
Unneeded messaging associations can be torn down by GIMPS, using the
teardown mechanisms of the underlying transport or security protocols
if available (for example, simply by closing a TCP connection). The
teardown can be initiated by either end. Whether an association is
needed is a combination of two factors:
o local policy, 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
is routing state still in place which might generate messages to
use it).
o whether the peer still wants the association in place. During
messaging association setup, each node indicates its own MA-hold-
time as part of the Stack-Configuration-Data; the node promises
not to tear down the association if it has received traffic from
its peer over that period. A peer which has generated no traffic
but still wants the association retained can use a special 'null'
message (GIMPS-MA-Hello) to indicate the fact.
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 described 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 January 19, 2006 [Page 30]
Internet-Draft GIMPS July 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: The main messages are either one of the stages in the
3-way handshake, or a simple message carrying NSLP data. Additional
types are allocated for errors and messaging association keepalive.
GIMPS-Message = GIMPS-Query / GIMPS-Response /
GIMPS-Confirm / GIMPS-Data /
GIMPS-Error / GIMPS-MA-Hello
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
and configuration data are mandatory if the message exchange relates
to setup of a messaging association.
GIMPS-Query = Common-Header
Message-Routing-Information
Session-Identification
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ 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 in D-mode
carries its own Network-Layer-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, as is its
own stack proposal and configuration data.
Schulzrinne & Hancock Expires January 19, 2006 [Page 31]
Internet-Draft GIMPS July 2005
GIMPS-Response = Common-Header
Message-Routing-Information
Session-Identification
[ Network-Layer-Information ]
Query-Cookie
[ Responder-Cookie
[ Stack-Proposal Stack-Configuration-Data ] ]
[ 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
Network-Layer-Information
Responder-Cookie
[ Stack-Proposal ]
[ NSLP-Data ]
GIMPS-Data: A plain data message contains no control objects, but
only the MRI and SID associated with the NSLP data being transferred.
Network-Layer-Information is only carried in the datagram mode case.
GIMPS-Data = Common-Header
Message-Routing-Information
Session-Identification
[ Network-Layer-Information ]
NSLP-Data
GIMPS-Error: A GIMPS-Error message reports a problem determined at
the GIMPS level. (Errors generated by signalling applications are
reported in NSLP-Data payloads and are not treated specially by
GIMPS.) The message includes a Network-Layer-Information object for
the originator of the error message it if is being sent in datagram
mode; all other information related to the error is carried in a
GIMPS-Error-Data object.
GIMPS-Error = Common-Header
[ Network-Layer-Information ]
GIMPS-Error-Data
GIMPS-MA-Hello: This message can be sent only in C-Mode to indicate
Schulzrinne & Hancock Expires January 19, 2006 [Page 32]
Internet-Draft GIMPS July 2005
that a node wishes to keep a messaging association open. It contains
only the common header, with a null NSLPID. A flag can be set in the
Common-Header to indicate that a reply is requested, thus allowing a
node to test the liveness of the peer.
GIMPS-MA-Hello = Common-Header
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 bit patterns are provided in
Appendix C.
5.2.1 The Common Header
Each message begins with a fixed format common header, which contains
the following information:
Version: The version number of the GIMPS protocol.
Length: The number of 32 bit 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.
Response requested: A flag to indicate that a message should be sent
in response to this message.
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
Schulzrinne & Hancock Expires January 19, 2006 [Page 33]
Internet-Draft GIMPS July 2005
message type encapsulation. The ABNF given above fixes the order of
objects within a 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.
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.
Session-Identification (SID): The GIMPS session identifier is a long,
cryptographically random identifier chosen by the node which
originates the signaling exchange. See Section 3.4.
Network-Layer-Information: This object carries information about the
network layer attributes of the node sending the message,
including data related to the management of routing state. This
includes a peer identity and IP address for the sending node. It
also includes IP TTL information to allow the hop count between
GIMPS peers to be measured and reported, and a validity time for
the routing state.
Network-Layer-Information = peer-identity
interface-address
RS-validity-time
IP-TTL
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 the peer-identity, so long as it
is stable. The interface-address must be routable, i.e. it must
be usable as a destination IP address for packets to be sent back
to the node generating the signalling message (whether in datagram
or connection mode). This rules out the use of certain classes of
address, such as link-local addresses (unless the GIMPS peer is
known to be on-link). Where this object is used in a GIMPS-Query,
the interface-address 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 handling, see Section 7.1. The use of the
RS-validity-time field is described in Section 4.4.3.
The setting and interpretation of the IP-TTL field depends on the
message direction (as determined from the MRI) and encapsulation.
Schulzrinne & Hancock Expires January 19, 2006 [Page 34]
Internet-Draft GIMPS July 2005
* 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.7.
Stack-Proposal = 1*stack-profile
stack-profile = 1*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
Stack-Configuration-Data TLV (see below).
Stack-Configuration-Data: This object carries information about the
overall configuration of a messaging association.
Stack-Configuration-Data = MA-hold-time
0*higher-layer-addressing
The MA-hold-time field indicates how long a node will hold open an
inactive association; see Section 4.4.3 for more discussion. The
higher-layer-addressing fields give the configuration of the
protocols to be used for new messaging associations, and they are
described in more detail in Section 5.7.
Schulzrinne & Hancock Expires January 19, 2006 [Page 35]
Internet-Draft GIMPS July 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. See Section 8.5 for further details
on requirements and mechanisms for cookie generation.
NSLP-Data: The NSLP payload to be delivered to the signaling
application. GIMPS does not interpret the payload content.
GIMPS-Error-Data: This contains all the information to determine the
cause and context of an error.
GIMPS-Error-Data = error-class
error-code error-subcode
common-header
[ Message-Routing-Information-content ]
[ Session-Identification-content ]
0*additional-information
[ comment ]
The error-class indicates the severity level, and the error-code
and error-subcode identify the specific error itself. A full list
of GIMPS errors and their severity levels is given in
Appendix C.5. The common-header from the original message is
always included, as are the contents of the Message-Routing-
Information and Session-Identification objects if they were
successfully decoded. For some errors, additional information
fields must be included according to a fixed format; finally, an
optional free-text comment may be added.
5.3 Datagram Mode Transport
This section describes the various encapsulation options for datagram
mode messages. Although there are several 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, minimal 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 36]
Internet-Draft GIMPS July 2005
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
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. Each NSLPID
corresponds to a unique RAO value, but not necessarily vice versa;
further details are discussed in [34].
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 is required.
5.3.3 Retransmission and Rate-Control
Datagram mode uses 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
Schulzrinne & Hancock Expires January 19, 2006 [Page 37]
Internet-Draft GIMPS July 2005
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:
1. 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, since the node is
already managing state for that flow. The problem of an
amplification attack stimulated by a malicious Query should be
handled by requiring the cookie mechanism to enable the node
receiving the Response to discard it efficiently if it does not
match a previously sent Query.
2. Where the responding node is not prepared to store per-flow state
until receiving a properly formed Confirm message.
In case (2), 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 MRI/NSLP combination for which there is no
stored routing state (since this state is only created on receipt of
a Confirm).
Schulzrinne & Hancock Expires January 19, 2006 [Page 38]
Internet-Draft GIMPS July 2005
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 transmitted and
successfully received. The mechanism to cause this is for the
Responding node to reject the incoming message with a "No Routing
State" error message (Appendix C.5.4.6) back to the Querying node,
which interprets this as caused by a lost Confirm; the Querying node
needs to be able to regenerate the Confirm purely from local state
(e.g. in particular it needs to remember a valid Responder Cookie).
The basic rate-control 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 [10] 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 [24] that it
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 [8] satisfies all requirements.
DCCP [9] 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, 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 39]
Internet-Draft GIMPS July 2005
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.
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 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 40]
Internet-Draft GIMPS July 2005
+---------------------------------------------+
| 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 Message Type/Encapsulation Relationships
GIMPS has four primary message types (Query/Response/Confirm/Data)
and three possible encapsulation methods (D-Mode Normal/D-Mode Query/
C-Mode). For information, the allowed combinations of message type
and encapsulation are given in the table below. However, it should
be noted that the processing of the message at the receiver is not
directly affected by the encapsulation method used, with the
exception that the decapsulation process may provide additional
information (e.g. translated addresses or IP hop count) which is used
in the subsequent message processing. The selection of the
encapsulation method is a matter for the message sender.
+----------------+----------------+----------------+----------------+
| Message | D-Mode Normal | D-Mode Query | C-Mode |
+----------------+----------------+----------------+----------------+
| GIMPS-Query | Never | Always | Never |
| | | | |
| GIMPS-Response | Unless a | Never | If a messaging |
| | messaging | | association is |
| | association is | | being re-used |
| | being re-used | | |
| | | | |
Schulzrinne & Hancock Expires January 19, 2006 [Page 41]
Internet-Draft GIMPS July 2005
| GIMPS-Confirm | Unless a | Never | If a messaging |
| | messaging | | association |
| | association | | has been set |
| | has been set | | up or is being |
| | up or is being | | re-used |
| | re-used | | |
| | | | |
| GIMPS-Data | If routing | If no routing | If a messaging |
| | state exists | state exists | association |
| | for the flow | and the MRI | exists |
| | but no | can be used to | |
| | appropriate | derive the | |
| | messaging | query | |
| | association | encapsulation | |
+----------------+----------------+----------------+----------------+
5.6 Error Message Processing
Special rules apply to the encapsulation and transmission of error
messages, and they are described here.
GIMPS only generates error messages in response to incoming messages.
(Error messages must not be generated in response to incoming error
messages.) The routing and encapsulation of the error message is
derived from that of the message that caused the error; in
particular, local routing state is not consulted. No routing state
or messaging association state should be created to handle the error,
and error messages are not retransmitted explicitly by GIMPS,
although they are subject to the same rate control as other messages.
o If the incoming message was received in datagram mode, the error
is send in datagram mode using the 'normal' encapsulation, using
the addressing information from the NLI object in the incoming
message. The NLI object in the GIMPS-Error message reports
information about the generator of the error.
o If the incoming message was received over a messaging association,
the error is sent back over the same messaging association.
The NSLPID in the common header of the GIMPS-Error is the null value
(as for GIMPS-MA-Hello). If for any reason the error message cannot
be sent (for example, if the NLI of the inbound message could not be
decoded, or because an error message is too large to send in datagram
mode), an error should be logged locally.
Schulzrinne & Hancock Expires January 19, 2006 [Page 42]
Internet-Draft GIMPS July 2005
5.7 Messaging Association Negotiation
5.7.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 feature
negotation cannot be added to an existing protocol in a backwards-
compatible way. Therefore, some sort of negotiation capability is
required.
Protocol negotiation is carried out in GIMPS-Query/Response messages,
using Stack-Proposal and Stack-Configuration-Data 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. The end result of the
negotiation is a messaging association which is a stack of protocols.
If multiple associations exist, it is a matter of local policy how to
distribute messages over them, subject to respecting the transfer
attributes requested for each message.
Every possible protocol for a messaging association has the following
attributes:
o MA-Protocol-ID, a 1-byte IANA assigned value.
o A specification of the (non-negotiable) policies about how the
protocol should be used (for example, in which direction a
connection should be opened).
o Formats for carrying the protocol addressing and other
configuration information in higher-layer-addressing information
elements in the Stack-Configuration-Data object. There are
different formats depending on whether the information is carried
in the Query or Response.
A Stack-Proposal object is simply a list of profiles; each profile is
a sequence of MA-Protocol-IDs. A Stack-Proposal is generally
accompanied by a Stack-Configuration-Data object which carries a
higher-layer-addressing information element for every protocol listed
in the Stack-Proposal. A node generating a Stack-Configuration-Data
object is committed to honouring the implied protocol configuration;
Schulzrinne & Hancock Expires January 19, 2006 [Page 43]
Internet-Draft GIMPS July 2005
in particular, it must be immediately prepared to accept incoming
datagrams or connections at the 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 Stack-Configuration-Data 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
responder's Stack-Proposal over it in the GIMPS-Confirm. The
responding node can verify this to ensure that no bidding-down attack
has occurred.
5.7.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 higher-layer-addressing field is needed.
o upstream: 2 byte port number at which the connection will be
accepted.
5.7.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 [20] for message compression.
o ssh [29] or HIP/IPsec [30] for channel security.
Schulzrinne & Hancock Expires January 19, 2006 [Page 44]
Internet-Draft GIMPS July 2005
o Alternative modes of TCP operation, for example where it is set up
from the responder to the querying node.
5.8 Specific Message Routing Methods
Each message routing method (see Section 3.3) requires the definition
of the format of the message routing information (MRI) and Query-
encapsulation rules. These are given in the following subsections
for the various possible message routing methods.
5.8.1 The Path-Coupled MRM
5.8.1.1 Message Routing Information
For the path-coupled MRM, this is just the Flow Identifier as in
[24]. 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 7.2
and Section 7.3 for further discussion).
MRI = network-layer-version
source-address prefix-length
destination-address prefix-length
IP-protocol
diffserv-codepoint
[ flow-label ]
[ ipsec-SPI / L4-ports]
Additional control information defines whether the flow-label, SPI
and port information are present, the direction of the signalling
message relative to this flow, and whether the IP-protocol and
diffserv-codepoint fields should be interpreted as significant. The
source and destination addresses should be host addresses, but prefix
lengths other than 32/128 (for IPv4/6) can be provided to implement
address 'wildcarding', allowing the MRI to refer to traffic to or
from a wider address range.
5.8.1.2 Downstream Query Encapsulation
Where the signalling 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.
Schulzrinne & Hancock Expires January 19, 2006 [Page 45]
Internet-Draft GIMPS July 2005
o By default, the source address is the flow source address, again
from the 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
(such as 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, with 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 mimics the actual data flow as
closely as possible, since this is the basis of how the signaling
message is attached to the data path. To this end, GIMPS may set the
DiffServ codepoint and (for IPv6) flow label to match the values in
the MRI if this would be needed to ensure correct routing.
Any message sent in datagram mode should be below a conservative
estimate of the path MTU (e.g. 512 bytes). It is possible that
fragmented datagrams including an RAO will not be correctly handled
in the network, so the sender may set the DF (do not fragment) bit in
the IPv4 header in order to detect that a message has encountered a
link with an unusually low MTU. In this case, it must use the
signalling source address for the IP source address in order to
receive the ICMP error.
A GIMPS implementation may apply validation checks to the MRI, to
reject Query messages that are being injected by nodes with no
legitimate interest in the flow being signalled for. In general, if
the GIMPS node can detect that no flow could arrive over the same
interface as the Query message, it should be rejected. (Such checks
apply only to messages with the query encapsulation, since only those
Schulzrinne & Hancock Expires January 19, 2006 [Page 46]
Internet-Draft GIMPS July 2005
messages are required to track the flow path.) The main checks are
that the IP version should match the version(s) used on that
interface, and that the full range of source addresses (the source-
address masked with its prefix-length) would pass ingress filtering
checks.
5.8.1.3 Upstream Query Encapsulation
In some deployment scenarios it is desirable and logically possible
to set up routing state in the upstream direction (from flow receiver
towards the sender). This could be used to support firewall
signaling to control traffic from an 'un-cooperative' sender, or
signalling in general where the flow sender was not NSIS-capable.
This can be incorporated into the GIMPS protocol structure by
defining an encapsulation and processing rules for sending Query
messages upstream.
In general, it is not possible to determine the hop-by-hop route
upstream because of asymmetric routing. However, in particular
cases, the upstream peer can be discovered with a high degree of
confidence, for example:
o The upstream GIMPS peer is 1 IP hop away, and can be reached by
tracing back through the interface on which the flow arrives.
o The upstream peer is a border router of a single-home (stub)
network.
This section defines an upstream Query encapsulation and validation
checks for when it can be used. The functionality to generate
upstream Queries is optional, but if received they should be
processed in the normal way (no special functionality is needed for
this). It is possible for routing state (for a given MRI and NSLPID)
to be installed by both upstream and downstream Query exchanges. If
the SIDs are different, these items of routing state should be
considered as independent; if they match, that installed by the
downstream exchange should take precedence.
The details of the encapsulation are as follows:
o The destination address SHOULD be the flow source address as given
in the MRI of the message payload. An implementation with more
detailed knowledge of local routing MAY use an alternative
destination address (e.g. the address of its default router).
o The source address SHOULD be the signalling node address.
Schulzrinne & Hancock Expires January 19, 2006 [Page 47]
Internet-Draft GIMPS July 2005
o The DiffServ codepoint and (for IPv6) flow label may be set to
match the values from the MRI, as in the downstream case. The
same considerations about message size and fragmentation also
apply as in the downstream case, and RAO setting and UDP port
selection are also the same.
o The IP-TTL of the message MUST be set to 255.
The sending GIMPS implementation should attempt to send the Query
message out of the same interface and to the same link layer
neighbour from which the data packets of the flow are arriving.
The receiving GIMPS implementation may apply validation checks to the
message and MRI, to reject Query messages which have reached a node
at which they can no longer be trusted. In particular, a node may
reject a message which has been propagated more than one IP hop, with
a "Invalid IP TTL" error message (Appendix C.5.4.12). This can be
determined by examining the received IP TTL, similar to the
generalised IP TTL security mechanism described in [23].
Alternatively, receipt of an upstream Query at the flow source may be
used to trigger setup of NTLP state in the downstream direction.
These restrictions may be relaxed in a future version.
5.8.2 The Loose-End MRM
This MRM is used to discover GIMPS nodes with particular properties
in the direction of a given address, for example to discover a NAT
along the upstream data path. It is based on work originally
documented in [33].
5.8.2.1 Message Routing Information
For the loose-end MRM, only a simplified version of the Flow
Identifier is required.
MRI = network-layer-version
source-address
destination-address
The source address is the address of the node initiating the
discovery process, for example the node that will be the data
receiver in the NAT discovery case. The destination address is the
address of a node which is expected to be the 'other side' of the
node to be discovered. Additional control information defines the
direction of the message relative to this flow.
Schulzrinne & Hancock Expires January 19, 2006 [Page 48]
Internet-Draft GIMPS July 2005
5.8.2.2 Downstream Query Encapsulation
Only one encapsulation is defined for the loose-end MRM; by
convention, this is referred to as the downstream encapsulation, and
is defined as follows:
o The IP destination address MUST be the destination address as
given in the MRI of the message payload.
o By default, the IP source address is the source address, again
from the MRI. 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
(such as unreachable port or address). If these are delivered
to the MRI 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, with use based on local policy.
A node SHOULD use the MRI source address for initial Query
messages, but MAY transition to the signaling source address for
retransmissions or as a matter of static configuration. A flag in
the common header tells the message receiver which option was
used.
There are no special requirements on the setting of the DiffServ
codepoint, IP TTL, or (for IPv6) the flow label. Nor are any special
validation checks applied.
Any message sent in datagram mode should be below a conservative
estimate of the path MTU (e.g. 512 bytes). It is possible that
fragmented datagrams including an RAO will not be correctly handled
in the network, so the sender may set the DF (do not fragment) bit in
the IPv4 header in order to detect that a message has encountered a
link with an unusually low MTU. In this case, it must use the
signalling source address for the IP source address in order to
receive the ICMP error.
Schulzrinne & Hancock Expires January 19, 2006 [Page 49]
Internet-Draft GIMPS July 2005
6. Formal Protocol Specification
This section provides a more formal specification of the operation of
GIMPS processing, in terms of rules for transitions between states of
a set of communicating state machines within a node.
Conceptually, the operation of GIMPS processing at a node may be seen
as the cooperation of 4 types of state machine:
1. There is a top-level state machine which represents the node
itself (Node-SM). This is responsible for the processing of
events which cannot be directed towards a more specific state
machine, for example, inbound messages for which no per-flow
routing state currently exists. This machine exists permanently,
and is responsible for creating 'per-flow' state machines to
manage the operation of the GIMPS handshake and routing state
maintenance procedures.
2. For each flow and signalling direction where the node is
responsible for initiating the creation of routing state, there
is an instance of a Query-Node Routing state machine (Query-SM).
This machine sends Query and Confirm messages and waits for
Responses, according to the requirements from locally generated
API commands or timer processing (e.g. message repetition or
routing state refresh).
3. For each flow and signalling direction where the node has
accepted the creation of routing state by a peer, there is an
instance of a Responding-Node Routing state machine
(Response-SM). This machine is responsible for managing the
status of the routing state for that flow. In some cases, it is
also responsible for [re]transmission of Response messages;
however, in many cases, the generation of Response messages is
handled by the Node-SM, and a Response-SM is not even created for
a flow until a properly formatted Confirm has been accepted.
4. Messaging assocations have their own lifecycle, represented by
MA-SM, from when they are first created (in an 'incomplete'
state, listening for an inbound connection or waiting for
outbound connections to complete), to when they are active and
available for use.
Note that, apart from the fact that the various machines can be
created and destroyed by each other, there is almost no interaction
between them. The machines for different flows do not interact; the
Query-SM and Response-SM for a single flow and signalling direction
do not interact. That is, the Response-SM which accepts the creation
of routing state for a flow on one interface has no direct
Schulzrinne & Hancock Expires January 19, 2006 [Page 50]
Internet-Draft GIMPS July 2005
interaction with the Query-SM which sets up routing state on the next
interface along the path. This interaction is mediated instead
through the NSLP.
The state transition diagrams use the following terminology for event
naming:
o rx_ = a message received event. The rest of the event name is the
name of the message
o tg_ = a trigger event, either from the API or from another
internal state machine.
o to_ = a timeout event.
o er_ = an error indication event. This may be filtered back to the
NSLP.
6.1 Node Processing
The Node level state machine is responsible for processing events for
which no more appropriate messaging association state or routing
state exists. Its structure is trivial: there is a single state
('Idle'); all events cause a transition back to Idle. Some events
cause the creation of other state machines.
Incoming Events:
+----------------+---------------------------------------------+
| Name | Meaning |
+----------------+---------------------------------------------+
| rx_Query | A GIMPS Query message has been received. |
| | |
| rx_Response | A GIMPS Response message has been received. |
| | |
| rx_Confirm | A GIMPS Confirm message has been received. |
| | |
| rx_Data | A GIMPS Data message has been received. |
| | |
| tg_SendMessage | A SendMessage event from the API. |
+----------------+---------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 51]
Internet-Draft GIMPS July 2005
Predicates:
+------------------+------------------------------------------------+
| Name | Meaning |
+------------------+------------------------------------------------+
| paranoid | The combination of local policy and transfer |
| | attributes mean that the node will not allow |
| | routing state to be created for a flow until |
| | the full Q/R/C sequence is complete. This |
| | corresponds to case 4 of the possible Q/R/C |
| | sequences. |
+------------------+------------------------------------------------+
State Transition Table:
+----------------+---------------------+
| Incoming Event | Rule in state: Idle |
+----------------+---------------------+
| rx_Query | Rule 1 |
| | |
| rx_Response | Rule 2 |
| | |
| rx_Confirm | Rule 3 |
| | |
| rx_Data | Rule 4 |
| | |
| tg_SendMessage | Rule 5 |
+----------------+---------------------+
The processing rules are as follows:
Rule 1:
if !paranoid
create R-SM
pass message to it
else
send Response
[Next state: Idle]
Rule 2:
// must already have a Q-SM to be receiving this
discard message
send Err_NoRtgState message
[Next state: Idle]
Schulzrinne & Hancock Expires January 19, 2006 [Page 52]
Internet-Draft GIMPS July 2005
Rule 3:
if !paranoid
// should already have R-SM for it
discard message
send Err_NoRtgState message
else
create R-SM
pass message to it
[Next state: Idle]
Rule 4:
pass directly to NSLP
[Next state: Idle]
Rule 5:
if Q-mode encapsulation is not possible for this MRI
reject message with an error
else
if local policy & transfer attributes say routing state is not needed
send message statelessly
else
create Q-SM
pass message to it
[Next state: Idle]
6.2 Query Node Processing
The Querying-Node state machine (Q-SM) has three states:
o Awaiting Response
o Established
o Awaiting Refresh
The Q-SM is created by the N-SM machine as a result of a request to
send a message for a flow in a signalling direction where the
appropriate state does not exist. The Query is generated
immediately, and the machine transitions to the Awaiting Response
state, in which timout-based retransmissions are handled. Once a
Response has been successfully recieved and routing state created,
the machine transitions to Established, during which NSLP data can be
sent and received normally. The Awaiting Refresh state can be
considered as a substate of Established, where a new Query has been
Schulzrinne & Hancock Expires January 19, 2006 [Page 53]
Internet-Draft GIMPS July 2005
generated to refresh the routing state (as in Awaiting Response) but
NSLP data can be handled normally.
tg_Initialise_QNode +-----+
-------------------------|Birth|
| +-----+
|
|
| tg_NSLP_Data
| tg_NSLP_Data er_No_RSM || rx_Data
| -------- -------------------- --------
| | V | || V
| | V | || V
| +----------+ | +-----------+
---->>| Awaiting | ---------------->> |Established|
------| Response |------------------------------>> | |
| +----------+ rx_Response +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Response | |
| [!nResp_reached] tg_NSLP_Data | |
| || rx_Data | |
| -------- | |
| | V | |
| to_No_Response | V | |
| [nResp_reached] +-----------+ rx_Response | |
---------- ------------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ to_Refresh_QNode
| | ^ | || tg_Rtg_Update
| | ^ |
| | --------
| | to_No_Response
| | [!nResp_reached]
V V
V V
+-----+
|Death|<<---------------
+-----+ to_Inactive_QNode
(from all states)
Figure 6: Query Node State Machine
Schulzrinne & Hancock Expires January 19, 2006 [Page 54]
Internet-Draft GIMPS July 2005
Incoming Events:
+------------------------+------------------------------------------+
| Name | Meaning |
+------------------------+------------------------------------------+
| tg_Initialise_QNode | This RS has just been created. |
| | |
| rx_Response | A Response message is received. |
| | |
| rx_Data | A data only message is received. |
| | |
| rx_Err_NoRtgState | An error message is received from the |
| | peer node indicating that it received a |
| | data message for which there is no |
| | stored routing state. |
| | |
| tg_NSLP_Data | An event is received requesting |
| | transmission of a message. |
| | |
| tg_Set_QNode_Lifetime | An event is received from the API |
| | setting the lifetime of the routing |
| | state associated with this SM. This |
| | event sets the period of the |
| | Inactive_QNode timer. |
| | |
| tg_NetNotification | An event is recieved indicating that the |
| | routing state associated with this state |
| | machine is invalid. |
| | |
| to_Refresh_QNode | A timeout is received indicating that |
| | the routing state associated with this |
| | state machine should be refreshed. |
| | |
| to_No_Response | A timeout is received indicating that no |
| | Response has been received in answer to |
| | a Query. |
| | |
| to_Inactive_QNode | This Q-Node is inactive an can be |
| | deleted. |
+------------------------+------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 55]
Internet-Draft GIMPS July 2005
Timers:
+---------------------+---------------------------------------------+
| Name | Meaning |
+---------------------+---------------------------------------------+
| Refresh_QNode | Indicates when the routing state stored by |
| | this state machine needs to be refreshed. |
| | It is reset whenever a Response is received |
| | indicating that the routing state is still |
| | valid. The period of this timer is set by |
| | the RS-validity-time field of a Reponse |
| | message. |
| | |
| No_Response | Indicates that a Response has not been |
| | received in answer to a Query. This is |
| | started whenever a Query is sent and |
| | stopped when a Response is received. |
| | |
| Inactive_QNode | Indicates that no traffic is currently |
| | being handled by this state machine. This |
| | is reset whenever the state machine handles |
| | NSLP data (in either direction). The period |
| | of this timer is set via the API. |
+---------------------+---------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 56]
Internet-Draft GIMPS July 2005
State Transition Table
+-------------------+-----------+-----------+-----------+-----------+
| Incoming Event | Rule in | Rule in | Rule in | Rule in |
| | state: | state: | state: | state: |
| | Birth | Awaiting | Establish | Awaiting |
| | | Response | ed | Refresh |
+-------------------+-----------+-----------+-----------+-----------+
| tg_Initialise_QNo | Rule 1 | Rule - | Rule - | Rule - |
| de | | | | |
| | | | | |
| rx_Response | Rule - | Rule 2 | Rule s | Rule 2 |
| | | | | |
| rx_Data | Rule - | Rule 10 | Rule 7 | Rule 7 |
| | | | | |
| rx_Err_NoRtgState | Rule - | Rule - | Rule 11 | Rule - |
| | | | | |
| tg_NSLP_Data | Rule - | Rule 3 | Rule 8 | Rule 8 |
| | | | | |
| tg_Set_QNode_Life | Rule - | Rule 4 | Rule 4 | Rule 4 |
| time | | | | |
| | | | | |
| tg_NetNotificatio | Rule - | Rule - | Rule 5 | Rule - |
| n | | | | |
| | | | | |
| to_Refresh_QNode | Rule - | Rule - | Rule 5 | Rule - |
| | | | | |
| to_No_Response | Rule - | Rule 6 | Rule - | Rule 6 |
| | | | | |
| to_Inactive_Qnode | Rule - | Rule - | Rule 9 | Rule 9 |
+-------------------+-----------+-----------+-----------+-----------+
The processing rules are as follows:
Rule s:
silently Ignore
[Next state: Present State]
Rule -:
// This event/state combination should never occur
raise fatal error
[Next state: Death]
Schulzrinne & Hancock Expires January 19, 2006 [Page 57]
Internet-Draft GIMPS July 2005
Rule 1:
if local policy & transfer attributes allow D-mode
include NSLP data in Query
else
store NSLP data for later transmission
send Query message
start No_Response timer
store any security
handle from the API
[Next state: Awaiting Response]
Rule 2:
if an MA-SM is needed
create one
if a Confirm is required
send Confirm message*
pass any NSLP data to the NSLP
send any
stored Data messages
stop No_Response timer
start Refresh_QNode timer
start Inactive_QNode timer
[Next state: Established]
Rule 3:
store message
[Next state: Awaiting Response]
Rule 4:
restart Inactive_QNode timer with new value
[Next state: Present State]
Rule 5:
send Query message*
start No_Response timer
stop Refresh_QNode timer
[Next state: Awaiting Refresh]
Rule 6:
Schulzrinne & Hancock Expires January 19, 2006 [Page 58]
Internet-Draft GIMPS July 2005
if number of Queries sent has reached the threshold
// nQuery_isMax is true
indicate No Response error to NSLP
destroy self
[Next state: Death]
else
send Query message*
start No_Response timer with new value
[Next state: Present State]
Rule 7:
pass any data to the NSLP
(re)start Inactive_QNode timer
[Next state: Present State]
Rule 8:
send Data message
restart Inactive_QNode timer
[Next state: Present State]
Rule 9:
destroy self
[Next state: Death]
Rule 10:
// This should never happen but may indicate a lost Response
send Query message*
start No_Response timer
stop Refresh_QNode timer
[Next state: Present State]
Rule 11:
// Assume the Confirm was lost in transit so resend it
send Confirm message
restart Refresh_QNode timer
restart Inactive_QNode timer
[Next state: Present State]
6.3 Responder Node Processing
The Responding-Node state machine (R-SM) has three states:
Schulzrinne & Hancock Expires January 19, 2006 [Page 59]
Internet-Draft GIMPS July 2005
o Awaiting Confirm
o Established
o Awaiting Refresh
The policy governing the creation of the R-SM has 4 cases, and these
affect which state the state machine enters first:
1. No state machine is ever created (there is a single Query-
Response exchange but the responder never stores backwards
routing state and there is no Confirm).
2. The R-SM is created on receipt of a Query message, but no Confirm
is requested.
3. The R-SM is again created on receiving a Query, but a Confirm is
requested. A timer is used to generate retransmitted Response
messages and the R-SM is destroyed if a valid Confirm message is
not forthcoming after some number of them.
4. The R-SM cannot be created until a valid Confirm message is
received.
In case 4 the R-SM is created in the Awaiting Confirm state. The
R-SM remains in this state until a Confirm is received, at which
point it transitions to the Established state. In cases 2 and 3 the
R-SM is created already in the Established state. In Established
state the NSLP can send and receive data normally. The Awaiting
Refresh state can be considered a substate of Established, where a
Query has been received to begin the routing state refresh. In this
state the R-SM behaves as in the Awaiting Confirm state, except that
the NSLP can still send and receive data.
Schulzrinne & Hancock Expires January 19, 2006 [Page 60]
Internet-Draft GIMPS July 2005
rx_Query rx_Query
[confirmRequired] +-----+ [!confirmRequired]
-------------------------|Birth|----------------------------
| +-----+ |
| | rx_Confirm |
| ---------------------------- |
| | |
| | |
| tg_NSLP_Data | |
| || rx_Data | |
| || rx_Query | |
| tg_NSLP_Data [!confirmRequired] | |
| -------- -------------- | |
| | V | V V V
| | V | V V V
| +----------+ | +-----------+
---->>| Awaiting | rx_Confirm -----------|Established|
------| Confirm |------------------------------>> | |
| +----------+ +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Confirm | |
| [!nConf_reached] tg_NSLP_Data | |
| || rx_Data | |
| -------- | |
| | V | |
| to_No_Confirm | V | |
| [nConf_reached] +-----------+ rx_Confirm | |
---------- ------------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ rx_Query
| | ^ | [confirmRequired]
| | ^ |
| | --------
| | to_No_Confirm
| | [!nConf_reached]
V V
V V
+-----+
|Death|<<---------------------
+-----+ to_Expire_RNode
(from all states)
Figure 7: Responder Node State Machine
Schulzrinne & Hancock Expires January 19, 2006 [Page 61]
Internet-Draft GIMPS July 2005
Incoming Events:
+------------------------+------------------------------------------+
| Name | Meaning |
+------------------------+------------------------------------------+
| rx_Query | Node receives a Query message. |
| | |
| rx_Data | Node receives a data message. |
| | |
| rx_Confirm | Node receives a Confirm message. |
| | |
| tg_NSLP_Data | A SendMessage event is received from the |
| | API requesting transmission of a |
| | message. |
| | |
| tg_Invalidate | An event is recieved, from the N-SM or |
| | the RC-SM marking the routing state |
| | associated with this SM as invalid. |
| | |
| to_Expire_RNode | A timeout is received indicating that |
| | the RS should be expired immediately. |
| | Note: state may not be refreshed from |
| | the R-Node |
| | |
| to_No_Confirm | A timeout is received indicating that we |
| | have not received a confirm for this RS |
| | where one was expected. |
+------------------------+------------------------------------------+
Timers:
+---------------------+---------------------------------------------+
| Name | Meaning |
+---------------------+---------------------------------------------+
| Expire_RNode | Indicates when the routing state stored by |
| | this state machine needs to be expired. It |
| | is reset whenever a Query or Confirm |
| | (depending on local policy) is received |
| | indicating that the routing state is still |
| | valid. |
| | |
| No_Confirm | Indicates that a Confirm has not been |
| | received in answer to a Response. This is |
| | started / reset whenever a Response is sent |
| | and stopped when a Confirm is received. |
+---------------------+---------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 62]
Internet-Draft GIMPS July 2005
State Transition Table
+-------------------+-----------+-----------+-----------+-----------+
| Incoming Event | Rule in | Rule in | Rule in | Rule in |
| | state: | state: | state: | state: |
| | [Start] | Awaiting | Establish | Awaiting |
| | | Confirm | ed | Refresh |
+-------------------+-----------+-----------+-----------+-----------+
| rx_Query | 1 | s | 9 | s |
| | | | | |
| rx_Confirm | 2 | 3 | s | 3 |
| | | | | |
| rx_Data | - | 10 | 7 | 7 |
| | | | | |
| tg_NSLP_Data | - | 5 | 4 | 4 |
| | | | | |
| to_Expire_RNode | - | 8 | 8 | 8 |
| | | | | |
| to_No_Confirm | - | 6 | - | 6 |
+-------------------+-----------+-----------+-----------+-----------+
The processing rules are as follows:
Rule -:
// This event/state combination should never occur
raise fatal error
[Next state: Death]
Rule s:
silently Ignore
[Next state: Present State]
Rule 1:
if MA-SM is needed
create one
if local policy & transfer attributes require a Confirm message
// confirmRequired is true
send Response message*
start No_Confirm timer
[Next state: Awaiting Confirm]
else
send Response message*
start Expire_RNode timer
[Next state: Established]
Schulzrinne & Hancock Expires January 19, 2006 [Page 63]
Internet-Draft GIMPS July 2005
Rule 2:
if MA-SM is needed
create one
start Expire_RNode timer
[Next state: Established]
Rule 3:
send any stored Data messages*
stop No_Confirm timer
start Expire_RNode timer
[Next state: Established]
Rule 4:
send Data message*
[Next state: Present State]
Rule 5:
store Data message
[Next state: Present State]
Rule 6:
if number of Responses sent has reached threshold
// nResp_isMax is true
destroy self
[Next state: Death]
else
send Response message*
start No_Response timer
[Next state: Present State]
Rule 7:
pass data to NSLP
[Next state: Present State]
Rule 8:
destroy self
[Next state: Death]
Schulzrinne & Hancock Expires January 19, 2006 [Page 64]
Internet-Draft GIMPS July 2005
Rule 9:
stop Expire_RNode timer
if local policy & transfer attributes require a Confirm message
// confirmRequired is true
send Response message*
start No_Confirm timer
[Next state: Awaiting Refresh]
else
send Response message*
start Expire_RNode timer
[Next state: Established]
Rule 10:
send Err_NoRtgState message*
[Next state: Present State]
6.4 Messaging Association Processing
Messaging associations are modelled for use within GIMPS with a
simple 3-state process. The two main states indicate that the
messaging association is either waiting for the connection process to
complete, or open and ready to use. In addition there is an
'Uninterested' state in which the local node no longer requires the
messaging association but the remote node still requires it to be
kept open.
Clearly, many internal details of the messaging assocation protocols
are hidden in this model, especially where the messaging association
uses multiple protocol layers; however, the specification of these is
left up to the individual protocol definitions. Note also that
although the existence of messaging associations is not directly
visible to NSLPs, there is some interaction between the two because
security-related information becomes available during the open
process, and this may be indicated to signalling applications if they
have requested it.
Schulzrinne & Hancock Expires January 19, 2006 [Page 65]
Internet-Draft GIMPS July 2005
tg_Initialise_MA +-----+
----------------------------|Birth|
| +-----+
|
| tg_Send_Message
|| rx_Data
|| rx_Hello
| tg_Send_Message || to_SendHello
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected | Connected |
------|Connection|------------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_Send_Message^ |
| || rx_Data | |to_NoActivity
| | V
| | V
| er_MA_Connect +-----+ to_NoHello +-----------+
--------------->>|Death|<<-------------------| Idle |
+-----+ | |
^ +-----------+
^ ^ |
| ^ |
----------------- --------
er_MA_Failure rx_Hello
(from all states)
Figure 8: Messaging Association State Machine
Schulzrinne & Hancock Expires January 19, 2006 [Page 66]
Internet-Draft GIMPS July 2005
Incoming Events
+------------------------+------------------------------------------+
| Name | Meaning |
+------------------------+------------------------------------------+
| to_NoActivity | A timeout is received indicating that |
| | there has not been any activity on this |
| | node for a period of time. |
| | |
| to_SendHello | A timeout is received indicating that an |
| | MAHello message should be sent to the |
| | remote node. |
| | |
| to_NoHello | A timeout is received indicating that an |
| | MAHello has not been received from the |
| | remote node for a period of time. |
| | |
| tg_Initialise_MA | This MA has just been created. |
| | |
| tg_Send_Data | A request has been made to send a C-Mode |
| | message over this MA. |
| | |
| er_MA_Connect | An error occurred while creating the |
| | connection. Either an active connect |
| | failed, or no incoming connection was |
| | received within a certain timeout. |
| | |
| tg_Connected | The connection to the peer has been |
| | created. |
| | |
| rx_Data | A GIMPS Query, Response, Confirm or Data |
| | message has been received over this MA. |
| | |
| rx_Hello | An MA-Hello message has been received |
| | over this MA. |
| | |
| er_MA_Failure | The messaging association has been |
| | destroyed by lower layer protocol |
| | operations (e.g. TCP Reset). |
+------------------------+------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 67]
Internet-Draft GIMPS July 2005
Timers:
+------------------------+------------------------------------------+
| Name | Meaning |
+------------------------+------------------------------------------+
| SendHello | Indicates that an MAHello message should |
| | be sent to the remote node. The period |
| | of this timer is determined by the |
| | MA-Hold-Time sent by the remote node |
| | during the Query/Response exchange. |
| | |
| NoHello | Indicates that no MAHello has been |
| | received from the remote node for a |
| | period of time. The period of this timer |
| | is sent to the remote node as the |
| | MA-Hold-Time during the Query/Response |
| | exchange. |
| | |
| NoActivity | Indicates that the link has been |
| | inactive for a period of time. The |
| | period of this timer is implementation |
| | specific but is likely to be related to |
| | the period of the NoHello timer. |
+------------------------+------------------------------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 68]
Internet-Draft GIMPS July 2005
State Transition Table
+------------+------------+-------------+-------------+-------------+
| Incoming | Rule in | Rule in | Rule in | Rule in |
| Event | state: | state: | state: | state: |
| | [Start] | Awaiting | Connected | Inactive |
| | | Connection | | |
+------------+------------+-------------+-------------+-------------+
| tg_Initial | Rule 1 | Rule - | Rule - | Rule - |
| ise_MA | | | | |
| | | | | |
| tg_Send_Da | Rule - | Rule 2 | Rule 5 | Rule 5 |
| ta | | | | |
| | | | | |
| er_MA_Conn | Rule - | Rule 3 | Rule - | Rule - |
| ect | | | | |
| | | | | |
| tg_Connect | Rule - | Rule 4 | Rule - | Rule - |
| ed | | | | |
| | | | | |
| rx_Data | Rule - | Rule - | Rule 6 | Rule 6 |
| | | | | |
| rx_Hello | Rule - | Rule - | Rule 7 | Rule 7 |
| | | | | |
| er_MA_Fail | Rule - | Rule - | Rule 3 | Rule 3 |
| ure | | | | |
| | | | | |
| to_NoActiv | Rule - | Rule - | Rule 9 | Rule - |
| ity | | | | |
| | | | | |
| to_SendHel | Rule - | Rule - | Rule 8 | Rule - |
| lo | | | | |
| | | | | |
| to_NoHello | Rule - | Rule - | Rule - | Rule 3 |
+------------+------------+-------------+-------------+-------------+
The processing rules are as follows:
Rule -:
// This event/state combination should never occur
raise fatal error
[Next state: Death]
Schulzrinne & Hancock Expires January 19, 2006 [Page 69]
Internet-Draft GIMPS July 2005
Rule 1:
// The precise action here depends on protocols used and directionality
create listening endpoints or attempt an active connect
start timers to detect connection failure if necessary
[Next state: Awaiting Connection]
Rule 2:
queue message for later transmission
[Next state: Awaiting Connection]
Rule 3:
destroy self
[Next state: Death]
Rule 4:
pass outstanding queued messages to transport layer
stop any timers controlling connection establishment
start NoActivity timer
start SendHello timer
[Next state: Connected]
Rule 5:
pass message to transport layer
(re)start NoActivity timer
(re)start SendHello
[Next state: Connected]
Rule 6:
pass message to N-SM
(re)start NoActivity timer
[Next state: Connected]
Rule 7:
if reply requested
send MA-Hello
restart NoHello timer
[Next state: Present State]
Schulzrinne & Hancock Expires January 19, 2006 [Page 70]
Internet-Draft GIMPS July 2005
Rule 8:
send MA-Hello message
[Next state: Present State]
Rule 9:
stop NoActivity timer
stop sendHello timer
start NoHello timer
[Next state: Inactive]
Schulzrinne & Hancock Expires January 19, 2006 [Page 71]
Internet-Draft GIMPS July 2005
7. Advanced Protocol Features
7.1 Route Changes and Local Repair
7.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 9. 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 them to carry out local
repair if possible.
Schulzrinne & Hancock Expires January 19, 2006 [Page 72]
Internet-Draft GIMPS July 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 9: A Re-Routing Event
7.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 January 19, 2006 [Page 73]
Internet-Draft GIMPS July 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 January 19, 2006 [Page 74]
Internet-Draft GIMPS July 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 Network-Layer-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 |
| | NLI in | NLI in GIMPS-Query |
| | GIMPS-Response | |
+----------------------+----------------------+---------------------+
Schulzrinne & Hancock Expires January 19, 2006 [Page 75]
Internet-Draft GIMPS July 2005
7.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 January 19, 2006 [Page 76]
Internet-Draft GIMPS July 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.
7.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 [27].
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.
7.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 and
Section 4.4, this situation cannot arise: all NSLP peers which store
routing state about each other 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 January 19, 2006 [Page 77]
Internet-Draft GIMPS July 2005
about local changes in forwarding table state, a flow signaling
protocol is probably not the right starting point.)
7.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 Query 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.8 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.
Message-Routing-Information formats may allow a 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 a "MRI Too Wild" error
message (Appendix C.5.4.13).
7.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
Schulzrinne & Hancock Expires January 19, 2006 [Page 78]
Internet-Draft GIMPS July 2005
signalled for. (This applies to all GIMPS messages, regardless of
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 Network-Layer-Information and Stack-
Configuration-Data objects).
3. Create a new Message-Routing-Information object with fields
modified according to the data flow bindings.
4. Create new Network-Layer-Information and Stack-Configuration-Data
objects 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 Network-Layer-Information 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
Schulzrinne & Hancock Expires January 19, 2006 [Page 79]
Internet-Draft GIMPS July 2005
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 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 [22] can process only
two.
7.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 signaling
session by one of the tunnel endpoints - that is, the tunnel counts
as a new flow. Because the relationship between signaling for the
'microflow' and signaling for the tunnel as a whole will depend on
the signaling application in question, we are assuming that it is a
signaling application responsibility to be aware of the fact that
tunnelling is taking place and to carry out additional signaling if
necessary; in other words, one tunnel endpoint must be signaling
application aware.
In some cases, it is the tunnel exit point (i.e. the node where
tunnelled data and downstream signaling packets leave the tunnel)
that will wish to carry out the tunnel signaling, but this node will
not have knowledge or control of how the tunnel entry point is
carrying out the data flow encapsulation. This information could be
carried as additional data (an additional GIMPS payload) in the
tunnelled signaling packets if the tunnel entry point was at least
GIMPS-aware. This payload would be the GIMPS equivalent of the RSVP
SESSION_ASSOC object of [13]. Whether this functionality should
Schulzrinne & Hancock Expires January 19, 2006 [Page 80]
Internet-Draft GIMPS July 2005
really be part of GIMPS and if so how the payload should be handled
will be considered in a later version.
7.5 IPv4-IPv6 Transition and Interworking
GIMPS itself is essentially IP version neutral (version dependencies
are isolated in the formats of the Message-Routing-Information,
Network-Layer-Information and Stack-Configuration-Data objects, and
GIMPS also depends on the version independence of the protocols that
support messaging associations). In mixed environments, GIMPS
operation will be influenced by the IP transition mechanisms in use.
This section provides a high level overview of how GIMPS is affected,
considering only the currently predominant mechanisms.
Dual Stack: (This applies both to the basic approach described in
[28] as well as the dual-stack aspects of more complete
architectures such as [32].) In mixed environments, GIMPS should
use the same IP version as the flow it is signaling for; hosts
which are dual stack for applications and routers which are dual
stack for forwarding should have GIMPS implementations which can
support both IP versions.
In theory, for some connection mode encapsulation options, a
single messaging association could carry signaling messages for
flows of both IP versions, but the saving seems of limited value.
The IP version used in datagram mode is closely tied to the IP
version used by the data flow, so it is intrinsically impossible
for a IPv4-only or IPv6-only GIMPS node to support signaling for
flows using the other IP version.
Applications with a choice of IP versions might select a version
based on which could be supported in the network by GIMPS, which
could be established by running parallel discovery procedures. In
theory, a GIMPS message related to a flow of one IP version could
flag support for the other; however, given that IPv4 and IPv6
could easily be separately routed, the correct GIMPS peer for a
given flow might well depend on IP version anyway, making this
flagged information irrelevant.
Packet Translation: (Applicable to SIIT [7] and NAT-PT [14].) Some
transition mechanisms allow IPv4 and IPv6 nodes to communicate by
placing packet translators between them. From the GIMPS
perspective, this should be treated essentially the same way as
any other NAT operation (e.g. between 'public' and 'private'
addresses) as described in Section 7.3. In other words, the
translating node needs to be GIMPS-aware; it will run GIMPS with
IPv4 on some interfaces and with IPv6 on others, and will have to
translate the Message-Routing-Information payload between IPv4 and
Schulzrinne & Hancock Expires January 19, 2006 [Page 81]
Internet-Draft GIMPS July 2005
IPv6 formats for flows which cross between the two. The
translation rules for the fields in the payload (including e.g.
DiffServ-codepoint and flow-label) are as defined in [7].
Tunnelling: (Applicable to 6to4 [15] and a whole host of other
tunnelling schemes.) Many transition mechanisms handle the
problem of how an end to end IPv6 (or IPv4) flow can be carried
over intermediate IPv4 (or IPv6) regions by tunnelling; the
methods tend to focus on minimising the tunnel administration
overhead.
From the GIMPS perspective, the treatment should be as similar as
possible to any other IP tunnelling mechanism, as described in
Section 7.4. In particular, the end to end flow signaling will
pass transparently through the tunnel, and signaling for the
tunnel itself will have to be managed by the tunnel endpoints.
However, additional considerations may arise because of special
features of the tunnel management procedures. For example, [16]
is based on using an anycast address as the destination tunnel
endpoint. It might be unwise to carry out signaling for the
tunnel to such an address, and the GIMPS implementation there
would not be able to use it as a source address for its own
signaling messages (e.g. GIMPS-responses). Further analysis will
be contained in a future version of this specification.
Schulzrinne & Hancock Expires January 19, 2006 [Page 82]
Internet-Draft GIMPS July 2005
8. Security Considerations
The security requirement for the GIMPS layer is to protect the
signaling plane against identified security threats. For the
signaling problem as a whole, these threats have been outlined in
[25]; the NSIS framework [24] assigns a subset of the responsibility
to the NTLP. The main issues to be handled can be summarised as:
Message Protection: Signaling message content should be protected
against eavesdropping, modification, injection and replay while in
transit. This applies both to GIMPS payloads, and GIMPS should
also provide such protection as a service to signaling
applications between adjacent peers.
Routing State Integrity Protection: It is important that signaling
messages are delivered to the correct nodes, and nowhere else.
Here, 'correct' is defined as 'the appropriate nodes for the
signaling given the Message-Routing-Information'. In the case
where the MRI is the Flow Identification for path-coupled
signaling, 'appropriate' means 'the same nodes that the
infrastructure will route data flow packets through'. (GIMPS has
no role in deciding whether the data flow itself is being routed
correctly; all it can do is ensure the signaling is routed
consistently with it.) GIMPS uses internal state to decide how to
route signaling messages, and this state needs to be protected
against corruption.
Prevention of Denial of Service Attacks: GIMPS nodes and the network
have finite resources (state storage, processing power,
bandwidth). The protocol should try to minimise exhaustion
attacks against these resources and not allow GIMPS nodes to be
used to launch attacks on other network elements.
The main missing issue is handling authorisation for executing
signaling operations (e.g. allocating resources). This is assumed to
be done in each signaling application.
In many cases, GIMPS relies on the security mechanisms available in
messaging associations to handle these issues, rather than
introducing new security measures. Obviously, this requires the
interaction of these mechanisms with the rest of the GIMPS protocol
to be understood and verified, and some aspects of this are discussed
in Section 5.7.
8.1 Message Confidentiality and Integrity
GIMPS can use messaging association functionality, such as TLS or
IPsec, to ensure message confidentiality and integrity. In many
Schulzrinne & Hancock Expires January 19, 2006 [Page 83]
Internet-Draft GIMPS July 2005
cases, confidentiality of GIMPS information itself is not likely to
be a prime concern, in particular since messages are often sent to
parties which are unknown ahead of time, although the content visible
even at the GIMPS level gives significant opportunities for traffic
analysis. Signaling applications may have their own mechanism for
securing content as necessary; however, they may find it convenient
to rely on protection provided by messaging associations, since it
runs unbroked between signaling application peers.
8.2 Peer Node Authentication
Cryptographic protection (of confidentiality or integrity) requires a
security association with session keys, which can be established
during an authentication and key exchange protocol run based on
shared secrets, public key techniques or a combination of both.
Authentication and key agreement is possible using the protocols
associated with the messaging association being secured (TLS
incorporates this functionality directly; IKE, IKEv2 or KINK can
provide it for IPsec). GIMPS nodes rely on these protocols to
authenticate the identity of the next hop, and GIMPS has no
authentication capability of its own.
However, with discovery, there are few effective ways to know what is
the legitimate next or previous hop as opposed to an impostor. In
other words, cryptographic authentication here only provides
assurance that a node is 'who' it is (i.e. the legitimate owner of
identity in some namespace), not 'what' it is (i.e. a node which is
genuinely on the flow path and therefore can carry out signaling for
a particular flow). Authentication provides only limited protection,
in that a known peer is unlikely to lie about its role. Additional
methods of protection against this type of attack are considered in
Section 8.3 below.
It is an implementation issue whether peer node authentication should
be made signaling application dependent; for example, whether
successful authentication could be made dependent on presenting
authorisation to act in a particular signaling role (e.g. signaling
for QoS). The abstract API of Appendix D does not specify such
policy and authentication interactions between GIMPS and the NSLP it
is serving. However, it does allow applications to inspect the
authenticated identity of the peer to which a message will be sent
before transmission.
8.3 Routing State Integrity
The internal state in a node (see Section 4.2), specifically the peer
identification, is used to route messages. If this state is
corrupted, signaling messages may be misdirected.
Schulzrinne & Hancock Expires January 19, 2006 [Page 84]
Internet-Draft GIMPS July 2005
In the case where the message routing method is path-coupled, the
messages need to be routed identically to the data flow described by
the Flow Identifier, and the routing state table is the GIMPS view of
how these flows are being routed through the network in the immediate
neighbourhood of the node. Routes are only weakly secured (e.g.
there is usually no cryptographic binding of a flow to a route), and
there is no authoritative information about flow routes other than
the current state of the network itself. Therefore, consistency
between GIMPS and network routing state has to be ensured by directly
interacting with the routing mechanisms to ensure that the signaling
peers are the appropriate ones for any given flow. An overview of
security issues and techniques in this context is provided in [31].
In one direction, peer identification is installed and refreshed only
on receiving a GIMPS-Reponse message (compare Figure 4). This must
echo the cookie from a previous GIMPS-Query message, which will have
been sent along the flow path (in datagram mode, i.e. end-to-end
addressed). Hence, only the true next peer or an on-path attacker
will be able to generate such a message, provided freshness of the
cookie can be checked at the querying node.
In the other direction, peer identification can be installed directly
on receiving a GIMPS-Query message containing addressing information
for the signaling source. However, any node in the network could
generate such a message (indeed, almost any node in the network could
be the genuine upstream peer for a given flow). To protect against
this, three strategies are possible:
Filtering: the receiving node may be able to reject signaling
messages which claim to be for flows with flow source addresses
which would be ruled out by ingress filtering. An extension of
this technique would be for the receiving node to monitor the data
plane and to check explicitly that the flow packets are arriving
over the same interface and if possible from the same link layer
neighbour as the datagram mode signaling packets. (If they are
not, it is likely that at least one of the signaling or flow
packets is being spoofed.) Signaling applications should only
install state on the route taken by the signaling itself.
Authentication (weak or strong): the receiving node may refuse to
install upstream state until it has completed a GIMPS-Confirm
handshaked with the peer. This echoes the response cookie of the
GIMPS-Response, and discourages nodes from using forged source
addresses. A stronger approach is to require full peer
authentication within the messaging association, the reasoning
being that an authenticated peer can be trusted not to pretend
that it is on path when it is not.
Schulzrinne & Hancock Expires January 19, 2006 [Page 85]
Internet-Draft GIMPS July 2005
SID segregation: The routing state lookup for a given MRI and NSLPID
also takes the SID into account. A malicious node can only
overwrite existing routing state if it can guess the corresponding
SID; it can insert state with random SID values, but generally
this will not be used to route messages for which state has
already been legitimately established.
The second technique also plays a role in denial of service
prevention, see below. In practice, a combination of all techniques
may be appropriate.
8.4 Denial of Service Prevention
GIMPS is designed so that in general each Query message only
generates at most one Response, so that a GIMPS node cannot become
the source of a denial of service amplification attack. (There is a
special case of retransmitted Response messages, see Section 5.3.3.)
However, GIMPS can still be subjected to denial-of-service attacks
where an attacker using forged source addresses forces a node to
establish state without return routability, causing a problem similar
to TCP SYN flood attacks. Furthermore, an adversary might use
modified or replayed unprotected signaling messages as part of such
an attack. There are two types of state attacks and one
computational resource attack. In the first state attack, an
attacker floods a node with messages that the node has to store until
it can determine the next hop. If the destination address is chosen
so that there is no GIMPS-capable next hop, the node would accumulate
messages for several seconds until the discovery retransmission
attempt times out. The second type of state-based attack causes
GIMPS state to be established by bogus messages. A related
computational/network-resource attack uses unverified messages to
cause a node to make AAA queries or attempt to cryptographically
verify a digital signature. (RSVP is vulnerable to this type of
attack.) Relying only on upper layer security, for example based on
CMS, might open a larger door for denial of service attacks since the
messages are often only one-shot-transactions which do not use
multiple roundtrips and DoS protection mechanisms.
We use a combination of two defences against these attacks:
1. The responding node need not establish a session or discover its
next hop on receiving the GIMPS-Query message, but can wait for a
GIMPS-Confirm message on a secure channel. If the channel
exists, the additional delay is one one-way delay and the total
is no more than the minimal theoretically possible delay of a
three-way handshake, i.e., 1.5 node-to-node round-trip times.
The delay gets significantly larger if a new connection needs to
Schulzrinne & Hancock Expires January 19, 2006 [Page 86]
Internet-Draft GIMPS July 2005
be established first.
2. The Response to the Query message contains a cookie, which is
repeated in the Confirm. State is only established for messages
that contain a valid cookie. The setup delay is also 1.5 round-
trip times. (This mechanism is similar to that in SCTP [8] and
other modern protocols.)
Once a node has decided to establish routing state, there may still
be transport and security state to be established between peers.
This state setup is also vulnerable to additional denial of service
attacks. GIMPS relies on the lower layer protocols that make up
messaging associations to mitigate such attacks. The current
description assumes that the querying node is always the one wishing
to establish a messaging association, so it is typically the
responding node that needs to be protected.
8.5 Summary of Requirements on Cookie Mechanisms
The requirements on the Query cookie can be summarised as follows:
Liveness: The cookie must be live (must change from one handshake to
the next). To prevent replay attacks.
Unpredictability: The cookie must not be guessable (e.g. not from a
sequence or timestamp). To prevent direct forgery based on seeing
a history of captured messages.
Easily validated: It must be efficient for the Q-Node to validate
that a particular cookie matches an in-progress handshake, for a
routing state machine which already exists. To discard responses
to spoofed queries.
Uniqueness: The cookie must be unique to a given handshake (since it
is actually used to match the Response to a handshake anyway, e.g.
during messaging association re-use).
Likewise, the requirements on the Responder cookie can be summarised
as follows:
Liveness: The cookie must be live (must change from one handshake to
the next). To prevent replay attacks.
Creation simplicity: The cookie must be lightweight to generate. To
avoid resource exhaustion at the responding node.
Schulzrinne & Hancock Expires January 19, 2006 [Page 87]
Internet-Draft GIMPS July 2005
Validation simplicity: It must be simple for the R-node to validate
that an R-cookie was generated by itself (and no-one else),
without storing state about the handshake it was generated for.
Binding: The cookie must be bound to the routing state that will be
installed. To prevent use with different routing state e.g. in a
modified Confirm. The routing state here includes:
The NLI of the Query
The MRI/NSLPID for the messaging
The interface on which the Query was received (probably)
A suitable implementation for the Q-Cookie is a cryptographically
random number which is unique for this routing state machine
handshake.
A suitable implementation for the R-Cookie is as follows:
R-Cookie = liveness data + hash (locally known secret,
Q-Node NLI, MRI, NSLPID,
reception interface,
liveness data)
There are a couple of alternatives for the liveness data. One is to
use a timestamp like SCTP. Another is to use a local secret with
(rapid) rollover, and the liveness data is the generation number of
the secret, like IKEv2. In both cases, the liveness data has to be
carried outside the hash, to allow the hash to be verified at the
Responder. Another approach is to replace the hash with encryption
under a locally known secret, in which case the liveness data does
not need to be carried in the clear. Any symmetric cipher immune to
known plaintext attacks can be used.
8.6 Residual Threats
Taking the above security mechanisms into account, the main residual
threats against NSIS are three types of on-path attack.
An on-path attacker who can intercept the initial Query can do most
things it wants to the subsequent signalling. It is very hard to
protect against this at the GIMPS level; the only defence is to use
strong messaging association security to see whether the Responding
node is authorised to take part in NSLP signalling exchanges. To
some extent, this behaviour is logically indistinguishable from
correct operation, so it is easy to see why defence is difficult.
Note than an on-path attacker of this sort can do anything to the
Schulzrinne & Hancock Expires January 19, 2006 [Page 88]
Internet-Draft GIMPS July 2005
traffic as well as the signalling. Therefore, the additional threat
induced by the signalling weakness seems tolerable.
At the NSLP level, there is a concern about transitivity of trust of
correctness of routing along the signalling chain. The NSLP at the
querying node can have good assurance that it is communicating with
an on-path peer (or a node delegated by the on-path node). However,
it has no assurance that the node beyond the responder is also on-
path, or that the MRI (in particular) is not being modified by the
responder to refer to a different flow. Therefore, if it sends
signalling messages with payloads (e.g. authorisation tokens) which
are "valuable" to nodes beyond the first hop, it is up to the NSLP to
ensure that the appropriate chain of trust exists, which must in
general use messaging association (strong) security.
There is a further residual attack by a node which is not on the path
of the flow, but is on the path of the Response, or is able to use a
Response from one handshake to interfere with another. The attacker
modifies the Response to cause the Querying node to form an adjacency
with it rather than the true downstream node. In principle, this
attack can be prevented by including an additional cryptographic
object in the Response message which ties the Response to the initial
Query and the routing state and can be verified by the Querying node.
Schulzrinne & Hancock Expires January 19, 2006 [Page 89]
Internet-Draft GIMPS July 2005
9. IANA Considerations
This section outlines the content of a future IANA considerations
section.
The GIMPS specification requires the creation of registries, as
follows:
GIMPS Message Type: The GIMPS common header (Appendix C.2) contains a
1 byte message type field (initially distinguishing Query/
Response/Confirm/Data/Error and MA-Hello messages).
NSLP Identifiers: Each signaling application requires one of more
NSLPIDs (different NSLPIDs may be used to distinguish different
classes of signaling node, for example to handle different
aggregation levels or different processing subsets). An NSLPID
must be associated with a unique RAO value; further considerations
are discussed in [34].
Object Types: There is a 12-bit field in the object header
(Appendix C.3.1). Distinguish different ranges for different
allocation styles (standards action, expert review etc.) and
different applicability scopes (experimental/private). When a new
object type is defined, the extensibility bits (A/B, see
Appendix C.3.2) must also be defined.
Extensibility Flags: There are 4 reserved flag bits in the object
header (Appendix C.3.1). These are reserved for the definition of
more complex extensibility encoding schemes.
Message Routing Methods: GIMPS allows the idea of multiple message
routing methods (see Section 3.3). The message routing method is
indicated in the leading 2 bytes of the MRI object
(Appendix C.4.1).
MA-Protocol-IDs: The GIMPS design allows the set of possible
protocols to be used in a messaging association to be extended, as
discussed in Section 5.7. Every new mode of using a protocol is
given a single byte MA-Protcol-ID, which is used as a tag in the
Stack-Proposal and Stack-Configuration-Data objects
(Appendix C.4.4 and Appendix C.4.5). Allocating a new MA-
Protocol-ID requires defining the higher layer addressing
information (if any) in the Stack-Configuration-Data object that
is needed to define its configuration. Note that the
MA-Protocol-ID is not an IP Protocol number (indeed, some of the
possible messaging association protocols - such as TLS - do not
have an IP Protocol number).
Schulzrinne & Hancock Expires January 19, 2006 [Page 90]
Internet-Draft GIMPS July 2005
Error Classes: There is a 1 byte field at the start of the Value
field of the Error object (Appendix C.5.1). Five values for this
field have already been defined. Further general classes of error
could be defined. Note that the value here is primarily to aid
human or management interpretation of otherwise unknown error
codes.
Error Codes/Subcodes: There is a 2 byte error code and 1 byte subcode
in the Value field of the Error object (Appendix C.5.1). When a
new error code is allocated, the Error Class and the format of any
associated error-specific information must also be defined.
Schulzrinne & Hancock Expires January 19, 2006 [Page 91]
Internet-Draft GIMPS July 2005
10. Change History
10.1 Changes In Version -07
1. The open issues section has finally been removed in favour of the
authoritative list of open issues in an online issue tracker at h
ttp://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index.
2. Clarified terminology on peering and adjacencies that there may
be NSIS nodes between GIMPS peers that do some message
processing, but that are not explicitly visible in the peer state
tables.
3. Added a description of the loose-end MRM (Section 5.8.2 and
Appendix C.4.1.2).
4. Added a description of an upstream Query encapsulation for the
path-coupled MRM, Section 5.8.1.3, including rationale for and
restrictions on its use.
5. The formal description of the protocol in Section 6 has been
significantly updated and extended in terms of detail.
6. Modified the description of the interaction between NSLPs and
GIMPS for handling inbound messages for which no routing state
exists, to allow the NSLP to indicate whether state setup should
proceed and to provide NSLP payloads for the Response or
forwarded message (Section 3.5, Section 4.3.2 and Appendix D).
7. Included new text, Section 5.6, on the processing and
encapsulation of error messages. Also added formats and an error
message catalogue in Appendix C.5, including a modified format
for the overall GIMPS-Error message and the GIMPS-Error-Data
object.
8. Removed the old section 5.3.3 on NSLPID/RAO setting on the
assumption that this will be covered in the extensibility
document.
9. Included a number of other minor corrections and clarifications.
10.2 Changes In Version -06
Version -06 does not introduce any major structural changes to the
protocol definition, although it does clarify a number of details and
resolve some outstanding open issues. The primary changes are as
follows:
Schulzrinne & Hancock Expires January 19, 2006 [Page 92]
Internet-Draft GIMPS July 2005
1. Added a new high level Section 3.3 which gathers together the
various aspects of the message routing method concept.
2. Added a new high level Section 3.4 which explains the concept
and significance of the session identifier. Also clarified that
the routing state always depends on the session identifier.
3. Added notes about the level of address validation performed by
GIMPS in Section 4.1.2 and extensions to the API in Appendix D.
4. Split the old Node-Addressing object into a Network-Layer-
Information object and Stack-Configuration-Data object. The
former refers to basic information about a node, and the latter
carries information about messaging association configuration.
Redefined the content of the various handshake messages
accordingly in Section 4.4.1 and Section 5.1.
5. Re-wrote Section 4.4.3 to clarify the rules on refresh and purge
of routing state and messaging associations. Also, moved the
routing state lifetime into the Network-Layer-Information object
and added a messaging association lifetime to the Stack-
Configuration-Data object (Section 5.2).
6. Added specific message types for errors and MA-Refresh in
Section 5.1. The error object is now GIMPS-specific
(Appendix C.5.1).
7. Moved the Flow-Identifier information about the message routing
method from the general description of the object to the path-
coupled MRM section (Section 5.8.1.1), and made a number of
clarifications to the bit format (Appendix C.4.1.1).
8. Removed text about assumptions on the version numbering of
NSLPs, and restricted the scope of the description of TLV objct
formats and extensibility flags to GIMPS rather than the whole
of NSIS (Appendix C).
9. Added a new Section 5.5 explaining the possible relationships
between message types and encapsulation formats.
10. Added a new Section 6 in outline form, to capture the formal
specification of the protocol operation.
11. Added new security sections on cookie requirements (Section 8.5)
and residual threats (Section 8.6).
Schulzrinne & Hancock Expires January 19, 2006 [Page 93]
Internet-Draft GIMPS July 2005
10.3 Changes In Version -05
Version -05 reformulates the specification, to describe routing state
maintenance in terms of exchanging explicitly identified Query/
Response/Confirm messages, leaving the upstream/downstream
distinction as a specific detail of how Query messages are
encapsulated. This necessitated widespread changes in the
specification text, especially Section 4.2.1, Section 4.4,
Section 5.1 and Section 5.3 (although the actual message sequences
are unchanged). A number of other issues, especially in the area of
message encapsulation, have also been closed. The main changes are
the following:
1. Added a reference to [33] as a concrete example of an
alternative message routing method.
2. Added further text (particularly in Section 2) on what GIMPS
means by the concept of 'session'.
3. Firmed up the selection of UDP as the encapsulation choice for
datagram mode, removing the open issue on this topic.
4. Defined the interaction between GIMPS and signaling applications
for communicating about the cryptographic security properties of
how a message will be sent or has been received (see
Section 4.1.2 and Appendix D).
5. Closed the issue on whether Query messages should use the
signaling or flow source address in the IP header; both options
are allowed by local policy and a flag in the common header
indicates which was used. (See Section 5.8.1.2.)
6. Added the necessary information elements to allow the IP hop
count between adjacent GIMPS peers to be measures and reported.
(See Section 5.2.2 and Appendix C.4.3.)
7. The old open-issue text on selection of IP router alert option
values has been moved into the main specification to capture the
technical considerations that should be used in assigning such
values (in old section 5.3.3).
8. Resolved the open issue on lost Confirm messages by allowing a
choice of timer-based retransmission of the Response, or an
error message from the responding node which causes the
retransmission of the Confirm (see Section 5.3.3).
9. Closed the open issue on support for message scoping (this is
now assumed to be a NSLP function).
Schulzrinne & Hancock Expires January 19, 2006 [Page 94]
Internet-Draft GIMPS July 2005
10. Moved the authoritative text for most of the remaining open
issues to an online issue tracker.
10.4 Changes In Version -04
Version -04 includes mainly clarifications of detail and extensions
in particular technical areas, in part to support ongoing
implementation work. The main details are as follows:
1. Substantially updated Section 4, in particular clarifying the
rules on what messages are sent when and with what payloads
during routing and messaging association setup, and also adding
some further text on message transfer attributes.
2. The description of messaging association protocol negotiation
including the related object formats has been centralised in a
new Section 5.7, removing the old Section 6.6 and also closing
old open issues 8.5 and 8.6.
3. Made a number of detailed changes in the message format
definitions (Appendix C), as well as incorporating initial rules
for encoding message extensibility information. Also included
explicit formats for a general purpose Error object, and the
objects used to negotiate messaging association protocols.
Updated the corresponding open issues section (old section 9.3)
with a new item on NSLP versioning.
4. Updated the GIMPS API (Appendix D), including more precision on
message transfer attributes, making the NSLP hint about storing
reverse path state a return value rather than a separate
primitive, and adding a new primitive to allow signaling
applications to invalidate GIMPS routing state. Also, added a
new parameter to SendMessage to allow signaling applications to
'bypass' a message statelessly, preserving the source of an
input message.
5. Added an outline for the future content of an IANA
considerations section (Section 9). Currently, this is
restricted to identifying the registries and allocations
required, without defining the allocation policies and other
considerations involved.
6. Shortened the background design discussion in Section 3.
7. Made some clarifications in the terminology section relating to
how the use of C-mode does and does not mandate the use of
transport or security protection.
Schulzrinne & Hancock Expires January 19, 2006 [Page 95]
Internet-Draft GIMPS July 2005
8. The ABNF for message formats in Section 5.1 has been re-written
with a grammar structured around message purpose rather than
message direction, and additional explanation added to the
information element descriptions in Section 5.2.
9. The description of the datagram mode transport in Section 5.3
has been updated. The encapsulation rules (covering IP
addressing and UDP port allocation) have been corrected, and a
new subsection on message retransmission and rate limiting has
been added, superceding the old open issue on the same subject
(section 8.10).
10. A new open issue on IP TTL measurement to detect non-GIMPS
capable hops has been added (old section 9.5).
10.5 Changes In Version -03
Version -03 includes a number of minor clarifications and extensions
compared to version -02, including more details of the GIMPS API and
messaging association setup and the node addressing object. The full
list of changes is as follows:
1. Added a new section pinning down more formally the interaction
between GIMPS and signaling applications (Section 4.1), in
particular the message transfer attributes that signaling
applications can use to control GIMPS (Section 4.1.2).
2. Added a new open issue identifying where the interaction between
the security properties of GIMPS and the security requirements of
signaling applications should be identified (old section 9.10).
3. Added some more text in Section 4.2.1 to clarify that GIMPS has
the (sole) responsibility for generating the messages that
refresh message routing state.
4. Added more clarifying text and table to GHC and IP TTL handling
discussion of Section 4.3.4.
5. Split Section 4.4 into subsections for different scenarios, and
added more detail on Node-Addressing object content and use to
handle the case where association re-use is possible in
Section 4.4.2.
6. Added strawman object formats for Node-Addressing and Stack-
Proposal objects in Section 5.1 and Appendix C.
Schulzrinne & Hancock Expires January 19, 2006 [Page 96]
Internet-Draft GIMPS July 2005
7. Added more detail on the bundling possibilities and appropriate
configurations for various transport protocols in Section 5.4.1.
8. Included some more details on NAT traversal in Section 7.3,
including a new object to carry the untranslated address-bearing
payloads, the NAT-Traversal object.
9. Expanded the open issue discussion in old section 9.3 to include
an outline set of extensibility flags.
10.6 Changes In Version -02
Version -02 does not represent any radical change in design or
structure from version -01; the emphasis has been on adding details
in some specific areas and incorporation of comments, including early
review comments. The full list of changes is as follows:
1. Added a new Section 1.1 which summarises restrictions on scope
and applicability; some corresponding changes in terminology in
Section 2.
2. Closed the open issue on including explicit GIMPS state teardown
functionality. On balance, it seems that the difficulty of
specifying this correctly (especially taking account of the
security issues in all scenarios) is not matched by the saving
of state enabled.
3. Removed the option of a special class of message transfer for
reliable delivery of a single message. This can be implemented
(inefficiently) as a degenerate case of C-mode if required.
4. Extended Appendix C with a general discussion of rules for
message and object formats across GIMPS and other NSLPs. Some
remaining open issues are noted in old section 9.3 (since
removed).
5. Updated the discussion of RAO/NSLPID relationships to take into
account the proposed message formats and rules for allocation of
NSLP id, and propose considerations for allocation of RAO
values.
6. Modified the description of the information used to route
messages (first given in Section 4.2.1 but also throughout the
document). Previously this was related directly to the flow
identification and described as the Flow-Routing-Information.
Now, this has been renamed Message-Routing-Information, and
identifies a message routing method and any associated
Schulzrinne & Hancock Expires January 19, 2006 [Page 97]
Internet-Draft GIMPS July 2005
addressing.
7. Modified the text in Section 4.3 and elsewhere to impose sanity
checks on the Message-Routing-Information carried in C-mode
messages, including the case where these messages are part of a
GIMPS-Query/Response exchange.
8. Added rules for message forwarding to prevent message looping in
a new Section 4.3.4, including rules on IP TTL and GIMPS hop
count processing. These take into account the new RAO
considerations described above.
9. Added an outline mechanism for messaging association protocol
stack negotiation, with the details in a new Section 6.6 and
other changes in Section 4.4 and the various sections on message
formats.
10. Removed the open issue on whether storing reverse routing state
is mandatory or optional. This is now explicit in the API
(under the control of the local NSLP).
11. Added an informative annex describing an abstract API between
GIMPS and NSLPs in Appendix D.
10.7 Changes In Version -01
The major change in version -01 is the elimination of
'intermediaries', i.e. imposing the constraint that signaling
application peers are also GIMPS peers. This has the consequence
that if a signaling application wishes to use two classes of
signaling transport for a given flow, maybe reaching different
subsets of nodes, it must do so by running different signaling
sessions; and it also means that signaling adaptations for passing
through NATs which are not signaling application aware must be
carried out in datagram mode. On the other hand, it allows the
elimination of significant complexity in the connection mode handling
and also various other protocol features (such as general route
recording).
The full set of changes is as follows:
1. Added a worked example in Section 3.5.
2. Stated that nodes which do not implement the signaling
application should bypass the message (Section 4.3).
Schulzrinne & Hancock Expires January 19, 2006 [Page 98]
Internet-Draft GIMPS July 2005
3. Decoupled the state handling logic for routing state and
messaging association state in Section 4.4. Also, allow
messaging associations to be used immediately in both directions
once they are opened.
4. Added simple ABNF for the various GIMPS message types in a new
Section 5.1, and more details of the common header and each
object in Section 5.2, including bit formats in Appendix C. The
common header format means that the encapsulation is now the
same for all transport types (Section 5.4.1).
5. Added some further details on datagram mode encapsulation in
Section 5.3, including more explanation of why a well known port
is needed.
6. Removed the possibility for fragmentation over DCCP
(Section 5.4.1), mainly in the interests of simplicity and loss
amplification.
7. Removed all the tunnel mode encapsulations (old sections 5.3.3
and 5.3.4).
8. Fully re-wrote the route change handling description
(Section 7.1), including some additional detection mechanisms
and more clearly distinguishing between upstream and downstream
route changes. Included further details on GIMPS/NSLP
interactions, including where notifications are delivered and
how local repair storms could be avoided. Removed old
discussion of propagating notifications through signaling
application unaware nodes (since these are now bypassed
automatically). Added discussion on how to route messages for
local state removal on the old path.
9. Revised discussion of policy-based forwarding (Section 7.2) to
account for actual FLow-Routing-Information definition, and also
how wildcarding should be allowed and handled.
10. Removed old route recording section (old Section 6.3).
11. Extended the discussion of NAT handling (Section 7.3) with an
extended outline on processing rules at a GIMPS-aware NAT and a
pointer to implications for C-mode processing and state
management.
12. Clarified the definition of 'correct routing' of signaling
messages in Section 8 and GIMPS role in enforcing this. Also,
opened the possibility that peer node authentication could be
signaling application dependent.
Schulzrinne & Hancock Expires January 19, 2006 [Page 99]
Internet-Draft GIMPS July 2005
13. Removed old open issues on Connection Mode Encapsulation
(section 8.7); added new open issues on Message Routing (old
Section 9.3 of version -05, later moved to Section 3.3) and
Datagram Mode congestion control.
14. Added this change history.
Schulzrinne & Hancock Expires January 19, 2006 [Page 100]
Internet-Draft GIMPS July 2005
11. References
11.1 Normative References
[1] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[9] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-11 (work in progress), March 2005.
[10] Conta, A., "Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005.
11.2 Informative References
[11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
Schulzrinne & Hancock Expires January 19, 2006 [Page 101]
Internet-Draft GIMPS July 2005
[14] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[15] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[16] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[17] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[18] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003.
[21] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[22] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[23] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[24] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[25] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005.
[26] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
May 2005.
[27] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
Schulzrinne & Hancock Expires January 19, 2006 [Page 102]
Internet-Draft GIMPS July 2005
progress), February 2005.
[28] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in
progress), March 2005.
[29] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[30] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03
(work in progress), June 2005.
[31] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-03 (work in
progress), May 2005.
[32] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
(DSTM)", draft-bound-dstm-exp-03 (work in progress), July 2005.
[33] Stiemerling, M., "Loose End Message Routing Method for NATFW
NSLP", draft-stiemerling-nsis-natfw-mrm-01 (work in progress),
February 2005.
[34] Loughney, J., "NSIS Extensibility Model",
draft-loughney-nsis-ext-00 (work in progress), May 2005.
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
Email: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Schulzrinne & Hancock Expires January 19, 2006 [Page 103]
Internet-Draft GIMPS July 2005
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
Email: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk
Schulzrinne & Hancock Expires January 19, 2006 [Page 104]
Internet-Draft GIMPS July 2005
Appendix A. Acknowledgements
This document is based on the discussions within the IETF NSIS
working group. It has been informed by prior work and formal and
informal inputs from: Cedric Aoun, Attila Bader, Roland Bless, Bob
Braden, Marcus Brunner, Benoit Campedel, Elwyn Davies, Christian
Dickmann, Pasi Eronen, Xiaoming Fu, Ruediger Geib, Eleanor Hepworth,
Cheng Hong, Cornelia Kappler, Georgios Karagiannis, Chris Lang, John
Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew McDonald,
Glenn Morrow, Dave Oran, Andreas Pashaldis, Tom Phelan, Takako Sanda,
Charles Shen, Melinda Shore, Martin Stiemerling, Mike Thomas, Hannes
Tschofenig, Sven van den Bosch, Michael Welzl, and Lars Westberg. In
particular, Hannes Tschofenig provided a detailed set of review
comments on the security section, and Andrew McDonald provided the
formal description for the initial packet formats. Chris Lang's
implementation work provided objective feedback on the clarity and
feasibility of the specification, and he also provided the state
machine description and the initial error catalogue and formats. We
look forward to inputs and comments from many more in the future.
Schulzrinne & Hancock Expires January 19, 2006 [Page 105]
Internet-Draft GIMPS July 2005
Appendix B. Example Message Routing State Table
Figure 10 shows a signaling scenario for a single flow being managed
by two signaling applications using the path-coupled message routing
method. The flow sender and receiver and one router support both,
two other routers support one each.
A B C D E
+------+ +-----+ +-----+ +-----+ +--------+
| Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow |
|Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver|
| | +-+ +-+ |GIMPS| |GIMPS| |GIMPS| | |
+------+ +-----+ +-----+ +-----+ +--------+
------------------------------>>
Flow Direction
Figure 10: A Signaling Scenario
The routing state table at node B is as follows:
+--------------------+----------+----------+----------+-------------+
| Message Routing | Session | NSLP ID | Response | Query |
| Information | ID | | Directio | Direction |
| | | | n | |
+--------------------+----------+----------+----------+-------------+
| Method = Path | 0xABCD | NSLP1 | IP-#A | (null) |
| Coupled; Flow ID = | | | | |
| {IP-#A, IP-#E, | | | | |
| protocol, ports} | | | | |
| | | | | |
| Method = Path | 0x1234 | NSLP2 | IP-#A | Pointer to |
| Coupled; Flow ID = | | | | B-D |
| {IP-#A, IP-#E, | | | | messaging |
| protocol, ports} | | | | association |
+--------------------+----------+----------+----------+-------------+
The Response direction state is just the same address for each
application. For the Query direction, NSLP1 only requires datagram
mode messages and so no explicit routing state towards C is needed.
NSLP2 requires a messaging association for its messages towards node
D, and node C does not process NSLP2 at all, so the peer state for
NSLP2 is a pointer to a messaging association that runs directly from
B to D. Note that E is not visible in the state table (except
implicitly in the address in the message routing information);
routing state is stored only for adjacent peers. (In addition to the
peer identification, IP hop counts are stored for each peer where the
state itself if not null; this is not shown in the table.)
Schulzrinne & Hancock Expires January 19, 2006 [Page 106]
Internet-Draft GIMPS July 2005
Appendix C. Bit-Level Formats and Error Messages
This appendix provides initial formats for the various component
parts of the GIMPS messages defined abstractly in Section 5.2.
C.1 General GIMPS Formatting Guidelines
Each GIMPS message consists of a header and a sequence of objects.
The GIMPS header has a specific format, described in more detail in
Appendix C.2 below. An NSLP message is one object within a GIMPS
message. Note that GIMPS provides the message length information and
signaling application identification.
Every object has the following general format:
o The overall format is Type-Length-Value (in that order).
o Some parts of the type field are set aside for control flags which
define how unknown types should be handled; this is discussed in
Appendix C.3.2.
o Length has the units of 32 bit words, and measures the length of
Value. If there is no Value, Length=0.
o Value is (therefore) a whole number of 32 bit words. If there is
any padding required, the length and location must be defined by
the object-specific format information; objects which contain
variable length (e.g. string) types may need to include additional
length subfields to do so.
o Any part of the object used for padding or defined as reserved
must be set to 0 on transmission and must be ignored on reception.
C.2 The GIMPS Common Header
This header precedes all GIMPS messages. It has a fixed format, as
shown below.
Schulzrinne & Hancock Expires January 19, 2006 [Page 107]
Internet-Draft GIMPS July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIMPS hops | Message length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signaling Application ID | Type |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message length = the total number of words in the message after
the common header itself
Type = the GIMPS message type (Query, Response, etc.)
S flag = set if the IP source address is the signaling
source address, clear if it was derived from the
MRI
R flag = set if a response to this message is explicitly
requested
C.3 General Object Characteristics
C.3.1 TLV Header
Each object begins with a fixed header giving the object type and
object length. The bits marked 'A' and 'B' are extensibility flags
which are defined below; the remaining bits marked 'r' are reserved.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C.3.2 Object Extensibility
The leading two bits of the common TLV header are used to signal the
desired treatment for objects whose treatment has not been defined in
the protocol specification in question (i.e. whose Type field is
unknown at the receiver). The following four categories of object
have been identified, and are loosely described here.
AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it must be rejected with a "Object Type Error"
error message (Appendix C.5.4.10) with subcode 1 ("Unrecognised
Object").
Schulzrinne & Hancock Expires January 19, 2006 [Page 108]
Internet-Draft GIMPS July 2005
AB=01 ("Ignore"): If the object is not understood, it should be
deleted and then the rest of the message processed as usual.
AB=10 ("Forward"): If the object is not understood, it should be
retained unchanged in any message forwarded as a result of message
processing, but not stored locally.
The combination AB=11 is reserved. Note that the concept of
retaining an unknown object and including it in refresh messages
further up or down the signalling path does not apply to GIMPS, since
refresh operations only take place between adjacent peers.
C.4 GIMPS TLV Objects
In the following object diagrams, '//' is used to indicate a variable
sized field and ':' is used to indicate a field that is optionally
present.
C.4.1 Message-Routing-Information
Type: Message-Routing-Information
Length: Variable (depends on message routing method)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Routing-Method | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C.4.1.1 Path-Coupled MRM
In the case of basic path-coupled routing, the addressing information
takes the following format:
Schulzrinne & Hancock Expires January 19, 2006 [Page 109]
Internet-Draft GIMPS July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |P|T|F|S|A|B|D|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix | Dest Prefix | Protocol | DS-field |Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
P - IP Protocol should be interpreted
T - DS-Field should be interpreted; see [5] and [18]
F - Flow Label is present and should be interpreted
S - SPI is present and should be interpreted; see [4]
A/B - Source/Destination Port (see below)
D - Direction of message relative to MRI
The source and destination addresses are always present and of the
same type; their length depends on the value in the IP-Ver field. In
the normal case where the MRI refers only to traffic between specific
host addresses, the Source/Dest Prefix values would both be 32/128
for IPv4/6 respectively.
In the case of IPv6, the Protocol field refers to the true upper
layer protocol carried by the packets, i.e. excluding any IP option
headers. This is therefore not necessarily the same as the Next
Header value from the base IPv6 header.
F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit
word for the FLow Label is absent.
The S/A/B flags can only be set if P is set. The SPI field is only
present if the S flag is set.
If either of A, B is set, the word containing the port numbers is
included in the object. However, the contents of each field is only
significant if the corresponding flag is set; otherwise, the contents
of the field is regarded as padding, and the MRI refers to all ports
(i.e. acts as a wildcard). If the flag is set and Port=0x0000, the
Schulzrinne & Hancock Expires January 19, 2006 [Page 110]
Internet-Draft GIMPS July 2005
MRI will apply to a specific port, whose value is not yet known. If
neither of A or B is set, the word is absent.
The Direction flag has the following meaning: the value 0 means 'in
the same direction as the flow' (or "downstream"), and the value 1
means 'in the opposite direction to the flow' (or "upstream").
C.4.1.2 Loose-End MRM
In the case of the loose-end message routing method, the addressing
information takes the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The only flag defined is:
D - Direction relative to MRI (always 0 for "downstream")
The source and destination addresses are always present and of the
same type; their length depends on the value in the IP-Ver field.
C.4.2 Session Identification
Type: Session-Identification
Length: Fixed (4 32-bit words)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne & Hancock Expires January 19, 2006 [Page 111]
Internet-Draft GIMPS July 2005
C.4.3 Network-Layer-Information
Type: Network-Layer-Information
Length: Variable (depends on length of Peer-Identity and IP version)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PI-Length | IP-TTL |IP-Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing State Validity Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Identity //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing State Validity Time = the time for which the routing state
for this flow can be considered correct without a
refresh. Given in milliseconds.
PI-Length = the byte length of the Peer-Identity field
(note that the Peer-Identity field itself is padded
to a whole number of words)
IP-TTL = initial or reported IP-TTL
IP-Ver = the IP version for the Interface-Address field
C.4.4 Stack Proposal
Type: Stack-Proposal
Length: Variable (depends on number of profiles and size of each
profile)
Schulzrinne & Hancock Expires January 19, 2006 [Page 112]
Internet-Draft GIMPS July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 2 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count = The number of profiles in the proposal
Each profile is itself a sequence of protocol layers, and the profile
is formatted as a list as follows:
o The first byte is a count of the number of layers in the profile.
o This is followed by a sequence of 1-byte MA-Protocol-IDs as
described in Section 5.7.
o The profile is padded to a word boundary with 0, 1, 2 or 3 zero
bytes.
C.4.5 Stack-Configuration-Data
Type: Stack-Configuration-Data
Length: Variable (depends on number of protocols and size of each
protocol configuration data)
Schulzrinne & Hancock Expires January 19, 2006 [Page 113]
Internet-Draft GIMPS July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HL-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MA-Hold-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Higher-Layer-Information 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Higher-Layer-Information N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Hold-Time = the time for which the messaging association will
be held open without traffic or a hello message.
Given in milliseconds.
HL-Count = the number of higher-layer-information fields
(these contain their own length information)
The higher layer information fields are formatted as follows:
o There is a 1-byte MA-Protocol-ID, as described in Section 5.7.
o There is a 1-byte length field defining the amount of
configuration data that follows after the length field.
o There is a variable length of configuration data.
o There are 0, 1, 2, or 3 bytes of zero padding to the next word
boundary.
Note that the contents of the configuration data may differ depending
on whether the object is in a GIMPS-Query or GIMPS-Response.
C.4.6 Query Cookie
Type: Query-Cookie
Length: Variable (selected by querying node)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Query Cookie //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne & Hancock Expires January 19, 2006 [Page 114]
Internet-Draft GIMPS July 2005
The contents are implementation defined. See Section 8.5 for further
discussion.
C.4.7 Responder Cookie
Type: Responder-Cookie
Length: Variable (selected by responding node)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Responder Cookie //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents are implementation defined. See Section 8.5 for further
discussion.
C.4.8 NAT Traversal
Type: NAT-Traversal
Length: Variable (depends on length of contained fields)
This object is used to support the NAT traversal mechanisms described
in Section 7.3.
Schulzrinne & Hancock Expires January 19, 2006 [Page 115]
Internet-Draft GIMPS July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRI-Length | Type-Count | NAT-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Original Message-Routing-Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// List of translated objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque NLI info. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// NLI information replaced by NAT #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque NLI info. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// NLI information replaced by NAT #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRI-Length = the word length of the included MRI payload
Type-Count = the number of GIMPS payloads translated by the
NAT; the Type numbers are included as a list
(padded with 2 null bytes if necessary)
NAT-Count = the number of NATs traversed by the message, and the
number of opaque NLI-related payloads at the end
of the object
C.4.9 NSLP Data
Type: NSLP-Data
Length: Variable (depends on NSLP)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// NSLP Data //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C.5 Errors
Schulzrinne & Hancock Expires January 19, 2006 [Page 116]
Internet-Draft GIMPS July 2005
C.5.1 Error Object
Type: Error
Length: Variable (depends on error)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M|C|D|Q| Reserved | MRI Length | Info Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Common Header +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session Id +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Message Routing Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Additional Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Debugging Comment //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
S - Session ID object present
M - MRI object present
C - Debug Comment present after header.
D - Original message was received in D-Mode
Q - Original message was received Q-Mode encapsulated
(can't be set if D=0).
A GIMPS Error object contains an error-class (see Appendix C.5.3), an
error-code, an error-subcode, and as much information about the
message which triggered the error as is available. This information
must include the Common header of the original message and should
also include the Session Id and MRI objects if these could be decoded
correctlty. These objects are included in their entirety, except for
the TLV Header.
Schulzrinne & Hancock Expires January 19, 2006 [Page 117]
Internet-Draft GIMPS July 2005
The Info Count field contains the number of Additional Information
fields in the object. This count is usually 1, but may be more for
certain messages; the precise set of fields to include is defined
with the error code/subcode. The field formats are given in
Appendix C.5.2 and their use for the different errors is given in the
error catalogue Appendix C.5.4. The Debugging Comment is a null-
terminated UTF-8 string, padded if necessary to a whole number of 32-
bit words with more null characters.
C.5.2 Additional Information Fields
The Common Header may optionally be followed by some Additional
Information objects. The possible formats of these objects are shown
below.
Message Length Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calculated Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calculated Length = the length of the original message calculated
by adding up all the objects in the message.
MTU Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object provides information about the MTU for a link along
which a message could not be sent.
Object Type Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object provides information about the type of object which
caused the error.
Schulzrinne & Hancock Expires January 19, 2006 [Page 118]
Internet-Draft GIMPS July 2005
Object Value Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Real Object Length: Since the length in the original TLV header
may be inaccurate, this field provides the actual
length of the object (including the TLV Header)
included in the error message.
Offset: The byte in the object at which the GIMPS node
found the error.
Object: The invalid TLV object (including the TLV Header)
This object carries information about a TLV object which was found
to be invalid in the original message. An error message may contain
more than one Object Value Info object.
C.5.3 Error Classes
The first byte of the error object, "Error Class", indicates the
severity level. The currently defined severity levels are:
Informational: response data which should not be thought of as
changing the condition of the protocol state machine.
Success: response data which indicates that the message being
responded to has been processed successfully in some sense.
Protocol-Error: the message has been rejected because of a protocol
error (e.g. an error in message format).
Transient-Failure: the message has been rejected because of a
particular local node status which may be transient (i.e. it may
be worthwhile to retry after some delay).
Permanent-Failure: the message has been rejected because of local
node status which will not change without additional out of band
(e.g. management) operations.
Additional error class values are reserved.
The allocation of error classes to particular errors is not precise;
Schulzrinne & Hancock Expires January 19, 2006 [Page 119]
Internet-Draft GIMPS July 2005
the above descriptions are deliberately informal. Actually error
processing should take into account the specific error in question;
the error class may be useful supporting information (e.g. in network
debugging).
C.5.4 Error Catalogue
This section lists all the possible GIMPS errors, including when they
are raised and what additiona information fields should be carried in
the error object.
C.5.4.1 Unrecognised Message Type
Class: Protocol-Error
Code: 0
Additional Info: None
This message is sent if a GIMPS node receives a message of an
unrecognised type. Note that in this case the original MRI and
Session ID are not included in the Error Object.
C.5.4.2 Incorrect Message Length
Class: Protocol-Error
Code: 1
Additional Info: Message Length Info
This message is sent if a GIMPS node receives a message containing a
common header with an incorrect message length field. The message
includes a single Message Length Info object containing the
calculated length of the message. Note that in this case the
original MRI and Session ID are not included in the Error Object.
C.5.4.3 Hop Limit Exceeded
Class: Permanent-Failure
Code: 2
Additional Info: None
This message is sent if a GIMPS node receives a message with a GIMPS
Hop Limit of zero, or a GIMPS node decrements a packet's GIMPS Hop
Limit to zero. This message indicates either a routing loop or too
small an initial Hop Limit value.
C.5.4.4 Incorrect Encapsulation
Class: Protocol-Error
Code: 3
Schulzrinne & Hancock Expires January 19, 2006 [Page 120]
Internet-Draft GIMPS July 2005
Additional Info: None
This message is sent if a GIMPS node receives a message which uses an
incorrect encapsulation method (e.g. a Query arrives over an MA).
C.5.4.5 Incorrectly Delivered Message
Class: Protocol-Error
Code: 4
Additional Info: None
This message is sent if a GIMPS node receives a message over an MA
which is not associated with the MRI/NSLPID/SID combination in the
message.
C.5.4.6 No Routing State
Class: Protocol-Error
Code: 5
Additional Info: None
This message is sent if a node receives a message for which there is
no matching routing state (and therefore no appropriate Q/R-SM).
This can occur either at a Querying node which receives an unexpected
Response message, or at a Responding node which receives an
unexpected Data message.
C.5.4.7 Unknown NSLPID
Class: Permanent-Failure
Code: 6
Additional Info: None
This message is sent if a router receives a directly addressed
message for an NSLP which it does not support.
C.5.4.8 Endpoint Found
Class: Informational
Code: 7
Additional Info: None
This message is sent if a GIMPS node at a flow endpoint receives a
message for an NSLP which it does not support.
C.5.4.9 Message Too Large
Schulzrinne & Hancock Expires January 19, 2006 [Page 121]
Internet-Draft GIMPS July 2005
Class: Permanent-Failure
Code: 8
Additional Info: MTU Info
A router receives a message which it can't forward because it exceeds
the next hop MTU.
C.5.4.10 Object Type Error
Class: Protocol-Error
Code: 9
Additional Info: Object Type Info
This message is sent if a GIMPS node receives a message containing a
TLV object with an incorrect header. The message includes the type
of the object at fault. This error code is split into subcodes as
follows:
0: Duplicate Object: This subcode is used if a GIMPS node receives a
message containing multiple instances of an object which may only
appear once in a message (in the current specification this
applies to all objects).
1: Unrecognised Object: If a GIMP node receives a message containing
an object which it does not recognise it must examine the objects
A & B flags. This subcode is used if the A & B flags are both
zero. Note that this error is unlikely to be received in response
to a Data message. This is a pathological case.
2: Missing Object: This subcode is used if a GIMPS node receives a
message which is missing one or more mandatory objects. This
message is also sent if a Stack Proposal is sent without a
matching Stack Configuration Data object, or vice versa.
C.5.4.11 Object Value Error
Class: Protocol-Error
Code: 10
Additional Info: Object Value Info
This message is sent if a router receives a packet containing an
object which cannot be properly parsed. The message contains a
single Object Value Info object, unless otherwise stated below. This
error code is split into subcodes as follows:
Schulzrinne & Hancock Expires January 19, 2006 [Page 122]
Internet-Draft GIMPS July 2005
0: Incorrect Length: The overall length does not match the object
length calculated from the object contents.
1: Value Not Supported: The value of a field is not supported by the
GIMPS node.
2: Invalid Flag-Field Combination: An object contains an invalid
combination of flags and/or fields. At the moment this only
relates to the Path-Coupled MRM object, but in future there may be
more.
3: Empty List: At the moment this only relates to Stack proposal
Profiles. The error message is sent if a stack proposal with a
length > 0 (a length of 0 is not a supported value) contains only
null bytes.
4: Invalid Cookie: The message contains a cookie which could not be
verified by the node.
5: SP-SCD Mismatch: This subcode is used if a GIMPS node receives a
message in which the data in the Stack Proposal object is
inconsistent with the information in the Stack Configuration Data
object. In this case, both the Stack Proposal object and Stack
Configuration Data object are included in the message, in separate
Object Value Info fields.
C.5.4.12 Invalid IP TTL
Class: Permanent-Failure
Code: 11
Additional Info: None
This error indicates that a message was received with an IP-TTL
outside an acceptable range; for example, that an upstream Query was
received with an IP-TTL of less than 254 (i.e. more than one IP hop
from the sender). The actual IP distance can be derived from the IP-
TTL information in the NLI object carried in the same message.
C.5.4.13 MRI Too Wild
Class: Permanent-Failure
Code: 12
Additional Info: Object Value Info
This error indicates that a message was received with an MRI that
contained too much wildcarding (e.g. too short a destination address
prefix) to be forwarded correctly down a single path).
Schulzrinne & Hancock Expires January 19, 2006 [Page 123]
Internet-Draft GIMPS July 2005
Appendix D. API between GIMPS and NSLP
D.1 API Concepts
This appendix provides an initial abstract API between GIMPS and
NSLPs.
This does not constrain implementors, but rather helps clarify the
interface between the different layers of the NSIS protocol suite.
In addition, although some of the data types carry the information
from GIMPS Information Elements, this does not imply that the format
of that data as sent over the API has to be the same.
Conceptually the API has similarities to the UDP sockets API,
particularly that for unconnected UDP sockets. An extension for an
API like that for UDP connected sockets could be considered. In this
case, for example, the only information needed in a SendMessage
primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle
(which can be null). Other information which was persistent for a
group of messages could be configured once for the socket. Such
extensions may make a concrete implementation more scalable and
efficient but do not change the API semantics, and so are not
considered further here.
D.2 SendMessage
This primitive is passed from an NSLP to GIMPS. It is used whenever
the NSLP wants to initiate sending a message.
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
NSLP-Id, Session-ID, MRI,
SII-Handle, Transfer-Attributes, Timeout, IP-TTL )
The following arguments are mandatory.
NSLP-Data: The NSLP message itself.
NSLP-Data-Size: The length of NSLP-Data.
NSLP-Message-Handle: A handle for this message, that can be used
later by GIMPS to reference it in status reports (in particular,
notification about what security attributes will be used for the
message, or error notifications). A NULL handle may be supplied
if the NSLP is not interested in receiving MessageStatus
notifications for this message.
Schulzrinne & Hancock Expires January 19, 2006 [Page 124]
Internet-Draft GIMPS July 2005
NSLP-Id: An identifier indicating which NSLP this is.
Session-ID: The NSIS session identifier. Note that it is assumed
that the signaling application provides this to GIMPS rather than
GIMPS providing a value itself.
MRI: Message routing information for use by GIMPS in determining the
correct next GIMPS hop for this message. It contains, for
example, the flow source/destination addresses and the type of
routing to use for the signaling message. The message routing
information implies the message routing method to be used and also
includes the direction of the message.
The following arguments are optional.
SII-Handle: A handle, previously supplied by GIMPS, to a data
structure (identifying peer addresses and interfaces) that should
be used to explicitly route the message to a particular GIMPS next
hop. If supplied, GIMPS should validate that it is consistent
with the MRI.
Transfer-Attributes: Attributes defining how the message should be
handled (see Section 4.1.2). The following attributes can be
considered:
Reliability: Values 'unreliable' (default) or 'reliable'.
Security: This attribute allows the NSLP to specify what level of
security protection is requested for the message (selected from
'integrity' and 'confidentiality'), and can also be used to
specify what authenticated signaling source and destination
identities should be used to send the message. The
possibilities can be learned by the NSLP from prior
MessageStatus or RecvMessage notifications. If an NSLP-
Message-Handle is provided, GIMPS will inform the NSLP of what
values it has actually chosen for this attribute via a
MessageStatus callback. This might take place either
synchronously (where GIMPS is just selecting from available
messaging associations), or asynchronously (when a new
messaging association needs to be created).
Local Processing: This attribute contains hints from the NSLP
about what local policy should be applied to the message; in
particular, its transmission priority relative to other
messages, or whether GIMPS should attempt to set up or maintain
forward routing state.
Schulzrinne & Hancock Expires January 19, 2006 [Page 125]
Internet-Draft GIMPS July 2005
Timeout: Length of time GIMPS should attempt to send this message
before indicating an error.
IP-TTL: The value of the IP TTL that should be used when sending this
message (may be overridden by GIMPS policy for particular
messages).
D.3 RecvMessage
This primitive is passed from GIMPS to an NSLP. It is used whenever
GIMPS receives a message from the network. This primitive can return
a value from the NSLP which indicates whether the NSLP wishes GIMPS
to retain message routing state.
RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Id, Session-ID, MRI,
Adjacency-Check,
SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance )
NSLP-Data: The NSLP message itself (may be empty).
NSLP-Data-Size: The length of NSLP-Data (may be zero).
NSLP-Id: An identifier indicating which NSLP this is message is for.
Session-ID: The NSIS session identifier.
MRI: Message routing information that was used by GIMPS in forwarding
this message. It contains, for example, the flow source/
destination addresses, the type of routing used for the signaling
message, and the direction of the message relative to the MRI.
Implicitly defines the message routing method that was used.
Adjacency-Check: This boolean is True if GIMPS is checking with the
NSLP to see if a signaling adjacency should be formed (see
Section 4.3.2). If True, the signaling application should return
the following values via the RecvMessage call:
A boolean to indicate whether or not the adjacency should be
formed.
Optionally, an NSLP-Payload to carry in a generated GIMPS-
Response or forwarded Query/Data message respectively.
Schulzrinne & Hancock Expires January 19, 2006 [Page 126]
Internet-Draft GIMPS July 2005
SII-Handle: A handle to a data structure, identifying peer addresses
and interfaces. Can be used to identify route changes and for
explicit routing to a particular GIMPS next hop.
Transfer-Attributes: The reliability and security attributes that
were associated with the reception of this particular message. As
well as the attributes associated with SendMessage, GIMPS may
indicate the level of verification of the addresses in the MRI.
Two flags can be indicated:
* Whether the signalling source address is one of the flow
endpoints (i.e. whether this is the first or last GIMPS hop);
* Whether the signalling source address has been validated by a
return routability check.
IP-TTL: The value of the IP TTL (or Hop Limit) this message was
received with (if available).
IP-Distance: The number of IP hops from the peer signaling node which
sent this message along the path, or 0 if this information is not
available.
D.4 MessageStatus
This primitive is passed from GIMPS to an NSLP. It is used to notify
the NSLP that a message that it requested to be sent could not be
dispatched, or to inform the NSLP about the transfer attributes that
have been selected for the message (specifically, security
attributes). The NSLP can respond to this message with a return code
to abort the sending of the message if the attributes are not
acceptable.
MessageStatus (NSLP-Message-Handle, Transfer-Attributes, Error-Type)
NSLP-Message-Handle: A handle for the message provided by the NSLP at
the time of sending.
Transfer-Attributes: The reliability and security attributes that
will be used to transmit this particular message.
Error-Type: Indicates the type of error that occurred. For example,
'no next node found'.
Schulzrinne & Hancock Expires January 19, 2006 [Page 127]
Internet-Draft GIMPS July 2005
D.5 NetworkNotification
This primitive is passed from GIMPS to an NSLP. It indicates that a
network event of possible interest to the NSLP occurred.
NetworkNotification ( MRI, Network-Notification-Type )
MRI: Provides the message routing information to which the network
notification applies.
Network-Notification-Type: Indicates the type of event that caused
the notification, e.g. downstream route change, upstream route
change, detection that this is the last node.
D.6 SetStateLifetime
This primitive is passed from an NSLP to GIMPS. It indicates the
lifetime for which GIMPS should retain its routing state. It can
also give a hint that the NSLP is no longer interested in the state.
SetStateLifetime ( MRI, Direction, State-Lifetime )
MRI: Provides the message routing information to which the routing
state lifetime applies.
Direction: A flag indicating whether this relates to state for the
upstream or downstream direction (in relation to the MRI).
State-Lifetime: Indicates the lifetime for which the NSLP wishes
GIMPS to retain its routing state (may be zero, indicating that
the NSLP has no further interest in the GIMPS state).
D.7 InvalidateRoutingState
This primitive is passed from an NSLP to GIMPS. It indicates that
the NSLP has knowledge that the next signaling hop known to GIMPS may
no longer be valid, either because of changes in the network routing
or the processing capabilities of NSLP nodes. It is an indication to
GIMPS to restart the discovery process.
InvalidateRoutingState ( NSLP-Id, MRI, Direction, Urgency )
Schulzrinne & Hancock Expires January 19, 2006 [Page 128]
Internet-Draft GIMPS July 2005
NSLP-Id: The NSLP originating the message. May be null (in which
case the invalidation applies to all signaling applications).
MRI: The flow for which routing state should be invalidated.
Direction: A flag indicating whether this relates to state for the
upstream or downstream direction (in relation to the MRI).
Urgency: A hint as to whether rediscovery should take place
immediately, or only when the next signaling message is to be
sent.
Schulzrinne & Hancock Expires January 19, 2006 [Page 129]
Internet-Draft GIMPS July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne & Hancock Expires January 19, 2006 [Page 130]
