Next Steps in Signaling H. Schulzrinne
Internet-Draft Columbia U.
Expires: April 19, 2004 R. Hancock
Siemens/RMR
October 20, 2003
GIMPS: General Internet Messaging Protocol for Signaling
draft-ietf-nsis-ntlp-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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 solution uses existing transport and
security protocols under a common messaging layer, the Generic
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 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 protocols provides a solution for the base protocol
component of the "Next Steps in Signaling" framework.
Schulzrinne & Hancock Expires April 19, 2004 [Page 1]
Internet-Draft GIMPS October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . 4
3. Design Methodology . . . . . . . . . . . . . . . . . . . . . 6
3.1 Overall Approach . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Design Attributes . . . . . . . . . . . . . . . . . . . . . 8
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 10
4.1 GIMPS State . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Basic Message Processing . . . . . . . . . . . . . . . . . . 12
4.3 Routing State and Messaging Association Maintainance . . . . 15
5. Message Formats and Encapsulations . . . . . . . . . . . . . 19
5.1 Message Formats . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Encapsulation in Datagram Mode . . . . . . . . . . . . . . . 20
5.3 Encapsulation Options in Connection Mode . . . . . . . . . . 20
6. Advanced Protocol Features . . . . . . . . . . . . . . . . . 28
6.1 Route Changes . . . . . . . . . . . . . . . . . . . . . . . 28
6.2 Policy-Based Forwarding . . . . . . . . . . . . . . . . . . 31
6.3 Route Recording . . . . . . . . . . . . . . . . . . . . . . 32
6.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 32
6.5 Interaction with IP Tunnelling . . . . . . . . . . . . . . . 33
6.6 IPv4-IPv6 Transition and Interworking . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . 36
7.1 Message Confidentiality and Integrity . . . . . . . . . . . 36
7.2 Peer Node Authentication . . . . . . . . . . . . . . . . . . 37
7.3 Routing State Integrity . . . . . . . . . . . . . . . . . . 37
7.4 Denial of Service Prevention . . . . . . . . . . . . . . . . 38
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1 Protocol Naming . . . . . . . . . . . . . . . . . . . . . . 40
8.2 General IP Layer Issues . . . . . . . . . . . . . . . . . . 40
8.3 Encapsulation and Addressing for Datagram Mode . . . . . . . 40
8.4 Intermediate Node Bypass and Router Alert Values . . . . . . 42
8.5 Messaging Association Flexibility . . . . . . . . . . . . . 43
8.6 Messaging Association Setup Message Sequences . . . . . . . 43
8.7 Connection Mode Encapsulation . . . . . . . . . . . . . . . 45
8.8 GIMPS State Teardown . . . . . . . . . . . . . . . . . . . . 45
8.9 Datagram Mode Retries and Single Shot Message Support . . . 45
8.10 GIMPS Support for Message Scoping . . . . . . . . . . . . . 46
8.11 Mandatory or Optional Reverse Routing State . . . . . . . . 46
8.12 Additional Discovery Mechanisms . . . . . . . . . . . . . . 47
8.13 Protocol Design Details . . . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . 49
Informative References . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
B. Example Routing State Table . . . . . . . . . . . . . . . . 53
C. Connection Mode Messaging Association Configurations . . . . 54
Intellectual Property and Copyright Statements . . . . . . . 55
Schulzrinne & Hancock Expires April 19, 2004 [Page 2]
Internet-Draft GIMPS October 2003
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.
The case of path-coupled signaling involves network elements which
are located on the path taken by a particular data flow, possibly
including but not limited to the flow endpoints. Indeed, there are
almost always more than two participants in a path-coupled-signaling
session, although there is no need for every router on the path to
participate. Path-coupled signaling thus excludes end-to-end
higher-layer application signaling (except as a degenerate case); an
example of such application signaling would be 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 involves 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 applications, and hence should be developed as a common
standard. The framework given in [18] 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 Generic Internet Messaging Protocol for
Signaling (GIMPS). Different signaling applications may make use of
different services provided by GIMPS, but GIMPS does not handle
signaling application state itself; in that crucial respect, it
differs from application signaling protocols such as the control
component of FTP, SIP and RTSP. Instead, GIMPS manages its own
internal state and the configuration of the underlying transport and
security protocols to ensure the transfer of signaling messages on
behalf of signaling applications in both directions along the flow
path.
Schulzrinne & Hancock Expires April 19, 2004 [Page 3]
Internet-Draft GIMPS October 2003
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.
GIMPS (adjacent) peer nodes
IP addresses = Signaling
IP address Source/Destination Addresses IP address
= Flow (depending on signaling direction) = Flow
Source | | Destination
Address | | Address
V V
+--------+ Data +------+ +------+ +--------+
| Flow |-----------|------|-------------|------|-------->| Flow |
| Sender | Flow | | | | |Receiver|
+--------+ |GIMPS |============>|GIMPS | +--------+
| Node |<============| Node |
+------+ Signaling +------+
Flow
>>>>>>>>>>>>>>>>> = Downstream direction
<<<<<<<<<<<<<<<<< = Upstream direction
Figure 1: Basic Terminology
[Data] Flow: A set of packets following a unique path through the
network, identified by some fixed combination of header fields.
Only unicast, unidirectional flows are considered.
Session: A single application layer flow of information for which
some network control state information is to be manipulated or
monitored. IP mobility may cause the mapping between sessions and
flows to change, and IP multihoming may mean there is more than
one flow for a given session.
[Flow] Sender: The node in the network which is the source of the
packets in a flow. Could be a host or a router (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 April 19, 2004 [Page 4]
Internet-Draft GIMPS October 2003
Downstream: In the same direction as the data flow.
Upstream: In the opposite direction to the data flow.
GIMPS Node: Any node along the data path supporting GIMPS (regardless
of what signaling applications it supports).
Adjacent peer: The next GIMPS node along the data path, in the
upstream or downstream direction. Whether two nodes are adjacent
or not is determined implicitly by the GIMPS peer discovery
mechanisms; it is possible for adjacencies to 'skip over'
intermediate nodes if they have no interest in the signaling
messages being exchanged.
Datagram mode: A mode of sending GIMPS messages between nodes without
using any transport layer state or security protection. Upstream
messages are sent UDP encapsulated directly to the signaling
destination; downstream messages are sent towards the flow
receiver with a router alert option.
Connection mode: A mode of sending GIMPS messages directly between
nodes using point to point transport protocols and security
associations, i.e. messaging associations (see below).
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 uses a
specific transport protocol and known ports, and may be run over
specific network layer security associations, or use a transport
layer security association internally. A messaging association is
bidirectional.
Schulzrinne & Hancock Expires April 19, 2004 [Page 5]
Internet-Draft GIMPS October 2003
3. Design Methodology
3.1 Overall Approach
The generic requirements identified in [18] for transport of
path-coupled signaling messages are essentially two-fold:
"Routing": Determine how to reach the adjacent signaling node along
the data path (the GIMPS peer);
"Transport": Deliver the signaling information to that peer.
To meet the routing requirement, for downstream signaling the node
can either use local state information (e.g. gathered during previous
signaling exchanges) to determine the identity of the GIMPS peer
explicitly, or it can just send the signaling towards the flow
destination address and rely on the peer to intercept it. For
upstream signaling, only the first technique is possible.
Once the routing decision has been made, the node has to select a
mechanism for transport of the message to the peer. GIMPS divides the
transport problems into two categories, the easy and the difficult
ones. It handles the easy cases within GIMPS itself, avoiding
complexity and latency, while drawing on the services of
well-understood reliable transport protocols for the harder cases.
Here, with details discussed later, "easy" messages are those that
are sized well below the lowest MTU along a path, are infrequent
enough not to cause concerns about congestion and flow control, and
do not need transport or network-layer security support.
In addition, in many cases, signaling information needs to be
delivered reliably between GIMPS peers. Some applications may
implement their own reliability mechanism, but experience with RSVP
has shown [12] that relying on soft-state refreshes itself may yield
unsatisfactory performance if signaling messages are lost even
occasionally. The provision of this type of reliability is also the
responsibility of the underlying transport protocols.
In [18] 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 protocols, as shown in Figure
2.
Schulzrinne & Hancock Expires April 19, 2004 [Page 6]
Internet-Draft GIMPS October 2003
^^ +-------------+
|| | Signaling |
|| +------------|Application 2|
|| | Signaling +-------------+
NSIS |Application 1| |
Signaling +-------------+ |
Application | +-------------+ |
Level | | Signaling | |
|| | |Application 3| |
|| | +-------------+ |
VV | | |
=======================|==========|========|=======================
^^ +----------------------------------------------+
|| |+-----------------------+ +------------+ |
|| || GIMPS | | GIMPS | |
|| || Encapsulation |<<<>>>|Maintainance| |
NSIS |+-----------------------+ +------------+ |
Transport |GIMPS: messaging layer |
Level +----------------------------------------------+
("NTLP") | | | |
|| +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP|....
VV +----+ +----+ +----+ +----+
===========================|=======|=======|=======|===============
| | | |
+----------------------------------------------+
| IP |
+----------------------------------------------+
Figure 2: Protocol Stacks for Signaling Transport
For efficiency, GIMPS offers two modes of transport operation:
Datagram mode: for small, infrequent messages with modest delay
constraints;
Connection mode: for larger data objects or where fast setup in the
face of packet loss is desirable, or where channel security is
required.
The datagram mode uses a lower-layer unreliable unsecured datagram
transport mechanism, with UDP as the initial choice. The connection
mode can use any stream or message-oriented transport protocol,
including TCP and SCTP. It may employ specific network layer security
associations (using IPsec), or an internal transport layer security
association (using TLS).
It is possible to combine these two modes along a chain of nodes,
Schulzrinne & Hancock Expires April 19, 2004 [Page 7]
Internet-Draft GIMPS October 2003
without coordination or manual configuration. This allows, for
example, the use of datagram mode at the edges of the network and
connection mode in the core of the network. Such combinations may
make operation more efficient for mobile endpoints, while allowing
multiplexing of signaling messages across shared security
associations and transport connections between core routers.
It must be understood that the routing and transport decisions made
by GIMPS are not totally independent. If the message transfer has
performance requirements that enforce the use of connection mode
(e.g. because fragmentation is required), this can only be used
between explicitly identified nodes. In such cases, the GIMPS node
must carry out signaling in datagram mode to identify the peer node
and set up the necessary transport connection - even for downstream
signaling, the datagram mode option of sending the message in the
direction of the flow receiver and relying on interception is not
available.
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 managment
actions within the GIMPS layer itself.
3.2 Design Attributes
Soft state: All parts of GIMPS state are subject to time-out
("soft-state"). Explicit removal is also logically possible (see
Section 8.8. 'State' here includes the transport associations
managed by GIMPS.
Application-neutral: GIMPS is designed to support the largest range
of signaling applications. While a number of such applications
have been identified, it appears likely that new applications will
emerge. (This was the case after the development of RSVP, for
example.)
Mobility support: End systems can change their network attachment
point and network address during a session. GIMPS minimises the
use of IP addresses as identifiers for non-topological information
(e.g. authentication state).
Efficient: Signaling often occurs before an application such as an IP
telephone conversation can commence, so that any signaling delay
becomes noticeable to the application. Signaling delays are
incurred by the delay in finding signaling nodes along the path
Schulzrinne & Hancock Expires April 19, 2004 [Page 8]
Internet-Draft GIMPS October 2003
(peer discovery), in retransmitting lost signaling messages and in
setting up security associations between nodes, among other
factors. GIMPS attempts to minimise these delays by several
mechanisms, such as the use of high performance transport
protocols to circumvent message loss, and the re-use of messaging
associations to avoid setup latency. If discovery is needed it is
a lightweight process which only probes local topology, and GIMPS
also allows it to be bypassed completely for downstream datagram
mode messages.
IP version neutral: GIMPS supports both IPv4 and IPv6: it can use
either for transport, largely as a result of their support in the
underlying transport protocols, and can signal for either type of
flow. In addition, GIMPS is able to operate on dual-stack nodes
(to bridge between v4 and v6 regions) and also to operate across
v4/v6 boundaries and other addressing boundaries. Specific
transition issues are considered in Section 6.6.
Transport neutral: GIMPS can operate over any message or
stream-oriented transport layer, including UDP, DCCP, TCP and
SCTP. Messages sent over protocols that do not offer a native
fragmentation service, such as UDP, are strictly limited in size
and rate to avoid network congestion and loss-amplification
problems.
Proxy support: The end systems in a session may not be capable of
handling either the signaling transport or the application and may
instead rely on proxies to initiate and terminate signaling
sessions. GIMPS decouples the operation of the messaging functions
from the flow source and destination addresses, treating these
primarily as data.
Scaleable: As will be discussed in Section 4.3, up to one messaging
association is generally kept for each next-hop node and thus
transport state scales better than the number of sessions. (Many
next-hops may not have transport state at all, if there are no
messages on sessions visiting those nodes that warrant such
treatment.) Transport associations are removed based on policy at
each node, depending on trade-offs between fast peer-to-peer
communication and state overhead. In short, transport state can be
removed immediately after the last signaling session to a
particular next-hop is removed, after some delay to wait for new
sessions or only if resource demands warrant it.
Schulzrinne & Hancock Expires April 19, 2004 [Page 9]
Internet-Draft GIMPS October 2003
4. Overview of Operation
This section describes the basic structure and operation of GIMPS. It
is divided into three parts. Section 4.1 gives an overview of the
per-flow and per-peer state that GIMPS maintains for the purpose of
routing messages. Section 4.2 describes how messages are processed in
the case where any necessary messaging associations and associated
routing state already exist; this includes the simple scenario of
pure datagram mode operation, where no messaging associations are
necessary in the first place (equivalent to the transport
functionality of base RSVP as defined in [8].) Section 4.3 describes
how routing state is maintained and how messaging associations are
initiated and terminated.
4.1 GIMPS 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 {flow
routing info, session id, signaling application id}:
Flow: the header N-tuple that determines the route taken by the flow
through the network; in particular, including the flow destination
address.
Session: a cryptographically random and (probabilistically) globally
unique identifier of the application layer session that is using
the flow. For a given flow, different signaling applications may
or may not use the same session identifier. Often there will only
be one flow for a given session, but in mobility/multihoming
scenarios there may be more than one and they may be differently
routed.
Signaling application: 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 or different messaging requirements).
For a given flow and signaling application there can only be a single
row in the table.
The state information for a given key is as follows:
Schulzrinne & Hancock Expires April 19, 2004 [Page 10]
Internet-Draft GIMPS October 2003
Upstream peer: the adjacent GIMPS peer closer to the flow source for
this flow and signaling application. This could be an IP address
(learned from previous signaling) or a pointer to a messaging
association. It could also be null, if this node is the flow
sender or this node is not storing reverse routing state, or a
special value to indicate that this node is the last upstream node
(but not the sender).
Downstream peer: the adjacent GIMPS peer closer to the flow
destination for this flow and signaling application. This could be
a pointer to a messaging association, or it could be null, if this
node is the flow receiver or this node is only sending downstream
datagram mode messages for this flow and signaling application, or
a special value to indicate that this node is the last downstream
node (but not the receiver).
Note that both the upstream and downstream peer state may be null,
and the session identifier information is not required for message
processing; in that case, no state information at all needs to be
stored in the table. Both items of peer identification state have
associated timers for how long the identification can be considered
accurate; when these timers expire, the peer identification (IP
address or messaging association pointer) is purged if it has not
been refreshed. An example of a routing state table for a simple
scenario is given in Appendix B.
Note also that the information is described as a table of flows, but
that there is no implied constraint on how the information is stored.
For example, in a network using pure destination address routing
(without load sharing or any form of policy-based forwarding), the
downstream peer information might be possible to store in an
aggregated form in the same manner as the IP forwarding table. In
addition, many of the per-flow entries may point to the same per-peer
state (e.g. the same messaging association) if the flows go through
the same adjacent peer.
The per-flow message routing state is not the only state stored by
GIMPS. There is also the state implied in the messaging associations.
Since we assume that these associations are typically per-peer rather
than per-flow, they are stored separately. As well as the messaging
association state itself, this table also stores per-association
information including:
o messages pending transmission while an association is being
established;
o an inactivity timer for how long the association has been idle.
Schulzrinne & Hancock Expires April 19, 2004 [Page 11]
Internet-Draft GIMPS October 2003
4.2 Basic Message Processing
This section describes how signaling application messages are
processed in the simple case where any necessary messaging
associations and routing state are already in place. The description
is divided into several parts: message reception, local processing
and delivery to signaling applications, and message transmission. An
overview is given in Figure 3.
+---------------------------------------------------------+
| Signaling Application Processing |
| |
+---------------------------------------------------------+
^ V
^ NSLP Payloads V
^ V
+---------------------------------------------------------+
| GIMPS Processing |
| |
+--x-----------u--d---------------------d--u-----------x--+
x u d d u x
x u d>>>>>>>>>>>>>>>>>>>>>d u x
x u d Bypass at d u x
+--x-----+ +--u--d--+ GIMPS level +--d--u--+ +-----x--+
| C-mode | | D-mode | | D-mode | | C-mode |
|Handling| |Handling| |Handling| |Handling|
+--x-----+ +--u--d--+ +--d--u--+ +-----x--+
x u d d u x
x uuuuuu d>>>>>>>>>>>>>>>>>>>>>d uuuuuu x
x u d Bypass at d u x
+--x--u--+ +-----d--+ router +--d-----+ +--u--x--+
|IP Host | | RAO | alert level | RAO | |IP Host |
|Handling| |Handling| |Handling| |Handling|
+--x--u--+ +-----d--+ +--d-----+ +--u--x--+
x u d d u x
+--x--u-----------d--+ +--d-----------u--x--+
| IP Layer | | IP Layer |
| (Receive Side) | | (Transmit Side) |
+--x--u-----------d--+ +--d-----------u--x--+
x u d d u x
x u d d u x
x u d d u x
uuuuuuuuuuuuuu = upstream datagram mode messages
dddddddddddddd = downstream datagram mode messages
xxxxxxxxxxxxxx = connection mode messages
RAO = Router Alert Option
Schulzrinne & Hancock Expires April 19, 2004 [Page 12]
Internet-Draft GIMPS October 2003
Figure 3: Message Paths through a GIMPS Node
Note that the same messages are also used for internal GIMPS state
maintenance operations. The state maintenance takes place as a result
of processing specific GIMPS payloads in these messages. The
processing of these payloads is the subject of Section 4.3.
Message Reception: Messages can be received in connection or datagram
mode, and from upstream or downstream peers.
Reception in connection mode is simple: incoming packets undergo
the security and transport treatment associated with the messaging
association, and the messaging association provides complete
messages to the GIMPS layer for further processing.
Reception in datagram mode depends on the message direction.
Upstream messages (from a downstream peer) will arrive UDP
encapsulated and addressed directly to the receiving signaling
node. Each datagram contains a single complete message which is
passed to the GIMPS layer for further processing, just as in the
connection mode case.
Downstream datagram mode messages are UDP encapsulated and
addressed to the flow receiver with an IP router alert option to
cause interception. The signaling node will therefore 'see' all
such messages, including those in which it is not interested.
There are then two cases. If the node categorises the message as
'not interesting', it is passed on for message transmission
without further processing (criteria and mechanisms for
categorisation are discussed in Section 8.4). If the message is
determined to be interesting, it is passed up to the GIMPS layer
for further processing as in the other cases.
Local Processing: Once a message has been received, by any method, it
is processed locally within the GIMPS layer. The GIMPS processing
to be done depends on the payloads carried; most of the
GIMPS-internal payloads are associated with state maintenance and
are covered in the next subsection.
One GIMPS-internal payload which can be carried in any message and
requires processing is the GIMPS hop count. This is decremented on
input processing, and checked to be greater than zero on output
processing. The primary purpose of the GIMPS hop count is to
prevent message looping.
The remainder of the GIMPS message consists of an NSLP payload.
This is delivered locally to the signaling application identified
at the GIMPS level; the format of the NSLP payload is not
Schulzrinne & Hancock Expires April 19, 2004 [Page 13]
Internet-Draft GIMPS October 2003
constrained by GIMPS, and the content is not interpreted.
Signaling applications can generate their messages for
transmission, either asynchronously, or in response to an input
message. Messages may also be forwarded in the GIMPS layer if
there is no appropriate local signaling application to process
them. Regardless of the source, outgoing messages are passed
downwards for message transmission processing.
Message Transmission: When a message is available for transmission,
GIMPS uses internal policy and the stored routing state to
determine how to handle it. The following processing applies
equally to locally generated messages and messages forwarded from
within the GIMPS or signaling application levels.
The main decision is whether the message must be sent in
connection mode or datagram mode. Reasons for using the former
could be:
* NSLP requirements: for example, the signaling application has
requested channel secured delivery, or reliable delivery;
* protocol specification: for example, this document could
specify that a message that requires fragmentation MUST be sent
over a messaging association;
* local GIMPS policy: for example, a node may prefer to send
messages over a messaging association to benefit from
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
(see Section 8.5 for further discussion).
If a messaging association is not required, the message is sent in
datagram mode. The processing in this case depends on whether the
message is directed upstream or downstream.
* If the upstream peer IP address is available from the per-flow
routing table, the message is UDP encapsulated and sent
directly to that address. Otherwise, the message cannot be
forwarded (i.e. this is an error condition).
* In the downstream direction, messages can always be sent. They
are simply UDP encapsulated and IP addressed to the flow
receiver, with the appropriate router alert option.
Schulzrinne & Hancock Expires April 19, 2004 [Page 14]
Internet-Draft GIMPS October 2003
If the use of a messaging association is selected, the message is
queued on the association (found from the upstream or downstream
peer state table), and further output processing is carried out
according to the details of the protocol stack used for the
association. If no appropriate association exists, the message is
queued while one is created (see next subsection). If no
association can be created, this is again an error condition.
4.3 Routing State and Messaging Association Maintainance
The main responsibility of the GIMPS layer 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 datagram mode messages containing specific GIMPS payloads.
Messaging associations are dependent on the existence of routing
state, but are actually set up by the normal procedures of the
transport and security protocols that comprise the messaging
association. Timers control routing state and messaging association
refresh and expiration.
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.
Schulzrinne & Hancock Expires April 19, 2004 [Page 15]
Internet-Draft GIMPS October 2003
+----------+ +----------+
| Querying | |Responding|
| Node | | Node |
+----------+ +----------+
GIMPS-query
------------------------->
Router Alert Option
Flow/Session/Sig App ID
Querying Node Addressing
[Query cookie, response request]
[NSLP Payload]
GIMPS-response
<-------------------------
Flow/Session/Sig App ID
Query cookie
Responder node addressing
[Responder cookie, response request]
[NSLP Payload]
Messaging Association Setup
<========================>
Final handshake
------------------------->
Flow/Session/Sig App ID
Responder cookie
Querying Node Addressing
[NSLP Payload]
Figure 4: Message Sequence at State Setup
The initial message in any routing state maintenance operation is a
downstream datagram mode message, sent from the querying node and
intercepted at the responding node. This is encapsulated and
addressed just as in the normal case; in particular, it has
addressing and other identifiers appropriate for the flow and
signaling application that state maintenance is being done for, and
it is allowed to contain an NSLP payload. Processing at the querying
and responding nodes is also essentially the same. However, the
querying node includes additional payloads: its own address
information, and optionally a 'discover-query' payload, which
contains a response request flag and a query cookie. This message is
informally referred to as a 'GIMPS-query', although it is just a
normal message with a particular payload set.
In the responding node, the GIMPS level processing of the
discover-query payload triggers the generation of a 'GIMPS-response'
Schulzrinne & Hancock Expires April 19, 2004 [Page 16]
Internet-Draft GIMPS October 2003
message. This is also a normally encapsulated and addressed message
with particular payloads, this time in the upstream direction. Again,
it can contain an NSLP payload (possibly a response to the NSLP
payload in the initial message). It includes its own addressing
information and the query cookie, and optionally a
'discover-response' payload, which contains another response request
flag and a responder cookie. Note that if a messaging association
already exists towards the querying node, this can be used to deliver
the GIMPS-response message; otherwise, datagram mode is used.
The querying node installs the responder address as downstream peer
state information after verifying the query cookie in the
GIMPS-response. The responding node can install the querying address
as upstream peer state information after the receipt of the initial
GIMPS-query, or after a third message in the downstream direction
containing the responder cookie. The detailed constraints on
precisely when state information is installed are driven by security
considerations on prevention of denial-of-service attacks and state
poisoning attacks, which are discussed further in Section 7.
Setup of messaging associations begins when both downstream peer
addressing information is available and a new messaging association
is actually needed. (In many cases, the GIMPS-response message above
will identify a downstream peer for whom an appropriate messaging
association already exists, in which case no further GIMPS management
is needed.) Setup of the messaging association always starts from the
upstream node, but once the querying node has sent any queued
signaling application messages it can be used equally in both
directions.
Refresh and expiration of all types of state is controlled by timers.
State in the routing table has a per-flow, per-direction timer, which
expires after a routing state lifetime (RSL). It is the
responsibility of the querying node to generate a GIMPS-query
message, optionally with a discover-query payload, before this timer
expires, if it believes that the flow is still active. Receipt of the
message at the responding node will refresh upstream peer addressing
state, and receipt of a GIMPS-response at the querying node will
refresh any downstream peer addressing state if it exists. Note that
nodes do not control the refresh of upstream peer state themselves,
they are dependent on the upstream peer to manage this.
Messaging associations can be managed by either end. Management
consists of tearing down unneeded associations. Whether an
association is needed is a local policy decision, which could take
into account the cost of keeping the messaging association open, the
level of past activity on the association, and the likelihood of
future activity (e.g. if there are flows still in place which might
Schulzrinne & Hancock Expires April 19, 2004 [Page 17]
Internet-Draft GIMPS October 2003
generate messages that would use it). Because messaging associations
can always be set up on demand, and messaging association status is
not made directly visible outside the GIMPS layer, 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.
Schulzrinne & Hancock Expires April 19, 2004 [Page 18]
Internet-Draft GIMPS October 2003
5. Message Formats and Encapsulations
5.1 Message Formats
All GIMPS messages begin with a common header which includes a
version number field. For messages sent over a messaging association,
it may also include transport protocol specific format information as
discussed in Section 5.3.1. The remainder of the message is is
encoded in an RSVP-style format, i.e., consisting of
type-length-value (TLV) objects. A later version of this
specification will contain more details on rules for object encodings
which enable protocol extensibility.
These items are contained in each GIMPS message:
Flow routing information: Information sufficient to define the route
that the flow will take through the network. Minimally, this could
just be the flow destination address; however, to account for
policy based forwarding and other issues a more complete set of
header fields should be used (see Section 6.2 and Section 6.4 for
further discussion). This object also contains a flag to indicate
whether the signaling message is being sent upstream or downstream
with respect to the flow.
Session identifier: The GIMPS session identifier is a long,
cryptographically random identifier chosen by the initiator. The
length is open, but 128 bits should be more than sufficient to
make the probability of collisions orders of magnitude lower than
other failure reasons.
Signaling application identifier: This describes the signaling
application, such as resource reservation or firewall control.
GIMPS Hop counter: A hop counter prevents a message from looping
indefinitely. (Since messages may get translated between different
lower-layer transport protocols, the IP hop count cannot be relied
upon.)
The following items are optional:
Lifetime: The lifetime of a routing state in the absence of
refreshes, measured in seconds. Defaults to 30 seconds.
Node addressing: Minimally, this is the IP address at which the GIMPS
node originating the message can be reached; this will be used to
fill in peer routing state. Additional information can be provided
on node capabilities and policy on messaging association
management, as well as currently available associations. The level
Schulzrinne & Hancock Expires April 19, 2004 [Page 19]
Internet-Draft GIMPS October 2003
of flexibility required in this field is discussed in Section 8.5.
Cookies: A query-cookie is optional in a GIMPS-query message and if
present 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 downstream message. The optional cookies
and response request flags make up the discover-query and
discover-response payloads. Cookies are X-octets long and need to
be designed so that a node can determine the validity of a cookie
without keeping state.
Message identifier: A four-octet message counter, used to associate
GIMPS messages with their confirmations. The initial use for this
is in state maintenance exchanges (GIMPS-query/response); possible
use to provide a simple one-off reliable exchange for signaling
application messages is considered in Section 8.9.
NSLP Payload: The payload carries one or more NSLP objects. GIMPS
does not interpret the payload content.
5.2 Encapsulation in Datagram Mode
Encapsulation in datagram mode is simple. The complete set of GIMPS
payloads for a single message is concatenated together with the
common header, and placed in the data field of a UDP datagram. UDP
checksums should be enabled. Upstream messages are addressed to the
adjacent peer, downstream messages are addressed to the flow receiver
and encapsulated with a Router Alert Option. Open issues about
alternative encapsulations, addressing possibilities, and router
alert option value field setting are discussed in Section 8.2,
Section 8.3 and Section 8.4 respectively.
The source UDP port is selected by the message sender. 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 another application. Therefore, a well-known port
would seem to be required.
5.3 Encapsulation Options in Connection Mode
Encapsulation in connection mode is more complex, firstly because of
the increased demands on transport functionality. This issue is
treated in Section 5.3.1. In addition, a consequence of the
restriction to the use of existing transport and security protocols
is that messaging associations must run between fixed nodes. However,
Schulzrinne & Hancock Expires April 19, 2004 [Page 20]
Internet-Draft GIMPS October 2003
there are still several options for how the IP packets for the
messaging association should be carried on the wire between these
nodes. These alternatives have different functionality, flexibility
and performance tradeoffs, and are considered in Section 5.3.2 -
Section 5.3.4.
5.3.1 General Considerations
It is a general requirement of the NTLP defined in [18] 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 [5] satisfies all requirements. (The bundling requirement is met
implicitly by the use of Nagle-like algorithms inside the SCTP
stack.)
DCCP [6] is message based but does not provide bundling or
fragmentation. These could both be provided by an additional
(simple) encapsulation above the DCCP level.
TCP provides both bundling and fragmentation, but not message
boundaries. Again, this could be done with a simple length field
embedded in the TCP data stream to mark each message.
UDP could be augmented as in the DCCP case. (However, note that it
should probably not be used for messages requiring fragmentation,
because of UDP's lack of congestion control functionality.)
If it is desired to support all these protocol options, it is
probably easiest to handle this as the addition of transport protocol
specific shim layers at the top of the messaging association, so that
the GIMPS layer sees a uniform functionality transport service
interface. The control information for these shim layers would be
carried inside the GIMPS fixed header.
5.3.2 Raw Encapsulation
The simplest encapsulation is to carry the GIMPS and signaling
application payloads directly in the transport protocol, and to carry
that protocol on the wire in the normal way. This situation is shown
in Figure 5; it applies to both upstream and downstream messages.
Schulzrinne & Hancock Expires April 19, 2004 [Page 21]
Internet-Draft GIMPS October 2003
+---------------------------------------------+
| L2 Header |
+---------------------------------------------+
| IP Header | ^
| Source address = signaling source | ^
| Destination address = signaling destination | .
+---------------------------------------------+ .
| L4 Header | . ^
| (Standard TCP/SCTP/DCCP/UDP header) | . ^
+---------------------------------------------+ . .
| GIMPS Fixed Header | . . ^
| (Optional shim fields, depending on L4) | . . ^ Scope of
+---------------------------------------------+ . . . security
| GIMPS Payloads | . . . protection
|(Sequence of TLV Elements, as in Section 6.1)| . . . (depending
+---------------------------------------------+ . . . on channel
| NSLP Payloads | . . . security
| (Opaque to GIMPS) | V V V mechanism
+---------------------------------------------+ V V V in use)
Figure 5: Raw Messaging Association Encapsulation
The advantages and disadvantages of this approach are as follows:
+) Practically all transport and security protocols can be used.
+) Use of existing protocol stack implementations is simple.
+) There is very little protocol overhead.
-) In order to do any processing on any of the GIMPS or signaling
application payloads, the complete messaging association must be
terminated at the processing node. This applies even if the
processing to be done is very lightweight (e.g. an address
translation) and/or the node does not support the signaling
application in question. This property makes it hard to offer
useful transport and security properties between signaling
application peers which need them, particularly flow control/
reliable delivery and signaling application payload
confidentiality and integrity.
-) More generally, for a given signaling application on two nodes,
there is very little room for flexibility in the NSIS processing
at nodes in between. Nodes have to process everything or nothing,
igoring the application completely.
Schulzrinne & Hancock Expires April 19, 2004 [Page 22]
Internet-Draft GIMPS October 2003
-) Signaling messages are only ever delivered between peers
established in GIMPS-query/response exchanges. Any route change is
not detected until another GIMPS-query/response procedure takes
place; in the meantime, signaling messages are misdelivered.
The raw encapsulation is most appropriate (has very few
disadvantages) in an environment where routes are stable and the
signaling nodes are highly homogeneous (all nodes have identical
processing requirements). A scenario which illustrates the problems
that arise in more heterogeneous environments is given in Appendix C.
5.3.3 Peer-Peer Tunnelled Encapsulation
In order to allow intermediate nodes to do limited processing of some
GIMPS payloads without interfering with the overall transport and
security service being provided by the messaging association, it is
necessary to carry some of the payloads outside the messaging
association protocols. One method for doing this is shown in Figure
6; it also applies to both upstream and downstream messages.
Schulzrinne & Hancock Expires April 19, 2004 [Page 23]
Internet-Draft GIMPS October 2003
+---------------------------------------------+
| L2 Header |
+---------------------------------------------+
| IP Header |
| Source address = signaling source |<---+
| Destination address = signaling destination | |
+---------------------------------------------+ | Repeated
| Router Alert Option | | IP header
+---------------------------------------------+ |
| UDP Header | |
| (Possibly using datagram mode ports) | |
+---------------------------------------------+ |
| Mutable GIMPS Header and Payloads | |
| (Subset of full GIMPS payload set) | |
+---------------------------------------------+ |
| IP Header | | ^
| Source address = signaling source |<---+ ^
| Destination address = signaling destination | .
+---------------------------------------------+ .
| L4 Header | .
| (Standard TCP/SCTP/DCCP/UDP header) | .Similar
+---------------------------------------------+ .to 'raw'
| GIMPS Fixed Header | . case
| (Optional shim fields, depending on L4) | .
+---------------------------------------------+ .
| 'End to end' GIMPS Payloads | .
|(Sequence of TLV Elements, as in Section 6.1)| .
+---------------------------------------------+ .
| NSLP Payloads | .
| (Opaque to GIMPS) | V
+---------------------------------------------+ V
Figure 6: Peer-Peer Tunnelled Messaging Association Encapsulation
The 'raw' encapsulation is carried within a tunnel; the outer tunnel
encapsulation is similar to datagram mode (except with fixed
addresses for both the upstream and downstream directions).
Advantages and disadvantages are as follows:
+) Any message-based transport and security protocol can be used.
+) Intermediate nodes (between the signaling source and destination,
which are assumed to be peers processing the full signaling
application) can intercept the packet because of the router alert
option and process the 'mutable' GIMPS payloads. This allows for
lighter-weight intermediate nodes. To avoid disrupting the
operation of the transport protocols, this processing should be
restricted to operations that can be carried out on a 'fast
Schulzrinne & Hancock Expires April 19, 2004 [Page 24]
Internet-Draft GIMPS October 2003
signaling path', for example avoiding AAA operations.
+) However, reliability and other transport functions continue to run
between the 'outer' signaling application peers, and channel
security also applies (except of course for the mutable fields)
between them.
+) In principle, signaling application payloads could also be carried
in the 'mutable' area.
-) Stream-based transport and security protocols would be hard to use
in this way (i.e. ruling out TCP/TLS).
-) Integration of existing protocol stacks implementations is more
complex. When a message is sent or received at the messaging
association endpoints, the mutable field contents have to be
provided as ancilliary data somehow.
-) The mutable area is vulnerable to spoofing and interception.
(However, such attacks can only be launched by on-path nodes.)
-) There is some additional protocol overhead, mainly the repeated IP
header. (It might be possible to omit this.)
-) This encapsulation is 'blind' to route changes as in the raw case.
-) If policy-based forwarding is in use between the signaling source
and destination, the intermediate nodes traversed may not be the
correct ones for the flow path, because the outer IP header does
not match the flow packet IP header. (This could be handled with
the functionality of Section 6.3.)
The application of this method to a heterogeneous signaling scenario
is shown in Appendix C. This tunnelled encapsulation is conceptually
similar to the use of a new IP option to carry the mutable fields.
However, the use of a new IP option format would be problematic for
IPv4; for IPv6, we would either have to allow the intermediate nodes
to process destination options on seeing the router alert, or use a
hop-by-hop option, with similar effects to the IPv4 case. Although
the cost is a duplicate IP header, the UDP tunnelling method seems
more attractive.
5.3.4 End-to-End Tunnelled Encapsulation
In order to get round the need for parallel route change discovery,
an alternative tunnel encapsulation can be considered for downstream
signaling messages. One method for doing this is shown in Figure 7.
(The corresponding upstream encapsulation would be the point-to-point
Schulzrinne & Hancock Expires April 19, 2004 [Page 25]
Internet-Draft GIMPS October 2003
tunnel mode.)
+---------------------------------------------+
| L2 Header |
+---------------------------------------------+
| IP Header |
| Source address = flow sender |<---+
| Destination address = flow receiver | |
+---------------------------------------------+ | Different
| Router Alert Option | | IP header
+---------------------------------------------+ |
| UDP Header | |
| (Possibly using datagram mode ports) | |
+---------------------------------------------+ |
| Mutable GIMPS Header and Payloads | |
| (Subset of full GIMPS payload set) | |
+---------------------------------------------+ |
| IP Header | | ^
| Source address = signaling source |<---+ ^
| Destination address = signaling destination | .
+---------------------------------------------+ .
| L4 Header | .
| (Standard TCP/SCTP/DCCP/UDP header) | .Similar
+---------------------------------------------+ .to 'raw'
| GIMPS Fixed Header | . case
| (Optional shim fields, depending on L4) | .
+---------------------------------------------+ .
| 'End to end' GIMPS Payloads | .
|(Sequence of TLV Elements, as in Section 6.1)| .
+---------------------------------------------+ .
| NSLP Payloads | .
| (Opaque to GIMPS) | V
+---------------------------------------------+ V
Figure 7: End-to-End Tunnelled Messaging Association Encapsulation
The sole change is the use of flow sender and receiver addresses in
the outer IP header. This has a number of significant implications
compared to the previous case:
+) Route changes are automatically detected by messages sent in the
downstream direction. The receiving node will determine that the
messaging association headers (in fact, the inner IP header) is
incorrect and can notify the signaling source that a discovery
exchange is needed.
Schulzrinne & Hancock Expires April 19, 2004 [Page 26]
Internet-Draft GIMPS October 2003
+) Intermediate nodes can still process the 'mutable' GIMPS payloads
without breaking end-to-end security and transport properties of
the messaging association.
+) Again, signaling application payloads could also be carried in the
'mutable' area.
+) Policy-based forwarding will be automatically handled in the
downstream direction.
-) Stream-based transport and security protocols would be hard to use
in this way (i.e. ruling out TCP/TLS). In addition, because some
messages will be 'lost' from the messaging association on a route
change, the protocol must allow for partial reliability (e.g.
PR-SCTP [7] rather than full SCTP, also allowing only IPsec and
not TLS for channel security.)
-) For the same reason, the congestion processing of the transport
protocols becomes more complex, because there is an additional
source of non-congestive message loss which the transport protocol
itself is not aware of.
-) Integration of existing protocol stacks implementations is as
complex as in the peer-to-peer case, and there is the same
additional protocol overhead.
The attractiveness of this encapsulation depends on the perceived
value of the automatic route change detection. If route change
detection is primarily done by tracking events outside GIMPS itself,
background rediscovery at a lower rate is no longer a significant
overhead, and the advantages over peer-to-peer tunnelling are
limited.
Schulzrinne & Hancock Expires April 19, 2004 [Page 27]
Internet-Draft GIMPS October 2003
6. Advanced Protocol Features
6.1 Route Changes
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 may be 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 main responsibility is to detect the route
change, update its own routing state consistently, and inform
interested signaling applications at affected nodes.
6.1.1 Route Change Detection
There are three primary mechanisms for a GIMPS node to detect that
the downstream flow path has changed:
1. 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, in RSVP and GIMPS, this only works
if the routing change is local, not if the routing change happens
somewhere a few routing hops away.
2. An extended trigger, where the node checks the 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
intra-domain and 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.
3. In probing mode, each GIMPS node periodically repeats the
discovery operation. 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 that
routes are stable for hours and days, so this may not be
necessary on a 30-second interval. (Sender mobility is handled
differently issue since the signaling message will visit "virgin"
territory, rather than nodes with existing sessions.)
For the first two mechanisms, once the change has been detected, the
discovery-query/response sequence is then triggered at the detecting
node (for the third case this sequence is part of the detection
Schulzrinne & Hancock Expires April 19, 2004 [Page 28]
Internet-Draft GIMPS October 2003
mechanism anyway). This propagates downstream until it rejoins the
old path; the node where this happens may also have to carry out
local repair actions.
In addition, there are several semi-heuristic techniques to detect
that the flow path might have changed, based on monitoring changes in
flow or signaling packet behaviour at downstream nodes (these are
discussed in [18]). These are mainly implementation options at the
detecting node; exploiting them might require an additional GIMPS
payload to be sent in the upstream direction with the semantics 'the
route for this flow may have changed', hence triggering discovery
again.
6.1.2 Local Repair Storms
Even where a node has detected a route change in the downstream
direction, there are still two possible cases:
o the detecting node may be the true crossover router, i.e. the
point in the network where old and new paths diverge, or
o the path change may actually have taken place upstream of the
detecting node (so that this node is no longer on the path at all)
In some circumstances, it is hard to distinguish these cases; an
example is shown in Figure 8. Here, after the link failure, node A is
the true crossover, but nodes B1/C1/D1 may all also initiate local
repair operations. A later version of this document will consider how
to control this.
Schulzrinne & Hancock Expires April 19, 2004 [Page 29]
Internet-Draft GIMPS October 2003
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 8: A Re-Routing Event
6.1.3 Propagating Route Change Notifications
A second problem that may occur with route change detection is that
the detecting GIMPS node may not implement all the signaling
applications that need to be informed. Therefore, the GIMPS node
needs to be able to send a notification back along the unchanged path
Schulzrinne & Hancock Expires April 19, 2004 [Page 30]
Internet-Draft GIMPS October 2003
to trigger the nearest signaling application aware node to take
action. If multiple signaling applications are in use, it will be
hard to define when to stop propagating this notification.
If the intermediate node bypass capabilities described in Section
4.3, Section 5.3 and Section 8.4 are fully used, one consequence is
that this separation between the nodes which do route change
detection and signaling application processing no longer occurs, so
this problem in its raw form no longer arises. Conversely, 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 about local changes in forwarding
table state, a flow signaling protocol is probably not the right
starting point.)
6.2 Policy-Based Forwarding
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:
Flow Routing Information: This is the information needed to determine
how a flow is routed within the network. Minimally it is the flow
destination address, but to handle load sharing, QoS routing, and
other forms of policy based forwarding it can be extended to
include the full IPv4 5-tuple or IPv6 3-tuple, and possibly
traffic class information as well. It 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).
The correct pinning of signaling messages to the data path depends on
how well the downstream messages in datagram mode can be made to be
routed correctly. Two strategies are used:
The messages themselves have the flow destination address, and
possibly source address and traffic class (see Section 8.3 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 flow routing
Schulzrinne & Hancock Expires April 19, 2004 [Page 31]
Internet-Draft GIMPS October 2003
information object in selecting the outgoing interface rather than
relying on the IP layer.
6.3 Route Recording
The basic procedures of Section 4.3 describe how messages between
adjacent GIMPS peers are used to fill in address information for use
in subsequent message exchanges. When GIMPS messages only go between
adjacent peers, this is all that is needed.
However, the more flexible encapsulations of Section 5.3.3 and
Section 5.3.4 allow signaling messages to be sent via intermediate
GIMPS nodes which do some limited processing of GIMPS or signaling
application payloads. It is necessary to ensure that the correct
sequence of intermediate nodes is traversed, in the downstream
direction and possibly also in the upstream direction. (For example,
if the intermediate node is a NAT, payload translations must be made
for both directions of signaling message.) However, this may not
happen automatically, in the downstream direction because of policy
based forwarding, and in the upstream direction because of asymmetric
routing.
One solution for this problem is to generalise the notion of the
upstream/downstream peer address into a sequence of addresses, i.e. a
recorded route. This route can be built up in GIMPS-query messages:
nodes which need to be kept on the signaling path but which do not
wish to maintain per-flow forwards or reverse routing state can
append their outgoing address to a GIMPS 'route record' payload, a
generalisation of the 'peer addressing information' object of Section
5.1. This is then stored at the receiver in place of the upstream
peer address. The GIMPS-response message sent back can be source
routed using this, and can gather another route record of the
upstream path which replaces the downstream peer address at the
querying node. The address manipulations at intermediate nodes are
very similar to source routing in IPv4 or IPv6, and it might be
possible to use these underlying protocol features instead of a
specific GIMPS function.
6.4 NAT Traversal
A already noted, GIMPS messages must carry packet addressing and
higher layer information as payload data in order to define the flow
signalled for. (This applies to all GIMPS messages, regardless of 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
Schulzrinne & Hancock Expires April 19, 2004 [Page 32]
Internet-Draft GIMPS October 2003
meaningless) flows after passing through the boundary.
The simplest solution to this problem is to require that a NAT is
GIMPS aware, and to allow it to update/rewrite the flow routing
information payload described in Section 6.2. (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. For this reason, the flow
routing information is a candidate to be carried in the 'mutable'
area if either tunnelled encapsulation for connection mode messages
is used (Section 5.3.3 and Section 5.3.4), since then the NAT does
not even have to terminate the transport association protocols. It
does raise security issues about unauthorised modifications to this
payload.
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 flow routing information
from what is done to the signaling packet headers. The fundamental
problem is that GIMPS mssages contain 3 or 4 interdependent addresses
which all have to be consistently translated, and existing generic
NAT traversal techniques such as STUN [17] can process only two.
6.5 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 have the router alert option or the
standard GIMPS protocol encapsulation (e.g. port numbers). They will
not be identifiable as GIMPS messages until they leave the tunnel
again. 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
Schulzrinne & Hancock Expires April 19, 2004 [Page 33]
Internet-Draft GIMPS October 2003
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 [9]. Whether this functionality should really
be part of GIMPS and if so how the payload should be handled will be
considered in a later version.
6.6 IPv4-IPv6 Transition and Interworking
GIMPS itself is essentially IP version neutral (version dependencies
are isolated in the formats of certain GIMPS payloads, and GIMPS also
depends on the version independence of the protocols that underlie
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
[11] as well as the dual-stack aspects of more complete
architectures such as [21].) 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
for which GIMPS support was available in the network, 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.
Schulzrinne & Hancock Expires April 19, 2004 [Page 34]
Internet-Draft GIMPS October 2003
Packet Translation: (Applicable to SIIT [4] and NAT-PT [10].) 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 6.4. 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 flow routing information payload between IPv4 and
IPv6 formats for flows which cross between the two. The
translation rules for the fields in the payload (including e.g.
traffic class and flow label) are as defined in [4].
Tunnelling: (Applicable to 6to4 [13] 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 6.5. 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, [14] 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 April 19, 2004 [Page 35]
Internet-Draft GIMPS October 2003
7. 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
[19]; the NSIS framework [18] 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 interception, modification etc. 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.
State Integrity Protection: It is important that signaling messages
are delivered to the right nodes (and not delivered to the wrong
ones). 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.
7.1 Message Confidentiality and Integrity
GIMPS can use messaging association functionality, such as TLS or
IPsec, to ensure message confidentiality and integrity. In many
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. 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, particularly if this is provided efficiently
and if it runs unbroken between signaling application peers.
Schulzrinne & Hancock Expires April 19, 2004 [Page 36]
Internet-Draft GIMPS October 2003
7.2 Peer Node Authentication
Cryptographic protection (of confidentiality or integrity) typically
requires session keys, which can established during authentication
exchanges based on shared secrets or public key techniques.
Authentication and key agreement is possible using the protocols
associated with the messaging association being secured (TLS
incorporates this functionality directly, IKE provides 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, 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. the correct peer to carry out
signaling with 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 7.3 below.
7.3 Routing State Integrity
The internal state in a node (see Section 4.1), specifically the
upstream and downstream peer identification, is used to route
messages along the data flow path. If this state is corrupted,
signaling messages may be misdirected.
The routing state table is the local GIMPS view of what routes are
being taken by flows through the network. Since routes are only
weakly secured (e.g. there is usually no cryptographic binding of a
flow to a route), and there is no other authoritative information
about flow routes 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 upstream and downstream signaling peers are the
appropriate ones for any given flow. A good overview of security
issues and techniques in this sort of context is provided in [20].
Downstream peer identification is installed and refreshed only on
receiving a GIMPS-reponse message. This must echo the cookie from a
previous GIMPS-query message, which will have been sent downstream
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.
Upstream peer identification can be installed directly on receiving a
Schulzrinne & Hancock Expires April 19, 2004 [Page 37]
Internet-Draft GIMPS October 2003
GIMPS-query message containing addressing information for the
upstream peer. 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, two
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 last 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: the receiving node may refuse to install upstream
state until it has handshaked by some means with the upstream
peer. This handshaking could be as simple as requesting the
upstream peer to echo the response cookie in the discover-response
payload of a GIMPS-response message (to discourage nodes
impersonating upstream peers from using forged source addresses);
or, it could be full peer authentication within the messaging
association, the reasoning being that an authenticated peer can be
trusted not to pretend to be on path when it is not.
The second technique also plays a role in denial of service
prevention, see below. In practice, a combination of both techniques
may be appropriate.
7.4 Denial of Service Prevention
GIMPS is designed so that each connectionless discovery message only
generates at most one response, so that a GIMPS node cannot become
the source of a denial of service amplification attack.
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. 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
Schulzrinne & Hancock Expires April 19, 2004 [Page 38]
Internet-Draft GIMPS October 2003
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.)
There are at least three defenses against these attacks:
1. The responding node does not establish a session or discover its
next hop on receiving the GIMPS-query message, but can wait for a
setup message on a reliable channel. If the reliable channel
exists, the additional delay is a 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
be established first.
2. The response to the initial discovery message contains a cookie.
The previous hop repeats the discovery with the cookie included.
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 [5].)
3. If there is a chance that the next-hop node shares a secret with
the previous hop, the sender could include a hash of the session
ID and the sender's secret. The receiver can then verify that the
message was likely sent by the purported source. This does not
scale well, but may work if most nodes tend to communicate with a
small peer clique of nodes. (In that case, however, they might as
well establish more-or-less permanent transport sessions with
each other.)
These techniques are complementary; we chose a combination of the
first and second method.
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 upstream node is always the one wishing
to establish a messaging association, so it is typically the
downstream node that is protected. Extensions are considered in
Section 8.6; these would require further analysis.
Schulzrinne & Hancock Expires April 19, 2004 [Page 39]
Internet-Draft GIMPS October 2003
8. Open Issues
8.1 Protocol Naming
Alternate names:
GIST: Generic Internet Signaling Transport
GIMPS: Generic Internet Messaging Protocol for Signaling
LUMPS: Lightweight Universal Messaging for Path associated Signaling
There is a danger of some ambiguity as to whether the protocol name
refers to the complete transport stack below the signaling
applications, or only to the additional protocol functionality above
the standard transport protocols (UDP, TCP etc.) The NSIS framework
uses the term NTLP for the first, but this specification uses the
GIST/variants names for the second (see Figure 2 in Section 3.1). In
other words, this specification proposes to meet the requirements for
NTLP functionality by layering GIMPS/... over existing standard
transport protocols. It isn't clear if additional terminological
surgery is needed to make this clearer.
8.2 General IP Layer Issues
Some NSIS messages have to be addressed end-to-end but intercepted at
intermediate routers, and this imposes some special constraints on
how they can be encapsulated. RSVPv1 [8] primarily uses raw IP with
specific protocol number (46); a UDP encapsulation is also possible
for hosts unable to perform raw network i/o. RSVP aggregation [15]
uses an additional protocol number (134) to bypass certain interior
nodes.
The critical requirements for the encapsulation at this level are
that routers should be able to identify signaling packets for
processing, and that they should not mis-identify packets for
'normal' end-to-end user data flows as signaling packets. The current
assumption is that UDP encapsulation can be used for such messages,
by allocating appropriate (new) value codes for the router alert
option (RAO) [1][3] to identify NSIS messages. Specific open issues
about how to allocate such values are discussed in Section 8.4.
An alternative approach would be to use raw IP with the RSVP protocol
numbers and a new RSVP version number.
8.3 Encapsulation and Addressing for Datagram Mode
The discussion in Section 4 essentially assumes that datagram mode
messages are UDP encapsulated. This leaves open the question of
whether other encapsulations are possible, and exactly how these
messages should be addressed.
Schulzrinne & Hancock Expires April 19, 2004 [Page 40]
Internet-Draft GIMPS October 2003
As well as UDP/IP (and raw IP as discussed and temporarily ruled out
in Section 8.2), DCCP/IP and UDP/IPsec could also be considered as
'datagram' encapsulations. However, they still require explicit
addressing between GIMPS peer nodes and some per-peer state to be set
up and maintained. Therefore, it seems more appropriate to consider
these encapsulation options as possible messaging association types,
for use where there is a need for congestion control or security
protection but without reliability. This would leave UDP/IP as the
single encapsulation allowed for all datagram mode messages.
Addressing for upstream datagram mode messages is simple: the IP
source address is the signaling source address, and the IP
destination address is the signaling destination address (compare
Figure 1). For downstream datagram mode messages, the IP destination
address will be the flow destination address, but the IP source
address could be either of the flow source address or signaling
source address. Some of the relative merits of these options are as
follows:
o Using the flow source address makes it more likely that the
message will be correctly routed through any intermediate
NSIS-unaware region which is doing load sharing or policy routing
on the {source, destination} address pair. If the signaling source
address is used, the message will be intercepted at some node
closer to the flow destination, but it may not be the same as the
next node for the data flow packets.
o Conversely, using the signaling source address means that ICMP
error messages (specifically, unreachable port or address) will be
correctly delivered to the message originator, rather than being
sent back to the flow source. Without seeing these messages, it is
very difficult for the querying node to recognise that it is the
last NSIS node on the path. In addition, using the signaling
source address may make it possible to exchange messages through
GIMPS unaware NATs (although it isn't clear how useful the
resulting messages will be, see Section 6.4).
It is not clear which of these situations it is more important to
handle correctly and hence which source addressing option to use.
(RSVP uses the flow source address, although this is primarily for
multicast routing reasons.) A conservative approach would be to allow
both, possibly even in parallel (although this might open up the
protocol to amplification attacks).
As well as the addressing, downstream datagram mode messages could be
given the same traffic class (and, in the case of IPv6, flow label)
as data flow messages. Doing this would increase the faithfulness of
the routing of such messages. The traffic class may not be strictly
Schulzrinne & Hancock Expires April 19, 2004 [Page 41]
Internet-Draft GIMPS October 2003
appropriate for signaling; however, in many cases the bulk of the
signaling messages will be sent in connection mode (for which a
different traffic class can be freely chosen).
8.4 Intermediate Node Bypass and Router Alert Values
We assume that the primary mechanism for intercepting messages is the
use of the RAO. The RAO contains a 16 bit value field, within which
35 values have currently been assigned by IANA. It is open how to
assign values for use by GIMPS messages to optimise protocol
processing, i.e. to minimise the amount of slow-path processing that
nodes have to carry out for messages they are not actually interested
in the content of.
There are two basic reasons why a GIMPS node might wish to ignore a
message:
o because it is for a signaling application that the node does not
process;
o because even though the signaling application is present, the node
is only processing signaling messages at the aggregate level and
not for individual flows (compare [15]).
Once a message is ignored and forwarded onwards towards the next
node, the current node has essentially dropped out of the signaling
path for this flow and signaling application. Its address will not be
discovered and used for upstream datagram mode messages or any
connection mode messages.
Some or all of this information could be encoded in the RAO value
field, which would then allow these messages to be filtered on the
fast path. (Even if the information is encoded deeper into the
message, such as in the GIMPS fixed header, it may still be possible
to process it on the fast path, and the semantics of the node
dropping out of the signaling path are the same however the filtering
is done. However, using the RAO seems the most efficient method if
this is possible.) It is not clear whether the signaling application
and aggregation level should be directly identified in the RAO value,
or whether IANA should allocate special values for 'popular'
applications or groups of applications or network configurations. The
former is most flexible but is liable to be expensive in terms of
value allocations.
There is a special consideration in the case of the aggregation
level. In this case, whether a message should be processed depends on
the network region it is in. There are then two basic possibilities:
Schulzrinne & Hancock Expires April 19, 2004 [Page 42]
Internet-Draft GIMPS October 2003
1. All routers have essentially the same algorithm for which
messages they process, i.e. all messages at aggregation level 0.
However, messages have their aggregation level incremented on
entry to an aggregation region and decremented on exit.
2. Routers process messages only above a certain aggregation level
and ignore all others. The aggregation level of a message is
never changed; signaling messages for end to end flows have level
0, but signaling messages for aggregates are generated with a
higher level.
The first technique requires aggregating/deaggregating routers to be
configured as being at a particular aggregation level, and also
requires consistent message rewriting at these boundaries. The second
technique eliminates the rewriting, but requires interior routers to
be configured also. It is not clear what the right trade-off between
these options is.
8.5 Messaging Association Flexibility
The language of Section 4 is mainly based on the use of 0 or 1
messaging associations between any pair of GIMPS nodes. However,
logically it would be quite possible to have more than one
association, for example:
o to allow different reliability characteristics;
o to provide different levels of security protection or to have
security separation between different signaling streams;
o even simply to have load split between different connections
according to priority (so there could be two associations with
identical protocol stacks).
It is possible to imagine essentially infinite flexibility in these
options, both in terms of how many possibilities are allowed and how
nodes signal their capabilities and preferences, without much
changing the overall GIMPS structure. (The GIMPS-query and
GIMPS-response messages described in section Section 4.3 can be used
to exchange this information.) What is not clear is how much
flexibility is actually needed.
8.6 Messaging Association Setup Message Sequences
The discussion of Section 4.3 assumes a simple fixed message
sequence, which we can picture as follows:
Schulzrinne & Hancock Expires April 19, 2004 [Page 43]
Internet-Draft GIMPS October 2003
+---------------------------------+---------------------------------+
| Direction | Message |
+---------------------------------+---------------------------------+
| ---> | GIMPS-query message |
| | |
| <--- | GIMPS-response message |
| | |
| ===> | Querying node initiates |
| | messaging association setup |
| | messages |
| | |
| <--> | Signaling messages exchanged |
+---------------------------------+---------------------------------+
There are several variants which could be considered at this level,
for example whether the messaging association could be set up by the
responding node:
+---------------------------------+---------------------------------+
| Direction | Message |
+---------------------------------+---------------------------------+
| ---> | GIMPS-query message |
| | |
| <=== | Responding node initiates |
| | messaging association setup |
| | messages |
| | |
| <--> | Signaling messages exchanged |
+---------------------------------+---------------------------------+
This saves a message but may be vulnerable to additional denial of
service attacks.
Another open area is how the responding node propagates the signaling
message downstream. It could initiate the downstream discovery
process as soon as it received the initial GIMPS-query message, or it
could wait until the first signaling application message has been
received (which might not be until a messaging association has been
established). A similar timing question applies to when it should
initiate its own downstream messaging associations. It is possible
that all these options are simply a matter for implementation
freedom, although leaving them open will make mobility and re-routing
behaviour rather harder to analyse, and again there are denial of
service implications for some approaches (see Section 7.4).
A final open area is how to manage the protocol exchanges that take
place in setting up the messaging association itself. It is probably
an implementation matter to consider whether to carry out, for
Schulzrinne & Hancock Expires April 19, 2004 [Page 44]
Internet-Draft GIMPS October 2003
example, the SCTP 4-way handshake only after IKE exchanges (for IPsec
SA initialisation) have completed, or whether these can be done
partly in parallel. A more radical step is to carry the initial
request and response messages of both exchanges as payloads in the
GIMPS-query/response exchange, with the request message initially
formatted by the querying node with an unspecified destination IP
address. This would require modifications to the protocol
implementations (especially at the querying node) similar to what is
needed for NAT traversal; it would have to be evaluated whether this
was worth the one or two round trip times that are saved.
8.7 Connection Mode Encapsulation
Section 5.3.2 - Section 5.3.4 present 3 options for encapsulation in
connection mode. Allowing all three would be a significant complexity
cost, especially given the interaction between encapsulation mode and
feasible protocols. If one option has to be chosen, point-to-point
tunnelling currently seems most attractive.
There might be efficiency saving in being able to use raw mode in the
core of the networks, for example on single-hop interdomain links
where these intermediate node problems do not arise. The absence of
intermediate nodes could be determined during the GIMPS-query/
response exchange, and then raw mode encapsulation chosen only when
possible.
8.8 GIMPS State Teardown
The description of Section 4.3 provides for GIMPS state (per-flow
routing state and per-peer messaging association state) to be removed
on timer expiry; routing state can also be replaced (updated). This
is the fundamental technique. An additional possibility would be to
have explicit removal, i.e. a protocol mechanism to tear down GIMPS
state immediately for a particular flow. On recieving such a message,
a GIMPS node would clear routing entries and possibly take down
messaging associations that were no longer used.
Even if one peer indicates that routing state is no longer required,
the receiving GIMPS node would have to ensure that no other peers
(e.g. supporting different signaling applications) might generate
messages of their own still needing the state. In addition, it is not
clear how useful it is to remove GIMPS state promptly, since
maintaining it only requires table storage without retention of any
actual network resources.
8.9 Datagram Mode Retries and Single Shot Message Support
The GIMPS-query and GIMPS-response messages may suffer from message
Schulzrinne & Hancock Expires April 19, 2004 [Page 45]
Internet-Draft GIMPS October 2003
loss (e.g. due to congestion or corruption). Because a successful
handshake is necessary before a messaging association can even be
initiated, GIMPS must provide its own recovery method for these
cases. A working assumption is that the querying node can repeat the
GIMPS-query with an exponential backoff until a response is received
or some retry threshold is reached.
The same technique could be used by the GIMPS layer to provide a
'low-cost' reliable message transfer service, restricted to short
messages, without incurring the cost of setting up a messaging
association. (If a messaging association exists, it will often be
cheaper to discover and use that.) Providing such a service would
require some minor extensions to the basic GIMPS protocol. It isn't
clear if this additional option fills an important gap in the
spectrum between datagram and connection mode message transfer.
8.10 GIMPS Support for Message Scoping
Many signaling applications are interested in sending messages over a
specific region of the network. Message scoping of this nature seems
to be hard to achieve in a topologically robust way, because such
region boundaries are not well defined in the network layer.
It may be that the GIMPS layer can assist such scoping, by detecting
and counting different types of nodes in the signaling plane. The
simplest solution would be to count GIMPS nodes supporting the
relevant signaling application - this is already effectively done by
the GIMPS hop count. A more sophisticated approach would be to track
the crossing of aggregation region boundaries, as introduced in
Section 8.4. Whether this is plausible depends on the willingness of
operators to configure such boundary information in their routers.
8.11 Mandatory or Optional Reverse Routing State
Reverse routing state (i.e. the upstream peer addressing information
in the routing state table) is installed per-flow when receiving a
downstream datagram mode message containing an addressing information
payload for the signaling source.
Technically, the presence of this payload (and hence the installation
of the state) is optional. This allows for very lightweight sending
of multi-hop downstream signaling messages (even all the way from
flow sender to flow receiver) because no state needs to be installed
or managed by GIMPS at the intermediate nodes. However, this rules
out the possibility of any downstream node sending signaling
responses (including error messages) directly upstream; they have to
be sent via the flow endpoints, leading to additional processing
there, as well as more complex security considerations.
Schulzrinne & Hancock Expires April 19, 2004 [Page 46]
Internet-Draft GIMPS October 2003
It is possible that the requirement for lightweight intermediate
nodes can be better matched by using one of the tunnelled
encapsulations described in Section 5.3. This would allow for a
restricted subset of processing at the intermediate nodes, while
still allowing the use of bidirectional communication between the
'outer' GIMPS peers, including reverse routing state at the
downstream one. This would eliminate the complexity of considering
reverse routing state maintenance as optional.
8.12 Additional Discovery Mechanisms
The routing state maintenance procedures described in Section 4.3 are
strongly focussed on the problem of discovering, implicitly or
explicitly, the neighbouring peers on the flow path - which is the
necessary functionality for path-coupled signaling.
As well as the GIMPS-query/response discovery mechanism, other
techniques may sometimes also be possible. For example, in many
environments, a host has a single access router, i.e. the downstream
peer (for outgoing flows) and the upstream peer (for incoming ones)
are known a priori. More generally, a link state routing protocol
database can be analysed to determine downstream peers in more
complex topologies, and maybe upstream ones if strict ingress
filtering is in effect. More radically, much of the GIMPS protocol is
unchanged if we consider off-path signaling nodes, although there are
significant differences in some of the security analysis (Section
7.3). However, none of these possibilities are considered further in
this specification.
8.13 Protocol Design Details
Clearly, not all details of GIMPS operation have been defined so far.
This section provides a list of slightly non-trivial areas where more
detail is need, where these have not been mentioned elsewhere in the
text.
o Datagram mode still requires (primitive) transport functions for
backoff on retransmission and rate limiting in general.
o Processing of the GIMPS hop count and IP TTL needs to be
clarified, especially for messages which are being bypassed
without going through full GIMPS processing.
o Receiver initiated signaling applications need to have reverse
path state set up in the network. Should this be done by GIMPS
carrying out the discovery for the specific signaling application
(which requires the flow sender to know what signaling
applications are going to be used), or should the discovery
Schulzrinne & Hancock Expires April 19, 2004 [Page 47]
Internet-Draft GIMPS October 2003
attempt to find every GIMPS node and the signaling applications
they support?
Schulzrinne & Hancock Expires April 19, 2004 [Page 48]
Internet-Draft GIMPS October 2003
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] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
2711, October 1999.
[4] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[5] 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.
[6] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-04 (work in progress), July 2003.
[7] Stewart, R., "SCTP Partial Reliability Extension",
draft-ietf-tsvwg-prsctp-01 (work in progress), August 2003.
Schulzrinne & Hancock Expires April 19, 2004 [Page 49]
Internet-Draft GIMPS October 2003
Informative References
[8] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[9] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
[10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[11] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[12] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[13] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[14] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
[15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[16] 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.
[17] 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.
[18] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-04 (work in progress), September 2003.
[19] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-02 (work in progress), July 2003.
[20] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work
in progress), July 2003.
[21] Bound, J., "Dual Stack Transition Mechanism",
Schulzrinne & Hancock Expires April 19, 2004 [Page 50]
Internet-Draft GIMPS October 2003
draft-bound-dstm-exp-00 (work in progress), August 2003.
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
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 April 19, 2004 [Page 51]
Internet-Draft GIMPS October 2003
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: Bob Braden, Xiaoming Fu, Ruediger Geib, Eleanor
Hepworth, Georgios Karagiannis, John Loughney, Jukka Manner, Andrew
McDonald, Charles Shen, Melinda Shore, Mike Thomas, Hannes
Tschofenig, Sven van den Bosch, and Lars Westberg. We look forward to
inputs and comments from many more in the future.
Schulzrinne & Hancock Expires April 19, 2004 [Page 52]
Internet-Draft GIMPS October 2003
Appendix B. Example Routing State Table
Figure 9 shows a signaling scenario for a single flow being managed
by two signaling applications. 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 9: A Signaling Scenario
+------------+------------+-------------+-------------+-------------+
| Flow | Session ID | Signaling | Upstream | Downstream |
| Routing | | Application | Peer | Peer |
| Informatio | | | | |
| n | | | | |
+------------+------------+-------------+-------------+-------------+
| {IP-#A, | 0xABCDEF | NSLP1 | IP-#A | (null) |
| IP-#E, | | | | |
| protocol & | | | | |
| ports} | | | | |
| | | | | |
| {IP-#A, | 0x123456 | NSLP2 | IP-#A | Pointer to |
| IP-#E, | | | | B-D |
| protocol & | | | | messaging |
| ports} | | | | association |
+------------+------------+-------------+-------------+-------------+
The table shows the routing state at Node B for the single flow from
A to E. The upstream state is just the same address for each
application. For the downstream case, NSLP1 only requires datagram
mode messages and so no explicit routing state towards C is needed.
NSLP2 requires a messaging association for its messages, and node C
has elected to bypass the GIMPS-query/response exchange, so the
downstream 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
flow routing information); routing state is stored only for adjacent
peers.
Schulzrinne & Hancock Expires April 19, 2004 [Page 53]
Internet-Draft GIMPS October 2003
Appendix C. Connection Mode Messaging Association Configurations
Figure 10 shows a segment of a path between flow sender and receiver
(not shown). Nodes A and F are GIMPS nodes which also fully process
NSLP1. They need to carry out relatively complex negotiations, maybe
exchanging large messages or requiring a secured channel. There are
several other nodes on the path between them:
o Node B is GIMPS aware but only processes NSLP2;
o Node C is a GIMPS aware NAT (see Section 6.4) but processes no
signaling applications;
o Node D is a router;
o Node E processes a subset of NSLP1 (e.g. insertion of local
resource availability status for use by Node F).
A B C D E F
+-----+ +-----+ +-----+ +-----+ +-----+
|NSLP1| | | | | +-+ |NSLP1| |NSLP1|
>>>>>| |>>>>|NSLP2|>>>>| NAT |>>>>|R|>>>>|-lite|>>>>| |>>>>>
|GIMPS| |GIMPS| |GIMPS| +-+ |GIMPS| |GIMPS|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 10: Heterogeneous Signaling
The possible messaging association arrangements depend on the
connection mode encapsulation:
Raw (as in Section 5.3.2): Messaging associations are needed from
A-C, C-E and E-F (node D is invisible to GIMPS and node B can
ignore discovery for NSLP1). Achieving properties such as
reliability or flow control or channel security between A and F
depends on the quality of implementation and trust in the
administration of nodes C and E.
Tunnelled (as in Section 5.3.3 and Section 5.3.4): There is a single
messaging association from A-F directly. C can do NAT processing
if the flow routing information is placed in the mutable area, and
E can manipulate NSLP1 objects in the mutable area also.
Schulzrinne & Hancock Expires April 19, 2004 [Page 54]
Internet-Draft GIMPS October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schulzrinne & Hancock Expires April 19, 2004 [Page 55]
Internet-Draft GIMPS October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne & Hancock Expires April 19, 2004 [Page 56]
