Request for Comments: 4080 Siemens/RMR
Category: Informational G. Karagiannis
University of Twente/Ericsson
J. Loughney
Nokia
S. Van den Bosch
Alcatel
June 2005
Next Steps in Signaling (NSIS): Framework
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Next Steps in Signaling (NSIS) working group is considering
protocols for signaling information about a data flow along its path
in the network. The NSIS suite of protocols is envisioned to support
various signaling applications that need to install and/or manipulate
such state in the network. Based on existing work on signaling
requirements, this document proposes an architectural framework for
these signaling protocols.
This document provides a model for the network entities that take
part in such signaling, and for the relationship between signaling
and the rest of network operation. We decompose the overall
signaling protocol suite into a generic (lower) layer, with separate
upper layers for each specific signaling application.
Table of Contents
1. Introduction ....................................................3
1.1. Definition of the Signaling Problem ........................3
1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1. Fundamental Signaling Concepts .............................6
3.1.1. Simple Network and Signaling Topology ...............6
3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4. Signaling Messages and Network Control State .......10
3.1.5. Data Flows and Sessions ............................10
3.2. Layer Model for the Protocol Suite ........................11
3.2.1. Layer Model Overview ...............................11
3.2.2. Layer Split Concept ................................12
3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5. State Management Functionality .....................16
3.2.6. Path-Decoupled Operation ...........................17
3.3. Signaling Application Properties ..........................18
3.3.1. Sender/Receiver Orientation ........................18
3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3. Heterogeneous Operation ............................19
3.3.4. Aggregation ........................................20
3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6. Acknowledgements and Notifications .................21
3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol ..............................23
4.1. Internal Protocol Components ..............................23
4.2. Addressing ................................................24
4.3. Classical Transport Functions .............................24
4.4. Lower Layer Interfaces ....................................26
4.5. Upper Layer Services ......................................27
4.6. Identity Elements .........................................28
4.6.1. Flow Identification ................................28
4.6.2. Session Identification .............................28
4.6.3. Signaling Application Identification ...............29
4.7. Security Properties .......................................30
5. Interactions with Other Protocols ..............................30
5.1. IP Routing Interactions ...................................30
5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2. Route Changes ......................................31
5.2. Mobility and Multihoming Interactions .....................33
5.3. Interactions with NATs ....................................36
5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications .........................................37
6.1. Signaling for Quality of Service ..........................37
6.1.1. Protocol Message Semantics .........................38
6.1.2. State Management ...................................39
6.1.3. Route Changes and QoS Reservations .................39
6.1.4. Resource Management Interactions ...................41
6.2. Other Signaling Applications ..............................42
7. Security Considerations ........................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
1. Introduction
1.1. Definition of the Signaling Problem
The Next Steps in Signaling (NSIS) working group is considering
protocols for signaling information about a data flow along its path
in the network.
It is assumed that the path taken by the data flow is already
determined by network configuration and routing protocols,
independently of the signaling itself; that is, signaling to set up
the routes themselves is not considered. Instead, the signaling
simply interacts with nodes along the data flow path. Additional
simplifications are that the actual signaling messages pass directly
through these nodes themselves (i.e., the ’path-coupled’ case; see
Section 3.1.2) and that only unicast data flows are considered.
The signaling problem in this sense is very similar to that addressed
by RSVP. However, there are two generalizations. First, the
intention is that components of the NSIS protocol suite will be
usable in different parts of the Internet, for different needs,
without requiring a complete end-to-end deployment (in particular,
the signaling protocol messages may not need to run all the way
between the data flow endpoints).
Second, the signaling is intended for more purposes than just QoS
(resource reservation). The basic mechanism to achieve this
flexibility is to divide the signaling protocol stack into two
layers: a generic (lower) layer, and an upper layer specific to each
signaling application. The scope of NSIS work is to define both the
generic protocol and, initially, upper layers suitable for QoS
signaling (similar to the corresponding functionality in RSVP) and
middlebox signaling. Further applications may be considered later.
1.2. Scope and Structure of the NSIS Framework
The underlying requirements for signaling in the context of NSIS are
defined in [1] and a separate security threats document [2]; other
related requirements can be found in [3] and [4] for QoS/Mobility and
middlebox communication, respectively. This framework does not
replace or update these requirements. Discussions about lessons to
be learned from existing signaling and resource management protocols
are contained in separate analysis documents [5], [6].
The role of this framework is to explain how NSIS signaling should
work within the broader networking context, and to describe the
overall structure of the protocol suite itself. Therefore, it
discusses important protocol considerations such as routing,
mobility, security, and interactions with network ’resource’
management (in the broadest sense).
The basic context for NSIS protocols is given in Section 3.
Section 3.1 describes the fundamental elements of NSIS protocol
operation in comparison to RSVP [7]; in particular, Section 3.1.3
describes more general signaling scenarios, and Section 3.1.4 defines
a broader class of signaling applications for which the NSIS
protocols should be useful. The two-layer protocol architecture that
supports this generality is described in Section 3.2, and Section 3.3
gives examples of the ways in which particular signaling application
properties can be accommodated within signaling layer protocol
behavior.
The overall functionality required from the lower (generic) protocol
layer is described in Section 4. This is not intended to define the
detailed design of the protocol or even design options, although some
are described as examples. It describes the interfaces between this
lower-layer protocol and the IP layer (below) and signaling
application protocols (above), including the identifier elements that
appear on these interfaces (Section 4.6). Following this, Section 5
describes how signaling applications that use the NSIS protocols can
interact sensibly with network layer operations; specifically,
routing (and re-routing), IP mobility, and network address
translation (NAT).
Section 6 describes particular signaling applications. The example
of signaling for QoS (comparable to core RSVP QoS signaling
functionality) is given in detail in Section 6.1, which describes
both the signaling application specific protocol and example modes of
interaction with network resource management and other deployment
aspects. However, note that these examples are included only as
background and for explanation; we do not intend to define an
over-arching architecture for carrying out resource management in the
Internet. Further possible signaling applications are outlined in
Section 6.2.
2. Terminology
Classifier: an entity that selects packets based on their contents
according to defined rules.
[Data] flow: a stream of packets from sender to receiver that is a
distinguishable subset of a packet stream. Each flow is
distinguished by some flow identifier (see Section 4.6.1).
Edge node: an (NSIS-capable) node on the boundary of some
administrative domain.
Interior nodes: the set of (NSIS-capable) nodes that form an
administrative domain, excluding the edge nodes.
NSIS Entity (NE): the function within a node that implements an NSIS
protocol. In the case of path-coupled signaling, the NE will
always be on the data path.
NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS
protocol component that supports a specific signaling application.
See also Section 3.2.1.
NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS
protocol component that will support lower-layer (signaling
application-independent) functions. See also Section 3.2.1.
Path-coupled signaling: a mode of signaling in which the signaling
messages follow a path that is tied to the data messages.
Path-decoupled signaling: signaling for state manipulation related to
data flows, but only loosely coupled to the data path; e.g., at
the AS level.
Peer discovery: the act of locating and/or selecting which NSIS peer
to carry out signaling exchanges with for a specific data flow.
Peer relationship: signaling relationship between two adjacent NSIS
entities (i.e., NEs with no other NEs between them).
Receiver: the node in the network that is receiving the data packets
in a flow.
Sender: the node in the network that is sending the data packets in a
flow.
Session: application layer flow of information for which some network
control state information is to be manipulated or monitored (see
Section 3.1.5).
Signaling application: the purpose of the NSIS signaling. A
signaling application could be QoS management, firewall control,
and so on. Totally distinct from any specific user application.
3. Overview of Signaling Scenarios and Protocol Structure
3.1. Fundamental Signaling Concepts
3.1.1. Simple Network and Signaling Topology
The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state
in the network. This state is related to a data flow and is
installed and maintained on the NSIS Entities (NEs) along the data
flow path through the network; not every node has to contain an NE.
The basic protocol concepts do not depend on the signaling
application, but the details of operation and the information carried
do. This section discusses the basic entities involved with
signaling as well as interfaces between them.
Two NSIS entities that communicate directly are said to be in a ’peer
relationship’. This concept might loosely be described as an ’NSIS
hop’; however, there is no implication that it corresponds to a
single IP hop. Either or both NEs might store some state information
about the other, but there is no assumption that they necessarily
establish a long-term signaling connection between themselves.
It is common to consider a network as composed of various domains
(e.g., for administrative or routing purposes), and the operation of
signaling protocols may be influenced by these domain boundaries.
However, it seems there is no reason to expect that an ’NSIS domain’
should exactly overlap with an IP domain (AS, area), but it is likely
that its boundaries would consist of boundaries (segments) of one or
several IP domains.
Figure 1 shows a diagram of nearly the simplest possible signaling
configuration. A single data flow is running from an application in
the sender to the receiver via routers R1, R2, and R3. Each host and
two of the routers contain NEs that exchange signaling messages --
possibly in both directions -- about the flow. This scenario is
essentially the same as that considered by RSVP for QoS signaling;
the main difference is that here we make no assumptions about the
particular sequence of signaling messages that will be invoked.
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows
3.1.2. Path-Coupled and Path-Decoupled Signaling
We can consider two basic paradigms for resource reservation
signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through
NEs that are on the data path. They do not have to reach all the
nodes on the data path. (For example, there could be intermediate
signaling-unaware nodes, or the presence of proxies such as those
shown in Figure 2 could prevent the signaling from reaching the path
end points.) Between adjacent NEs, the route taken by signaling and
data might diverge. The path-coupled case can be supported by
various addressing styles, with messages either explicitly addressed
to the neighbor on-path NE, or addressed identically to the data
packets, but also with the router alert option (see [8] and [9]), and
intercepted. These cases are considered in Section 4.2. In the
second case, some network configurations may split the signaling and
data paths (see Section 5.1.1); this is considered an error case for
path-coupled signaling.
In the path-decoupled case, signaling messages are routed to nodes
(NEs) that are not assumed to be on the data path, but that are
(presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the signaling endpoints may have no
relation at all with the ultimate data sender or receiver. The
implications of path-decoupled operation for the NSIS protocols are
considered briefly in Section 3.2.6; however, the initial goal of
NSIS and this framework is to concentrate mainly on the path-coupled
case.
3.1.3. Signaling to Hosts, Networks, and Proxies
There are different possible triggers for the signaling protocols.
Among them are user applications (that are using NSIS signaling
services), other signaling applications, network management actions,
some network events, and so on. The variety of possible triggers
requires that the signaling can be initiated and terminated in the
different parts of the network: hosts, domain boundary nodes (edge
nodes), or interior domain nodes.
The NSIS protocol suite extends the RSVP model to consider this wider
variety of possible signaling exchanges. As well as the basic
end-to-end model already described, examples such as end-to-edge and
edge-to-edge can be considered. The edge-to-edge case might involve
the edge nodes communicating directly, as well as via the interior
nodes.
Although the end-to-edge (host-to-network) scenario requires only
intra-domain signaling, the other cases might need inter-domain NSIS
signaling as well if the signaling endpoints (hosts or network edges)
are connected to different domains. Depending on the trust relation
between concatenated NSIS domains, the edge-to-edge scenario might
cover a single domain or multiple concatenated NSIS domains. The
latter case assumes the existence of trust relations between domains.
In some cases, it is desired to be able to initiate and/or terminate
NSIS signaling not from the end host that sends/receives the data
flow, but from some other entities in the network that can be called
signaling proxies. There could be various reasons for this:
signaling on behalf of the end hosts that are not NSIS-aware,
consolidation of the customer accounting (authentication,
authorization) in respect to consumed application and transport
resources, security considerations, limitation of the physical
connection between host and network, and so on. This configuration
can be considered a kind of "proxy on the data path"; see Figure 2.
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Appl = signaling application
Figure 2: "On path" NSIS proxy
This configuration presents two specific challenges for the
signaling:
o A proxy that terminates signaling on behalf of the NSIS-unaware
host (or part of the network) should be able to determine that it
is the last NSIS-aware node along the path.
o Where a proxy initiates NSIS signaling on behalf of the NSIS-
unaware host, interworking with some other "local" technology
might be required (for example, to provide QoS reservation from
proxy to the end host in the case of a QoS signaling application).
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
Appl = signaling PA = Proxy for signaling
application application
Figure 3: "Off path" NSIS proxy
Another possible configuration, shown in Figure 3, is where an NE can
send and receive signaling information to a remote processor. The
NSIS protocols may or may not be suitable for this remote
interaction, but in any case it is not currently part of the NSIS
problem. This configuration is supported by considering the NE a
proxy at the signaling application level. This is a natural
implementation approach for some policy control and centralized
control architectures; see also Section 6.1.4.
3.1.4. Signaling Messages and Network Control State
The distinguishing features of the signaling supported by the NSIS
protocols are that it is related to specific flows (rather than to
network operation in general), and that it involves nodes in the
network (rather than running transparently between the end hosts).
Therefore, each signaling application (upper-layer) protocol must
carry per-flow information for the aspects of network-internal
operation that are of interest to that signaling application. An
example for the case of an RSVP-like QoS signaling application would
be state data representing resource reservations. However, more
generally, the per-flow information might be related to some other
control function in routers and middleboxes along the path. Indeed,
the signaling might simply be used to gather per-flow information,
without modifying network operation at all.
We call this information ’network control state’ generically.
Signaling messages may install, modify, refresh, or simply read this
state from network elements for particular data flows. Usually a
network element will also manage this information at the per-flow
level, although coarser-grained (’per-class’) state management is
also possible.
3.1.5. Data Flows and Sessions
Formally, a data flow is a (unidirectional) sequence of packets
between the same endpoints that all follow a unique path through the