security service provided by the NTLP.
Channel security can also be applied to the signaling messages with
differing granularity; i.e., all or parts of the signaling message
may be protected. For example, if the flow is traversing a NAT, only
the parts of the message that do not need to be processed by the NAT
should be protected. (Alternatively, if the NAT takes part in NTLP
security procedures, it only needs to be given access to the message
fields containing addresses, often just the flow id.) Which parts of
the NTLP messages need protecting is an open question, as is what
type of protection should be applied to each.
5. Interactions with Other Protocols
5.1. IP Routing Interactions
The NTLP is responsible for determining the next node to be visited
by the signaling protocol. For path-coupled signaling, this next
node should be one that will be visited by the data flow. In
practice, this peer discovery will be approximate, as any node could
use any feature of the peer discovery packet to route it differently
from the corresponding data flow packets. Divergence between the
data and signaling paths can occur due to load sharing or load
balancing (Section 5.1.1). An example specific to the case of QoS is
given in Section 6.1.1. Route changes cause a temporary divergence
between the data path and the path on which signaling state has been
installed. The occurrence, detection, and impact of route changes is
described in Section 5.1.2. A description of this issue in the
context of QoS is given in Section 6.1.2.
5.1.1. Load Sharing and Policy-Based Forwarding
Load sharing or load balancing is a network optimization technique
that exploits the existence of multiple paths to the same destination
in order to obtain benefits in terms of protection, resource
efficiency, or network stability. It has been proposed for a number
of routing protocols, such as OSPF [16] and others. In general, load
sharing means that packet forwarding will take into account header
fields in addition to the destination address; a general discussion
of such techniques and the problems they cause is provided in [17].
The significance of load sharing in the context of NSIS is that
routing of signaling messages using end-to-end addressing does not
guarantee that these messages will follow the data path. Policy-
based forwarding for data packets -- where the outgoing link is
selected based on policy information about fields additional to the
packet destination address -- has the same impact. Signaling and
data packets may diverge because of both of these techniques.
If signaling packets are given source and destination addresses
identical to data packets, signaling and data may still diverge
because of layer-4 load balancing (based on protocol or port). Such
techniques would also cause ICMP errors to be misdirected to the
source of the data because of source address spoofing. If signaling
packets are made identical in the complete 5-tuple, divergence may
still occur because of the presence of router alert options. The
same ICMP misdirection applies, and it becomes difficult for the end
systems to distinguish between data and signaling packets. Finally,
QoS routing techniques may base the routing decision on any field in
the packet header (e.g., DSCP).
5.1.2. Route Changes
In a connectionless network, each packet is independently routed
based on its header information. Whenever a better route towards the
destination becomes available, this route is installed in the
forwarding table and will be used for all subsequent (data and
signaling) packets. This can cause a divergence between the path
along which state has been installed and the path along which
forwarding will actually take place. The problem of route changes is
reduced if route pinning is performed. Route pinning refers to the
independence of the path taken by certain data packets from
reachability changes caused by routing updates from an Interior
Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).
Nothing about NSIS signaling prevents route pinning from being used
as a network engineering technique, provided that it is done in a way
that preserves the common routing of signaling and data. However,
even if route pinning is used, it cannot be depended on to prevent
all route changes (for example, in the case of link failures).
Handling route changes requires the presence of three processes in
the signaling protocol:
1. route change detection
2. installation of state on the new path
3. removal of state on the old path
Many route change detection methods can be used, some needing
explicit protocol support, and some of which are implementation-
internal. They differ in their speed of reaction and in the types of
change they can detect. In rough order of increasing applicability,
they can be summarized as follows:
1. monitoring changes in local forwarding table state
2. monitoring topology changes in a link-state routing protocol
3. inference from changes in data packet TTL
4. inference from loss of packet stream in a flow-aware router
5. inference from changes in signaling packet TTL
6. changed route of an end-to-end addressed signaling packet
7. changed route of a specific end-to-end addressed probe packet
These methods can be categorized as being based on network monitoring
(methods 1-2), on data packet monitoring (methods 3-4) and on
monitoring signaling protocol messages (methods 5-7); method 6 is the
baseline method of RSVP. The network monitoring methods can only
detect local changes; in particular, method 1 can only detect an
event that changes the immediate next downstream hop, and method 2
can only detect changes within the scope of the link-state protocol.
Methods 5-7, which are contingent on monitoring signaling messages,
become less effective as soft-state refresh rates are reduced.
When a route change has been detected, it is important that state is
installed as quickly as possible along the new path. It is not
guaranteed that the new path will be able to provide the same
characteristics that were available on the old path. To avoid
duplicate state installation or, worse, rejection of the signaling
message because of previously installed state, it is important to be
able to recognize the new signaling message as belonging to an
existing session. In this respect, we distinguish between route
changes with associated change of the flow identification (e.g., in
case of a mobility event when the IP source might change) and route
changes without change of the flow identification (e.g., in case of a
link failure along the path). The former case requires an identifier
independent from the flow identification; i.e., the session
identifier (Section 4.6.2). Mobility issues are discussed in more
detail in Section 5.2.
When state has been installed along the new path, the existing state
on the old path needs to be removed. With the soft-state principle,
this will happen automatically because of the lack of refresh
messages. Depending on the refresh timer, however, it may be
required to tear down this state much faster (e.g., because it is
tied to an accounting record). In that case, the teardown message
needs to be able to distinguish between the new path and the old
path.
In some environments, it is desirable to provide connectivity and
per-flow or per-class state management with high-availability
characteristics; i.e., with rapid transparent recovery, even in the
presence of route changes. This may require interactions with
protocols that are used to manage the routing in this case, such as
Virtual Router Redundancy Protocol (VRRP) [18].
Our basic assumption about such interactions is that the NTLP would
be responsible for detecting the route change and ensuring that
signaling messages were re-routed consistently (in the same way as
the data traffic). However, further state re-synchronization
(including failover between ’main’ and ’standby’ nodes in the high
availability case) would be the responsibility of the signaling
application and its NSLP, and would possibly be triggered by the
NTLP.
5.2. Mobility and Multihoming Interactions
The issues associated with mobility and multihoming are a
generalization of the basic route change case of the previous
section. As well as the fact that packets for a given session are no
longer traveling over a single topological path, the following extra
considerations arise:
1. The use of IP-layer mobility and multihoming means that more than
one IP source or destination address will be associated with a
single session. The same applies if application-layer solutions
(e.g., SIP-based approaches) are used.
2. Mobile IP and associated protocols use some special
encapsulations for some segments of the data path.
3. The double route may persist for some time in the network (e.g.,
in the case of a ’make-before-break’ handover being done by a
multihomed host).
4. Conversely, the re-routing may be rapid and routine (unlike
network-internal route changes), increasing the importance of
rapid state release on old paths.
The interactions between mobility and signaling have been extensively
analyzed in recent years, primarily in the context of RSVP and Mobile
IP interaction (e.g., the mobility discussion of [5]), but also in
that of other types of network (e.g., [19]). A general review of the
fundamental interactions is given in [20], which provides further
details on many of the subjects considered in this section.
We assume that the signaling will refer to ’outer’ IP headers when
defining the flows it is controlling. There are two main reasons for
this. The first is that the data plane will usually be unable to
work in terms of anything else when implementing per-flow treatment
(e.g., we cannot expect that a router will analyze inner headers to
decide how to schedule packets). The second reason is that we are
implicitly relying on the security provided by the network
infrastructure to ensure that the correct packets are given the
special treatment being signaled for, and this is built on the
relationship between packet source and destination addresses and
network topology. (This is essentially the same approach that is
used as the basis of route optimization security in Mobile IPv6
[21].) The consequence of this assumption is that we see the packet
streams to (or from) different addresses as different flows. Where a
flow is carried inside a tunnel, it is seen as a different flow
again. The encapsulation issues (point (2) above) are therefore to
be handled the same way as other tunneling cases (Section 5.4).
Therefore, the most critical aspect is that multiple flows are being
used, and the signaling for them needs to be correlated. This is the
intended role of the session identifier (see Section 4.6.2, which
also describes some of the security requirements for such an
identifier). Although the session identifier is visible at the NTLP,
the signaling application is responsible for performing the
correlation (and for doing so securely). The NTLP responsibility is
limited to delivering the signaling messages for each flow between
the correct signaling application peers. The locations at which the
correlation takes place are the end system and the signaling-
application-aware node in the network where the flows meet. (This
node is generally referred to as the "crossover router"; it can be
anywhere in the network.)
Although much work has been done in the past on finding the crossover
router directly from information held in particular mobility
signaling protocols, the initial focus of NSIS work should be a
solution that is not tightly bound to any single mobility approach.
In other words, it should be possible to determine the crossover
router based on NSIS signaling. (This doesn’t rule out the
possibility that some implementations may be able to do this
discovery faster; e.g., by being tightly integrated with local
mobility management protocols. This is directly comparable to
spotting route changes in fixed networks by being routing aware.)
Note that the crossover router discovery may involve end-to-end
signaling exchanges (especially for flows towards the mobile or
multihomed node), which raises a latency concern. On the other hand,
end-to-end signaling will have been necessary in any case, at the
application level not only to communicate changed addresses, but also
to update packet classifiers along the path. It is a matter for
further analysis to decide how these exchanges could be combined or
carried out in parallel.
On the shared part of the path, signaling is needed at least to
update the packet classifiers to include the new flow, although if
correlation with the existing flow is possible it should be possible
to bypass any policy or admission control processing. State
installation on the new path (and possibly release on the old one)
are also required. Which entity (one of the end hosts or the
crossover router) controls all these procedures depends on which
entities are authorized to carry out network state manipulations, so
this is therefore a matter of signaling application and NSLP design.
The approach may depend on the sender/receiver orientation of the
original signaling (see Section 3.3.1). In addition, in the mobility
case, the old path may no longer be directly accessible to the mobile
node; inter-access-router communication may be required to release
state in these circumstances.
The frequency of handovers in some network types makes fast handover
support protocols desirable, for selecting the optimal access router
for handover (for example, [22]), and for transferring state
information to avoid having to regenerate it in the new access router
after handover (for example, [23]). Both of these procedures could
have strong interactions with signaling protocols. The access router
selection might depend on the network control state that could be
supported on the path through the new access router. Transfer of
signaling application state or NTLP/NSLP protocol state may be a
candidate for context transfer.
5.3. Interactions with NATs
Because at least some messages will almost inevitably contain
addresses and possibly higher-layer information as payload, we must
consider the interaction with address translation devices (NATs).
These considerations apply both to ’traditional’ NATs of various
types (as defined in [24]) as well as some IPv4/v6 transition
mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25].
In the simplest case of an NSIS-unaware NAT in the path, payloads
will be uncorrected, and signaling will refer to the flow
incorrectly. Applications could attempt to use STUN [26] or similar
techniques to detect and recover from the presence of the NAT. Even
then, NSIS protocols would have to use a well-known encapsulation
(TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT
devices.
A simple ’NSIS-aware’ NAT would require flow identification
information to be in the clear and not to be integrity protected. An
alternative conceptual approach is to consider the NAT functionality
part of message processing itself, in which case the translating node
can take part natively in any NSIS protocol security mechanisms.
Depending on NSIS protocol layering, it would be possible for this
processing to be done in an NSIS entity that was otherwise ignorant
of any particular signaling applications. This is the motivation for
including basic flow identification information in the NTLP
(Section 4.6.1).
Note that all of this discussion is independent of the use of a
specific NSLP for general control of NATs (and firewalls). That case
is considered in Section 6.2.
5.4. Interactions with IP Tunneling
Tunneling is used in the Internet for a number of reasons, such as
flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
private networking, and so on. An NSIS solution must continue to
work in the presence of these techniques. The presence of the tunnel
should not cause problems for end-to-end signaling, and it should
also be possible to use NSIS signaling to control the treatment of
the packets carrying the tunneled data.
It is assumed that the NSIS approach will be similar to that of [27],
where the signaling for the end-to-end data flow is tunneled along
with that data flow and is invisible to nodes along the path of the
tunnel (other than the endpoints). This provides backwards
compatibility with networks where the tunnel endpoints do not support
the NSIS protocols. We assume that NEs will not unwrap tunnel
encapsulations to find and process tunneled signaling messages.
To signal for the packets carrying the tunneled data, the tunnel is
considered a new data flow in its own right, and NSIS signaling is
applied to it recursively. This requires signaling support in at
least one tunnel endpoint. In some cases (where the signaling
initiator is at the opposite end of the data flow from the tunnel
initiator; i.e., in the case of receiver initiated signaling), the
ability to provide a binding between the original flow identification
and that for the tunneled flow is needed. It is left open here
whether this should be an NTLP or an NSLP function.
6. Signaling Applications
This section gives an overview of NSLPs for particular signaling
applications. The assumption is that the NSLP uses the generic
functionality of the NTLP given earlier; this section describes
specific aspects of NSLP operation. It includes simple examples that
are intended to clarify how NSLPs fit into the framework. It does
not replace or even form part of the formal NSLP protocol
specifications; in particular, initial designs are being developed
for NSLPs for resource reservation [28] and middlebox communication
[29].
6.1. Signaling for Quality of Service
In the case of signaling for QoS, all the basic NSIS concepts of
Section 3.1 apply. In addition, there is an assumed directionality
of the signaling process, in that one end of the signaling flow takes
responsibility for actually requesting the resource. This leads to
the following definitions:
o QoS NSIS Initiator (QNI): the signaling entity that makes the
resource request, usually as a result of user application request.
o QoS NSIS Responder (QNR): the signaling entity that acts as the
endpoint for the signaling and that can optionally interact with
applications as well.
o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR
that propagates NSIS signaling further through the network.
Each of these entities will interact with a resource management
function (RMF) that actually allocates network resources (router
buffers, interface bandwidth, and so on).
Note that there is no constraint on which end of the signaling flow
should take the QNI role: With respect to the data flow direction, it
could be at the sending or receiving end.
6.1.1. Protocol Message Semantics
The QoS NSLP will include a set of messages to carry out resource
reservations along the signaling path. A possible set of message
semantics for the QoS NSLP is shown below. Note that the ’direction’
column in the table below only indicates the ’orientation’ of the
message. Messages can be originated and absorbed at QNF nodes as
well as the QNI or QNR; an example might be QNFs at the edge of a
domain exchanging messages to set up resources for a flow across a
it. Note that it is left open if the responder can release or modify
a reservation, during or after setup. This seems mainly a matter of
assumptions about authorization, and the possibilities might depend
on resource type specifics.
The table also explicitly includes a refresh operation. This does
nothing to a reservation except extend its lifetime, and it is one
possible state management mechanism (see next section).
+-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow |
| | | |
| Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | |
| | | |
| Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation |
| | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request |
| | | |
| Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
| | | |
| Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+
6.1.2. State Management
The primary purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in
Section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made.
There two critical issues to be considered in building a robust NSLP
to handle this problem:
o The protocol must be scalable. It should allow minimization of
the resource reservation state-storage demands that it implies for
intermediate nodes; in particular, storage of state per ’micro’
flow is likely to be impossible except at the very edge of the
network. A QoS signaling application might require per-flow or
lower granularity state; examples of each for the case of QoS
would be IntServ [30] or RMD [31] (per ’class’ state),
respectively.
o The protocol must be robust against failure and other conditions
that imply that the stored resource reservation state has to be
moved or removed.
For resource reservations, soft-state management is typically used as
a general robustness mechanism. According to the discussion of
Section 3.2.5, the soft-state protocol mechanisms are built into the
NSLP for the specific signaling application that needs them; the NTLP
sees this simply as a sequence of (presumably identical) messages.
6.1.3. Route Changes and QoS Reservations
In this section, we will explore the expected interaction between
resource signaling and routing updates (the precise source of routing
updates does not matter). The normal operation of the NSIS protocol
will lead to the situation depicted in Figure 7, where the reserved
resources match the data path.
reserved +-----+ reserved +-----+