The purpose of this division is to provide additional flexibility in
defining the objects carried by the NSLP such that only the objects
applicable in a particular setting are used. One approach for
reflecting the distinction is that local objects could be put into
separate local messages that are initiated and terminated within one
single domain; an alternative is that they could be "stacked" within
the NSLP messages that are used anyway for inter-domain signaling.
3.3.4. Aggregation
It is a well-known problem that per-flow signaling in large-scale
networks presents scaling challenges because of the large number of
flows that may traverse individual nodes.
The possibilities for aggregation at the level of the NTLP are quite
limited; the primary scaling approach for path-coupled signaling is
for a signaling application to group flows together and to perform
signaling for the aggregate, rather than for the flows individually.
The aggregate may be created in a number of ways; for example, the
individual flows may be sent down a tunnel, or given a common
Differentiated Services Code Point (DSCP) marking. The aggregation
and de-aggregation points perform per flow signaling, but nodes
within the aggregation region should only be forced to process
signaling messages for the aggregate. This depends on the ability of
the interior nodes to ignore the per-flow signaling as discussed in
Section 3.2.3.
Individual NSLPs will need to specify what aggregation means in their
context, and how it should be performed. For example, in the QoS
context it is possible to add together the resources specified in a
number of separate reservations. In the case of other applications,
such as signaling to NATs and firewalls, the feasibility (and even
the meaning) of aggregation is less clear.
3.3.5. Peer-Peer and End-End Relationships
The assumption in this framework is that the NTLP will operate
’locally’; that is, just over the scope of a single peer
relationship. End-to-end operation is built up by concatenating
these relationships. Non-local operation (if any) will take place in
NSLPs.
The peering relations may also have an impact on the required amount
of state at each NSIS entity. When direct interaction with remote
peers is not allowed, it may be required to keep track of the path
that a message has followed through the network. This could be
achieved by keeping per-flow state at the NSIS entities, as is done
in RSVP. Another approach would be to maintain a record route object
in the messages; this object would be carried within the NSIS
protocols, rather than depend on the route-recording functionality
provided by the IP layer.
3.3.6. Acknowledgements and Notifications
We are assuming that the NTLP provides a simple message transfer
service, and that any acknowledgements or notifications it generates
are handled purely internally (and apply within the scope of a single
NTLP peer relationship).
However, we expect that some signaling applications will require
acknowledgements regarding the failure/success of state installation
along the data path, and this will be an NSLP function.
Acknowledgements can be sent along the sequence of NTLP peer
relationships towards the signaling initiator, which relieves the
requirements on the security associations that need to be maintained
by NEs and that can allow NAT traversal in both directions. (If this
direction is towards the sender, it implies maintaining reverse
routing state in the NTLP.) In certain circumstances (e.g., trusted
domains), an optimization could be to send acknowledgements directly
to the signaling initiator outside the NTLP (see Section 3.2.2),
although any such approach would have to take into account the
necessity of handling denial of service attacks launched from outside
the network.
The semantics of the acknowledgement messages are of particular
importance. An NE sending a message could assume responsibility for
the entire downstream chain of NEs, indicating (for instance) the
availability of reserved resources for the entire downstream path.
Alternatively, the message could have a more local meaning,
indicating (for instance) that a certain failure or degradation
occurred at a particular point in the network.
Notifications differ from acknowledgements because they are not
(necessarily) generated in response to other signaling messages.
This means that it may not be obvious how to determine where the
notification should be sent. Other than that, the same
considerations apply as for acknowledgements. One useful distinction
to make would be to differentiate between notifications that trigger
a signaling action and others that don’t. The security requirements
for the latter are less stringent, which means they could be sent
directly to the NE they are destined for (provided that this NE can
be determined).
3.3.7. Security and Other AAA Issues
In some cases, it will be possible to achieve the necessary level of
signaling security by using basic ’channel security’ mechanisms [11]
at the level of the NTLP, and the possibilities are described in
Section 4.7. In other cases, signaling applications may have
specific security requirements, in which case they are free to invoke
their own authentication and key exchange mechanisms and to apply
’object security’ to specific fields within the NSLP messages.
In addition to authentication, the authorization (to manipulate
network control state) has to be considered as functionality above
the NTLP level, since it will be entirely application specific.
Indeed, authorization decisions may be handed off to a third party in
the protocol (e.g., for QoS, the resource management function as
described in Section 6.1.4). Many different authorization models are
possible, and the variations impact:
o what message flows take place -- for example, whether
authorization information is carried along with a control state
modification request or is sent in the reverse direction in
response to it;
o what administrative relationships are required -- for example,
whether authorization takes place only between peer signaling
applications, or over longer distances.
Because the NTLP operates only between adjacent peers and places no
constraints on the direction or order in which signaling applications
can send messages, these authorization aspects are left open to be
defined by each NSLP. Further background discussion of this issue is
contained in [12].
4. The NSIS Transport Layer Protocol
This section describes the overall functionality required from the
NTLP. It mentions possible protocol components within the NTLP layer
and the different possible addressing modes that can be utilized, as
well as the assumed transport and state management functionality.
The interfaces between NTLP and the layers above and below it are
identified, with a description of the identity elements that appear
on these interfaces.
This discussion is not intended to design the NTLP or even to
enumerate design options, although some are included as examples.
The goal is to provide a general discussion of required functionality
and to highlight some of the issues associated with this.
4.1. Internal Protocol Components
The NTLP includes all functionality below the signaling application
layer and above the IP layer. The functionality that is required
within the NTLP is outlined in Section 3.2.4, with some more details
in Sections 3.2.5 and 4.3.
Some NTLP functionality could be provided via components operating as
sublayers within the NTLP design. For example, if specific transport
capabilities are required (such as congestion avoidance,
retransmission, and security), then existing protocols (such as
TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This
possibility is not required or excluded by this framework.
If peer-peer addressing (Section 4.2) is used for some messages, then
active next-peer discovery functionality will be required within the
NTLP to support the explicit addressing of these messages. This
could use message exchanges for dynamic peer discovery as a sublayer
within the NTLP; there could also be an interface to external
mechanisms to carry out this function.
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
Figure 6: Options for NTLP Structure
4.2. Addressing
There are two ways to address a signaling message being transmitted
between NTLP peers:
o peer-peer, where the message is addressed to a neighboring NSIS
entity that is known to be closer to the destination NE.
o end-to-end, where the message is addressed to the flow destination
directly and intercepted by an intervening NE.
With peer-peer addressing, an NE will determine the address of the
next NE based on the payload of the message (and potentially on the
previous NE). This requires that the address of the destination NE
be derivable from the information present in the payload, either by
using some local routing table or through participation in active
peer discovery message exchanges. Peer-peer addressing inherently
supports tunneling of messages between NEs, and is equally applicable
to the path-coupled and path-decoupled cases.
In the case of end-to-end addressing, the message is addressed to the
data flow receiver, and (some of) the NEs along the data path
intercept the messages. The routing of the messages should follow
exactly the same path as the associated data flow (but see
Section 5.1.1 on this point). Note that securing messages sent this
way raises some interesting security issues (these are discussed in
[2]). In addition, it is a matter of the protocol design what should
be used as the source address of the message (the flow source or
signaling source).
It is not possible at this stage to mandate one addressing mode or
the other. Indeed, each is necessary for some aspects of NTLP
operation: In particular, initial discovery of the next downstream
peer will usually require end-to-end addressing, whereas reverse
routing will always require peer-peer addressing. For other message
types, the choice is a matter of protocol design. The mode used is
not visible to the NSLP, and the information needed in each case is
available from the flow identifier (Section 4.6.1) or locally stored
NTLP state.
4.3. Classical Transport Functions
The NSIS signaling protocols are responsible for transporting
(signaling) data around the network; in general, this requires
functionality such as congestion management, reliability, and so on.
This section discusses how much of this functionality should be
provided within the NTLP. It appears that this doesn’t affect the
basic way in which the NSLP/NTLP layers relate to each other (e.g.,
in terms of the semantics of the inter-layer interaction); it is much
more a question of the overall performance/complexity tradeoff
implied by placing certain functions within each layer.
Note that, per the discussion at the end of Section 3.2.3, there may
be cases where intermediate nodes wish to modify messages in transit
even though they do not perform full signaling application
processing. In this case, not all the following functionality would
be invoked at every intermediate node.
The following functionality is assumed to lie within the NTLP:
1. Bundling together of small messages (comparable to [13]) can be
provided locally by the NTLP as an option, if desired; it doesn’t
affect the operation of the network elsewhere. The NTLP should
always support unbundling, to avoid the cost of negotiating the
feature as an option. (The related function of refresh
summarization -- where objects in a refresh message are replaced
with a reference to a previous message identifier -- is left to
NSLPs, which can then do this in a way tuned to the state
management requirements of the signaling application. Additional
transparent compression functionality could be added to the NTLP
design later as a local option.) Note that end-to-end addressed
messages for different flows cannot be bundled safely unless the
next node on the outgoing interface is known to be NSIS-aware.
2. When needed, message fragmentation should be provided by the
NTLP. The use of IP fragmentation for large messages may lead to
reduced reliability and may be incompatible with some addressing
schemes. Therefore, this functionality should be provided within
the NTLP as a service for NSLPs that generate large messages.
How the NTLP determines and accommodates Maximum Transmission
Unit (MTU) constraints is left as a matter of protocol design.
To avoid imposing the cost of reassembly on intermediate nodes,
the fragmentation scheme used should allow for the independent
forwarding of individual fragments towards a node hosting an
interested NSLP.
3. There can be significant benefits for signaling applications if
state-changing messages are delivered reliably (as introduced in
[13] for RSVP; see also the more general analysis of [14]). This
does not change any assumption about the use of soft-state by
NSLPs to manage signaling application state, and it leaves the
responsibility for detecting and recovering from application
layer error conditions in the NSLP. However, it means that such
functionality does not need to be tuned to handle fast recovery
from message loss due to congestion or corruption in the lower
layers, and it also means that the NTLP can prevent the
amplification of message loss rates caused by fragmentation.
Reliable delivery functionality is invoked by the NSLP on a
message-by-message basis and is always optional to use.
4. The NTLP should not allow signaling messages to cause congestion
in the network (i.e., at the IP layer). Congestion could be
caused by retransmission of lost signaling packets or by upper
layer actions (e.g., a flood of signaling updates to recover from
a route change). In some cases, it may be possible to engineer
the network to ensure that signaling cannot overload it; in
others, the NTLP would have to detect congestion and to adapt the
rate at which it allows signaling messages to be transmitted.
Principles of congestion control in Internet protocols are given
in [15]. The NTLP may or may not be able to detect overload in
the control plane itself (e.g., an NSLP-aware node several
NTLP-hops away that cannot keep up with the incoming message
rate) and indicate this as a flow-control condition to local
signaling applications. However, for both the congestion and
overload cases, it is up to the signaling applications themselves
to adapt their behavior accordingly.
4.4. Lower Layer Interfaces
The NTLP interacts with ’lower layers’ of the protocol stack for the
purposes of sending and receiving signaling messages. This framework
places the lower boundary of the NTLP at the IP layer. The interface
to the lower layer is therefore very simple:
o The NTLP sends raw IP packets
o The NTLP receives raw IP packets. In the case of peer-peer
addressing, they have been addressed directly to it. In the case
of end-to-end addressing, this will be achieved by intercepting
packets that have been marked in some special way (by special
protocol number or by some option interpreted within the IP layer,
such as the router alert option).
o The NTLP receives indications from the IP layer (including local
forwarding tables and routing protocol state) that provide some
information about route changes and similar events (see
Section 5.1).
For correct message routing, the NTLP needs to have some information
about link and IP layer configuration of the local networking stack.
In general, it needs to know how to select the outgoing interface for
a signaling message and where this must match the interface that will
be used by the corresponding flow. This might be as simple as just
allowing the IP layer to handle the message using its own routing
table. There is no intention to do something different from IP
routing (for end-to-end addressed messages); however, some hosts
allow applications to bypass routing for their data flows, and the
NTLP processing must account for this. Further network layer
information would be needed to handle scoped addresses (if such
things ever exist).
Configuration of lower-layer operation to handle flows in particular
ways is handled by the signaling application.
4.5. Upper Layer Services
The NTLP offers transport-layer services to higher-layer signaling
applications for two purposes: sending and receiving signaling
messages, and exchanging control and feedback information.
For sending and receiving messages, two basic control primitives are
required:
o Send Message, to allow the signaling application to pass data to
the NTLP for transport.
o Receive Message, to allow the NTLP to pass received data to the
signaling application.
The NTLP and signaling application may also want to exchange other
control information, such as the following:
o Signaling application registration/de-registration, so that
particular signaling application instances can register their
presence with the transport layer. This may also require some
identifier to be agreed upon between the NTLP and signaling
application to support the exchange of further control information
and to allow the de-multiplexing of incoming data.
o NTLP configuration, allowing signaling applications to indicate
what optional NTLP features they want to use, and to configure
NTLP operation, such as controlling what transport layer state
should be maintained.
o Error messages, to allow the NTLP to indicate error conditions to
the signaling application, and vice versa.
o Feedback information, such as route change indications so that the
signaling application can decide what action to take.
4.6. Identity Elements
4.6.1. Flow Identification
The flow identification is a method of identifying a flow in a unique
way. All packets associated with the same flow will be identified by
the same flow identifier. The key aspect of the flow identifier is
to provide enough information such that the signaling flow receives
the same treatment along the data path as the actual data itself;
i.e., consistent behavior is applied to the signaling and data flows
by a NAT or policy-based forwarding engine.
Information that could be used in flow identification may include:
o source IP address;
o destination IP address;
o protocol identifier and higher layer (port) addressing;
o flow label (typical for IPv6);
o SPI field for IPsec encapsulated data; and
o DSCP/TOS field.
It is assumed that at most limited wildcarding on these identifiers
is needed.
We assume here that the flow identification is not hidden within the
NSLP, but is explicitly part of the NTLP. The justification for this
is that being able to do NSIS processing, even at a node which was
unaware of the specific signaling application (see Section 3.2.3)
might be valuable. An example scenario would be messages passing
through an addressing boundary where the flow identification had to
be re-written.
4.6.2. Session Identification
There are circumstances in which being able to refer to signaling
application state independently of the underlying flow is important.
For example, if the address of one of the flow endpoints changes due
to a mobility event, it is desirable to be able to change the flow
identifier without having to install a completely new reservation.
The session identifier provides a method to correlate the signaling
about the different flows with the same network control state.
The session identifier is essentially a signaling application
concept, since it is only used in non-trivial state management
actions that are application specific. However, we assume here that
it should be visible within the NTLP. This enables it to be used to
control NTLP behavior; for example, by controlling how the transport
layer should forward packets belonging to this session (as opposed to
this signaling application). In addition, the session identifier can
be used by the NTLP to demultiplex received signaling messages
between multiple instances of the same signaling application, if such
an operational scenario is supported (see Section 4.6.3 for more
information on signaling application identification).
To be useful for mobility support, the session identifier should be
globally unique, and it should not be modified end-to-end. It is
well known that it is practically impossible to generate identifiers
in a way that guarantees this property; however, using a large random
number makes it highly likely. In any case, the NTLP ascribes no
valuable semantics to the identifier (such as ’session ownership’);
this problem is left to the signaling application, which may be able
to secure it to be used for this purpose.
4.6.3. Signaling Application Identification
Because the NTLP can be used to support several NSLP types, there is
a need to identify which type a particular signaling message exchange
is being used for. This is to support:
o processing of incoming messages -- the NTLP should be able to
demultiplex these towards the appropriate signaling applications;
and
o processing of general messages at an NSIS-aware intermediate node
-- if the node does not handle the specific signaling application,
it should be able to make a forwarding decision without having to
parse upper-layer information.
No position is taken on the form of the signaling application
identifier, or even the structure of the signaling application
’space’: free-standing applications, potentially overlapping groups
of capabilities, etc. These details should not influence the rest of
the NTLP design.
4.7. Security Properties
It is assumed that the only security service required within the NTLP
is channel security. Channel security requires a security
association to be established between the signaling endpoints, which
is carried out via some authentication and key management exchange.
This functionality could be provided by reusing a standard protocol.
In order to protect a particular signaling exchange, the NSIS entity
needs to select the security association that it has in place with
the next NSIS entity that will be receiving the signaling message.
The ease of doing this depends on the addressing model in use by the
NTLP (see Section 4.2).
Channel security can provide many different types of protection to
signaling exchanges, including integrity and replay protection and
encryption. It is not clear which of these is required at the NTLP
layer, although most channel security mechanisms support them all.
It is also not clear how tightly an NSLP can ’bind’ to the channel