network (determined by IP routing and other network configuration).
A flow is defined by a packet classifier (in the simplest cases, just
the destination address and topological origin are needed). In
general we assume that when discussing only the data flow path, we
only need to consider ’simple’ fixed classifiers (e.g., IPv4 5-tuple
or equivalent).
A session is an application layer concept for an exchange of packets
between two endpoints, for which some network state is to be
allocated or monitored. In simple cases, a session may map to a
specific flow; however, signaling applications are allowed to create
more flexible flow:session relationships. (Note that this concept of
’session’ is different from that of RSVP, which defines a session as
a flow with a specific destination address and transport protocol.
The NSIS usage is closer to the session concepts of higher-layer
protocols.)
The simplest service provided by NSIS signaling protocols is the
management of network control state at the level of a specific flow,
as described in the previous subsection. In particular, it should be
possible to monitor routing updates as they change the path taken by
a flow and, for example, update network state appropriately. This is
no different from the case for RSVP (local path repair). Where there
is a 1:1 flow:session relationship, this is all that is required.
However, for some more complex scenarios (especially mobility and
multihoming related ones; see [1] and the mobility discussion of
[5]), it is desirable to update the flow:session mapping during the
session lifetime. For example, a new flow can be added, and the old
one deleted (and maybe in that order, for a ’make-before-break’
handover), effectively transferring the network control state between
data flows to keep it associated with the same session. Such updates
are best managed by the end systems (generally, systems that
understand the flow:session mapping and are aware of the packet
classifier change). To enable this, it must be possible to relate
signaling messages to sessions as well as to data flows. A session
identifier (Section 4.6.2) is one component of the solution.
3.2. Layer Model for the Protocol Suite
3.2.1. Layer Model Overview
In order to achieve a modular solution for the NSIS requirements, the
NSIS protocol suite will be structured in two layers:
o a ’signaling transport’ layer, responsible for moving signaling
messages around, which should be independent of any particular
signaling application; and
o a ’signaling application’ layer, which contains functionality such
as message formats and sequences, specific to a particular
signaling application.
For the purpose of this document, we use the term ’NSIS Transport
Layer Protocol’ (NTLP) to refer to the component that will be used in
the transport layer. We also use the term ’NSIS Signaling Layer
Protocol’ (NSLP) to refer generically to any protocol within the
signaling application layer; in the end, there will be several NSLPs,
largely independent of each other. These relationships are
illustrated in Figure 4. Note that the NTLP may or may not have an
interesting internal structure (e.g., including existing transport
protocols), but that is not relevant at this level of description.
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| +-----------------+ | for ... |
V +-----------------+
=============================================
NSIS ^ +--------------------------------+
Transport | | NSIS Transport Layer Protocol |
Layer V +--------------------------------+
=============================================
+--------------------------------+
. IP and lower layers .
. .
Figure 4: NSIS Protocol Components
Note that not every generic function has to be located in the NTLP.
Another option would be to have re-usable components within the
signaling application layer. Functionality within the NTLP should be
restricted to what interacts strongly with other transport and
lower-layer operations.
3.2.2. Layer Split Concept
This section describes the basic concepts underlying the
functionality of the NTLP. First, we make a working assumption that
the protocol mechanisms of the NTLP operate only between adjacent NEs
(informally, the NTLP is a ’hop-by-hop’ protocol), whereas any
larger-scope issues (including e2e aspects) are left to the upper
layers.
The way in which the NTLP works can be described as follows: When a
signaling message is ready to be sent from one NE, it is given to the
NTLP along with information about what flow it is for; it is then up
to the NTLP to get it to the next NE along the path (upstream or
downstream), where it is received and the responsibility of the NTLP
ends. Note that there is no assumption here about how the messages
are actually addressed (this is a protocol design issue, and the
options are outlined in Section 4.2). The key point is that the NTLP
for a given NE does not use any knowledge about addresses,
capabilities, or status of any NEs other than its direct peers.
The NTLP in the receiving NE either forwards the message directly or,
if there is an appropriate signaling application locally, passes it
upwards for further processing; the signaling application can then
generate another message to be sent via the NTLP. In this way,
larger-scope (including end-to-end) message delivery is achieved.
This definition relates to NTLP operation. It does not restrict the
ability of an NSLP to send messages by other means. For example, an
NE in the middle or end of the signaling path could send a message
directly to the other end as a notification or acknowledgement of
some signaling application event. However, the issues in sending
such messages (endpoint discovery, security, NAT traversal, and so
on) are so different from the direct peer-peer case that there is no
benefit in extending the NTLP to include such non-local
functionality. Instead, an NSLP that requires such messages and
wants to avoid traversing the path of NEs should use some other
existing transport protocol. For example, UDP or DCCP would be a
good match for many of the scenarios that have been proposed.
Acknowledgements and notifications of this type are considered
further in Section 3.3.6.
One motivation for restricting the NTLP to peer-relationship scope is
that if there are any options or variants in design approach -- or,
worse, in basic functionality -- it is easier to manage the resulting
complexity if it only impacts direct peers rather than potentially
the whole Internet.
3.2.3. Bypassing Intermediate Nodes
Because the NSIS problem includes multiple signaling applications, it
is very likely that a particular NSLP will only be implemented on a
subset of the NSIS-aware nodes on a path, as shown in Figure 5. In
addition, a node inside an aggregation region will still wish to
ignore signaling messages that are per-flow, even if they are for a
signaling application that the node is generally able to process.
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs
Where signaling messages traverse such NSIS-aware intermediate nodes,
it is desirable to process them at the lowest level possible (in
particular, on the fastest path). In order to offer a non-trivial
message transfer service (in terms of security, reliability and so
on) to the peer NSLP nodes, it is important that the NTLP at
intermediate nodes is as transparent as possible; that is, it carries
out minimal processing. In addition, if intermediate nodes have to
do slow-path processing of all NSIS messages, this eliminates many of
the scaling benefits of aggregation, unless tunneling is used.
Considering first the case of messages sent with the router alert
option, there are two complementary methods to achieve this bypassing
of intermediate NEs:
o At the IP layer, a set of protocol numbers or a range of values in
the router alert option can be used. In this way, messages can be
marked with an implied granularity, and routers can choose to
apply further slow-path processing only to configured subsets of
messages. This is the method used in [10] to distinguish per-flow
and per-aggregate signaling.
o The NTLP could process the message but determine that there was no
local signaling application it was relevant to. At this stage,
the message can be returned unchanged to the IP layer for normal
forwarding; the intermediate NE has effectively chosen to be
transparent to the message in question.
In both cases, the existence of the intermediate NE is totally hidden
from the NSLP nodes. If later stages of the signaling use directly
addressed messages (e.g., for reverse routing), they will not involve
the intermediate NE at all, except perhaps as a normal router.
There may be cases where the intermediate NE would like to do some
restricted protocol processing, such as the following:
o Translating addresses in message payloads (compare Section 4.6.1);
note that this would have to be done to messages passing in both
directions through a node.
o Updating signaling application payloads with local status
information (e.g., path property measurement inside a domain).
If this can be done without fully terminating the NSIS protocols, it
would allow a more lightweight implementation of the intermediate NE,
and a more direct ’end-to-end’ NTLP association between the peer
NSLPs where the signaling application is fully processed. On the
other hand, this is only possible with a limited class of possible
NTLP designs, and makes it harder for the NTLP to offer a security
service (since messages have to be partially protected). The
feasibility of this approach will be evaluated during the NTLP
design.
3.2.4. Core NSIS Transport Layer Functionality
This section describes the basic functionality to be supported by the
NTLP. Note that the overall signaling solution will always be the
result of joint operation of both the NTLP and the signaling layer
protocols (NSLPs); for example, we can always assume that an NSLP is
operating above the NTLP and taking care of end-to-end issues (e.g.,
recovery of messages after restarts).
Therefore, NTLP functionality is essentially just efficient upstream
and downstream peer-peer message delivery, in a wide variety of
network scenarios. Message delivery includes the act of locating
and/or selecting which NTLP peer to carry out signaling exchanges
with for a specific data flow. This discovery might be an active
process (using specific signaling packets) or a passive process (a
side effect of using a particular addressing mode). In addition, it
appears that the NTLP can sensibly carry out many of the functions
that enable signaling messages to pass through middleboxes, since
this is closely related to the problem of routing the signaling
messages in the first place. Further details about NTLP
functionality are contained in Sections 3.2.5 and 4.3.
3.2.5. State Management Functionality
Internet signaling requires the existence and management of state
within the network for several reasons. This section describes how
state management functionality is split across the NSIS layers.
(Note that how the NTLP internal state is managed is a matter for its
design and indeed implementation.)
1. Conceptually, the NTLP provides a uniform message delivery
service. It is unaware of the difference in state semantics
between different types of signaling application messages (e.g.,
whether a message changes, just refreshes signaling application
state, or even has nothing to with signaling application state at
all).
2. An NTLP instance processes and, if necessary, forwards all
signaling application messages "immediately". (It might offer
different service classes, but these would be distinguished by,
for example, reliability or priority, not by state aspects.)
This means that the NTLP does not know explicit timer or message
sequence information for the signaling application; and that
signaling application messages pass immediately through an
NSLP-unaware node. (Their timing cannot be jittered there, nor
can messages be stored up to be re-sent on a new path in case of
a later re-routing event.)
3. Within any node, it is an implementation decision whether to
generate/jitter/filter refreshes separately within each signaling
application that needs this functionality, or to integrate it
with the NTLP implementation as a generic "soft-state management
toolbox". The choice doesn’t affect the NTLP specification at
all. Implementations might piggyback NTLP soft-state refresh
information (if the NTLP works this way) on signaling application
messages, or they might even combine soft-state management
between layers. The state machines of the NTLP and NSLPs remain
logically independent, but an implementation is free to allow
them to interact to reduce the load on the network to the same
level that would be achieved by a monolithic model.
4. It may be helpful for signaling applications to receive
state-management related ’triggers’ from the NTLP indicating that
a peer has failed or become available ("down/up notifications").
These triggers would be about adjacent NTLP peers, rather than
signaling application peers. We can consider this another case
of route change detection/notification (which the NTLP is also
allowed to do anyway). However, apart from generating such
triggers, the NTLP takes no action itself on such events, other
than to ensure that subsequent signaling messages are routed
correctly.
5. The existence of these triggers doesn’t replace NSLP refreshes as
the mechanism for maintaining liveness at the signaling
application level. In this sense, up/down notifications are
advisories that allow faster reaction to events in the network,
but that shouldn’t be built into NSLP semantics. (This is
essentially the same distinction, with the same rationale, that
SNMP makes between notifications and normal message exchanges.)
3.2.6. Path-Decoupled Operation
Path-decoupled signaling is defined as signaling for state
installation along the data path, without the restriction of passing
only through nodes that are located on the data path. Signaling
messages can be routed to nodes that are off the data path, but that
are (presumably) aware of it. This allows a looser coupling between
signaling and data plane nodes (e.g., at the autonomous system
level). Although support for path-decoupled operation is not one of
the initial goals of the NSIS work, this section is included for
completeness and to capture some initial considerations for future
reference.
The main advantages of path-decoupled signaling are ease of
deployment and support of additional functionality. The ease of
deployment comes from a restriction of the number of impacted nodes
in case of deployment and/or upgrade of an NSLP. Path-decoupled
signaling would allow, for instance, deploying a solution without
upgrading any of the routers in the data plane. Additional
functionality that can be supported includes the use of off-path
proxies to support authorization or accounting architectures.
There are potentially significant differences in the way that the two
signaling paradigms should be analyzed. Using a single centralized
off-path NE may increase the requirements in terms of message
handling; on the other hand, path-decoupled signaling is equally
applicable to distributed off-path entities. Failure recovery
scenarios need to be analyzed differently because fate-sharing
between data and control planes can no longer be assumed.
Furthermore, the interpretation of sender/receiver orientation
becomes less natural. With the local operation of the NTLP, the
impact of path-decoupled signaling on the routing of signaling
messages is presumably restricted to the problem of peer
determination. The assumption that the off-path NSIS nodes are
loosely tied to the data path suggests, however, that peer
determination can still be based on L3 routing information. This
means that a path-decoupled signaling solution could be implemented
using a lower-layer protocol presenting the same service interface to
NSLPs as the path-coupled NTLP. A new message transport protocol
(possibly derived from the path-coupled NTLP) would be needed, but
NSLP specifications and the inter-layer interaction would be
unchanged from the path-coupled case.
3.3. Signaling Application Properties
It is clear that many signaling applications will require specific
protocol behavior in their NSLP. This section outlines some of the
options for NSLP behavior; further work on selecting from these
options would depend on detailed analysis of the signaling
application in question.
3.3.1. Sender/Receiver Orientation
In some signaling applications, a node at one end of the data flow
takes responsibility for requesting special treatment (such as a
resource reservation) from the network. Which end may depend on the
signaling application, or on characteristics of the network
deployment.
In a sender-initiated approach, the sender of the data flow requests
and maintains the treatment for that flow. In a receiver-initiated
approach, the receiver of the data flow requests and maintains the
treatment for that flow. The NTLP itself has no freedom in this
area: Next NTLP peers have to be discovered in the sender-to-receiver
direction, but after that the default assumption is that signaling is
possible both upstream and downstream (unless a signaling application
specifically indicates that this is not required). This implies that
backward routing state must be maintained by the NTLP or that
backward routing information must be available in the signaling
message.
The sender- and receiver-initiated approaches have several
differences in their operational characteristics. The main ones are
as follows:
o In a receiver-initiated approach, the signaling messages traveling
from the receiver to the sender must be backward routed such that
they follow exactly the same path as was followed by the signaling
messages belonging to the same flow traveling from the sender to
the receiver. In a sender-initiated approach, provided that
acknowledgements and notifications can be delivered securely to
the sending node, backward routing is not necessary, and nodes do
not have to maintain backward routing state.
o In a sender-initiated approach, a mobile node can initiate a
reservation for its outgoing flows as soon as it has moved to
another roaming subnetwork. In a receiver-initiated approach, a
mobile node has to inform the receiver about its handover, thus
allowing the receiver to initiate a reservation for these flows.
For incoming flows, the reverse argument applies.
o In general, setup and modification will be fastest if the node
responsible for authorizing these actions can initiate them
directly within the NSLP. A mismatch between authorizing and
initiating NEs will cause additional message exchanges, either in
the NSLP or in a protocol executed prior to NSIS invocation.
Depending on how the authorization for a particular signaling
application is done, this may favor either sender- or receiver-
initiated signaling. Note that this may complicate modification
of network control state for existing flows.
3.3.2. Uni- and Bi-Directional Operation
For some signaling applications and scenarios, signaling may only be
considered for a unidirectional data flow. However, in other cases,
there may be interesting relationships in the signaling between the
two flows of a bi-directional session; an example is QoS for a voice
call. Note that the path in the two directions may differ due to
asymmetric routing. In the basic case, bi-directional signaling can
simply use a separate instance of the same signaling mechanism in
each direction.
In constrained topologies where parts of the route are symmetric, it
may be possible to use a more unified approach to bi-directional
signaling; e.g., carrying the two signaling directions in common
messages. This optimization might be used for example to make mobile
QoS signaling more efficient.
In either case, the correlation of the signaling for the two flow
directions is carried out in the NSLP. The NTLP would simply be
enabled to bundle the messages together.
3.3.3. Heterogeneous Operation
It is likely that the appropriate way to describe the state for which
NSIS is signaling will vary from one part of the network to another
(depending on the signaling application). For example, in the QoS
case, resource descriptions that are valid for inter-domain links
will probably be different from those useful for intra-domain
operation (and the latter will differ from one domain to another).
One way to address this issue is to consider the state description
used within the NSLP as carried in globally-understood objects and
locally-understood objects. The local objects are only applicable
for intra-domain signaling, while the global objects are mainly used
in inter-domain signaling. Note that the local objects are still
part of the protocol but are inserted, used, and removed by one
single domain.