draft-ietf-nsis-fw-07.txt   rfc4080.txt 
Next Steps in Signaling R. Hancock Network Working Group R. Hancock
Internet-Draft Siemens/RMR Request for Comments: 4080 Siemens/RMR
Expires: May 2, 2005 G. Karagiannis Category: Informational G. Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
J. Loughney J. Loughney
Nokia Nokia
S. van den Bosch S. Van den Bosch
Alcatel Alcatel
November 1, 2004 June 2005
Next Steps in Signaling: Framework
draft-ietf-nsis-fw-07
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 Next Steps in Signaling (NSIS): Framework
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2005. 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 Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Next Steps in Signaling working group is considering protocols The Next Steps in Signaling (NSIS) working group is considering
for signaling information about a data flow along its path in the protocols for signaling information about a data flow along its path
network. The NSIS suite of protocols is envisioned to support in the network. The NSIS suite of protocols is envisioned to support
various signaling applications that need to install and/or manipulate various signaling applications that need to install and/or manipulate
such state in the network. Based on on existing work on signaling such state in the network. Based on existing work on signaling
requirements, this document proposes an architectural framework for requirements, this document proposes an architectural framework for
these signaling protocols. these signaling protocols.
This document provides a model for the network entities that take This document provides a model for the network entities that take
part in such signaling, and the relationship between signaling and part in such signaling, and for the relationship between signaling
the rest of network operation. We decompose the overall signaling and the rest of network operation. We decompose the overall
protocol suite into a generic (lower) layer, with separate upper signaling protocol suite into a generic (lower) layer, with separate
layers for each specific signaling application. upper layers for each specific signaling application.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1 Definition of the Signaling Problem . . . . . . . . . . . 4 1.1. Definition of the Signaling Problem ........................3
1.2 Scope and Structure of the NSIS Framework . . . . . . . . 4 1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure . . . . 8 3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1 Fundamental Signaling Concepts . . . . . . . . . . . . . . 8 3.1. Fundamental Signaling Concepts .............................6
3.1.1 Simple Network and Signaling Topology . . . . . . . . 8 3.1.1. Simple Network and Signaling Topology ...............6
3.1.2 Path-Coupled and Path-Decoupled Signaling . . . . . . 9 3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3 Signaling to Hosts, Networks and Proxies . . . . . . . 9 3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4 Signaling Messages and Network Control State . . . . . 12 3.1.4. Signaling Messages and Network Control State .......10
3.1.5 Data Flows and Sessions . . . . . . . . . . . . . . . 13 3.1.5. Data Flows and Sessions ............................10
3.2 Layer Model for the Protocol Suite . . . . . . . . . . . . 13 3.2. Layer Model for the Protocol Suite ........................11
3.2.1 Layer Model Overview . . . . . . . . . . . . . . . . . 13 3.2.1. Layer Model Overview ...............................11
3.2.2 Layer Split Concept . . . . . . . . . . . . . . . . . 15 3.2.2. Layer Split Concept ................................12
3.2.3 Bypassing Intermediate Nodes . . . . . . . . . . . . . 16 3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4 Core NSIS Transport Layer Functionality . . . . . . . 17 3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5 State Management Functionality . . . . . . . . . . . . 18 3.2.5. State Management Functionality .....................16
3.2.6 Path De-Coupled Operation . . . . . . . . . . . . . . 19 3.2.6. Path-Decoupled Operation ...........................17
3.3 Signaling Application Properties . . . . . . . . . . . . . 20 3.3. Signaling Application Properties ..........................18
3.3.1 Sender/Receiver Orientation . . . . . . . . . . . . . 20 3.3.1. Sender/Receiver Orientation ........................18
3.3.2 Uni- and Bi-Directional Operation . . . . . . . . . . 21 3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3 Heterogeneous Operation . . . . . . . . . . . . . . . 21 3.3.3. Heterogeneous Operation ............................19
3.3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . 22 3.3.4. Aggregation ........................................20
3.3.5 Peer-Peer and End-End Relationships . . . . . . . . . 22 3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6 Acknowledgements and Notifications . . . . . . . . . . 23 3.3.6. Acknowledgements and Notifications .................21
3.3.7 Security and Other AAA Issues . . . . . . . . . . . . 24 3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol . . . . . . . . . . . . . . 25 4. The NSIS Transport Layer Protocol ..............................23
4.1 Internal Protocol Components . . . . . . . . . . . . . . . 25 4.1. Internal Protocol Components ..............................23
4.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2. Addressing ................................................24
4.3 Classical Transport Functions . . . . . . . . . . . . . . 27 4.3. Classical Transport Functions .............................24
4.4 Lower Layer Interfaces . . . . . . . . . . . . . . . . . . 28 4.4. Lower Layer Interfaces ....................................26
4.5 Upper Layer Services . . . . . . . . . . . . . . . . . . . 29 4.5. Upper Layer Services ......................................27
4.6 Identity Elements . . . . . . . . . . . . . . . . . . . . 30 4.6. Identity Elements .........................................28
4.6.1 Flow Identification . . . . . . . . . . . . . . . . . 30 4.6.1. Flow Identification ................................28
4.6.2 Session Identification . . . . . . . . . . . . . . . . 31 4.6.2. Session Identification .............................28
4.6.3 Signaling Application Identification . . . . . . . . . 31 4.6.3. Signaling Application Identification ...............29
4.7 Security Properties . . . . . . . . . . . . . . . . . . . 32 4.7. Security Properties .......................................30
5. Interactions with Other Protocols . . . . . . . . . . . . . . 33 5. Interactions with Other Protocols ..............................30
5.1 IP Routing Interactions . . . . . . . . . . . . . . . . . 33 5.1. IP Routing Interactions ...................................30
5.1.1 Load Sharing and Policy-Based Forwarding . . . . . . . 33 5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2 Route Changes . . . . . . . . . . . . . . . . . . . . 34 5.1.2. Route Changes ......................................31
5.2 Mobility and Multihoming Interactions . . . . . . . . . . 36 5.2. Mobility and Multihoming Interactions .....................33
5.3 Interactions with NATs . . . . . . . . . . . . . . . . . . 38 5.3. Interactions with NATs ....................................36
5.4 Interactions with IP Tunneling . . . . . . . . . . . . . . 38 5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications . . . . . . . . . . . . . . . . . . . . 40 6. Signaling Applications .........................................37
6.1 Signaling for Quality of Service . . . . . . . . . . . . . 40 6.1. Signaling for Quality of Service ..........................37
6.1.1 Protocol Message Semantics . . . . . . . . . . . . . . 40 6.1.1. Protocol Message Semantics .........................38
6.1.2 State Management . . . . . . . . . . . . . . . . . . . 41 6.1.2. State Management ...................................39
6.1.3 Route Changes and QoS Reservations . . . . . . . . . . 42 6.1.3. Route Changes and QoS Reservations .................39
6.1.4 Resource Management Interactions . . . . . . . . . . . 43 6.1.4. Resource Management Interactions ...................41
6.2 Other Signaling Applications . . . . . . . . . . . . . . . 44 6.2. Other Signaling Applications ..............................42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations ........................................42
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. References .....................................................43
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47 8.1. Normative References ......................................43
8.2 Informative References . . . . . . . . . . . . . . . . . . . 47 8.2. Informative References ....................................44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . 53
1. Introduction 1. Introduction
1.1 Definition of the Signaling Problem 1.1. Definition of the Signaling Problem
The Next Steps in Signaling (NSIS) working group is considering The Next Steps in Signaling (NSIS) working group is considering
protocols for signaling information about a data flow along its path protocols for signaling information about a data flow along its path
in the network. in the network.
It is assumed that the path taken by the data flow is already It is assumed that the path taken by the data flow is already
determined by network configuration and routing protocols, determined by network configuration and routing protocols,
independent of the signaling itself; that is, signaling to set up the independently of the signaling itself; that is, signaling to set up
routes themselves is not considered. Instead, the signaling simply the routes themselves is not considered. Instead, the signaling
interacts with nodes along the data flow path. Additional simply interacts with nodes along the data flow path. Additional
simplifications are that the actual signaling messages pass directly simplifications are that the actual signaling messages pass directly
through these nodes themselves (i.e. the 'path-coupled' case, see through these nodes themselves (i.e., the 'path-coupled' case; see
Section 3.1.2) and that only unicast data flows are considered. Section 3.1.2) and that only unicast data flows are considered.
The signaling problem in this sense is very similar to that addressed The signaling problem in this sense is very similar to that addressed
by RSVP. However, there are two generalizations. Firstly, the by RSVP. However, there are two generalizations. First, the
intention is that components of the NSIS protocol suite will be intention is that components of the NSIS protocol suite will be
usable in different parts of the Internet, for different needs, usable in different parts of the Internet, for different needs,
without requiring a complete end-to-end deployment (in particular, without requiring a complete end-to-end deployment (in particular,
the signaling protocol messages may not need to run all the way the signaling protocol messages may not need to run all the way
between the data flow endpoints). between the data flow endpoints).
Secondly, the signaling is intended for more purposes than just QoS Second, the signaling is intended for more purposes than just QoS
(resource reservation). The basic mechanism to achieve this (resource reservation). The basic mechanism to achieve this
flexibility is to divide the signaling protocol stack into two flexibility is to divide the signaling protocol stack into two
layers: a generic (lower) layer, and an upper layer specific to each layers: a generic (lower) layer, and an upper layer specific to each
signaling application. The scope of NSIS work is to define both the signaling application. The scope of NSIS work is to define both the
generic protocol, and, initially, upper layers suitable for QoS generic protocol and, initially, upper layers suitable for QoS
signaling (similar to the corresponding functionality in RSVP) and signaling (similar to the corresponding functionality in RSVP) and
middlebox signaling. Further applications may be considered later. middlebox signaling. Further applications may be considered later.
1.2 Scope and Structure of the NSIS Framework 1.2. Scope and Structure of the NSIS Framework
The underlying requirements for signaling in the context of NSIS are The underlying requirements for signaling in the context of NSIS are
defined in [1] and a separate security threats document [2]; other defined in [1] and a separate security threats document [2]; other
related requirements can be found in [3] and [4] for QoS/Mobility and related requirements can be found in [3] and [4] for QoS/Mobility and
middlebox communication respectively. This framework does not middlebox communication, respectively. This framework does not
replace or update these requirements. Discussions about lessons to replace or update these requirements. Discussions about lessons to
be learned from existing signaling and resource management protocols be learned from existing signaling and resource management protocols
are contained in separate analysis documents [5], [6]. are contained in separate analysis documents [5], [6].
The role of this framework is to explain how NSIS signaling should The role of this framework is to explain how NSIS signaling should
work within the broader networking context, and to describe the work within the broader networking context, and to describe the
overall structure of the protocol suite itself. Therefore, it overall structure of the protocol suite itself. Therefore, it
discusses important protocol considerations, such as routing, discusses important protocol considerations such as routing,
mobility, security, and interactions with network 'resource' mobility, security, and interactions with network 'resource'
management (in the broadest sense). management (in the broadest sense).
The basic context for NSIS protocols is given in Section 3. Section The basic context for NSIS protocols is given in Section 3.
3.1 describes the fundamental elements of NSIS protocol operation in Section 3.1 describes the fundamental elements of NSIS protocol
comparison to RSVP [7]; in particular, Section 3.1.3 describes more operation in comparison to RSVP [7]; in particular, Section 3.1.3
general signaling scenarios, and Section 3.1.4 defines a broader describes more general signaling scenarios, and Section 3.1.4 defines
class of signaling applications for which the NSIS protocols should a broader class of signaling applications for which the NSIS
be useful. The two-layer protocol architecture that supports this protocols should be useful. The two-layer protocol architecture that
generality is described in Section 3.2, and Section 3.3 gives supports this generality is described in Section 3.2, and Section 3.3
examples of the ways in which particular signaling application gives examples of the ways in which particular signaling application
properties can be accommodated within signaling layer protocol properties can be accommodated within signaling layer protocol
behavior. behavior.
The overall functionality required from the lower (generic) protocol The overall functionality required from the lower (generic) protocol
layer is described in Section 4. This is not intended to define the layer is described in Section 4. This is not intended to define the
detailed design of the protocol or even design options, although some detailed design of the protocol or even design options, although some
are described as examples. It describes the interfaces between this are described as examples. It describes the interfaces between this
lower layer protocol and the IP layer (below) and signaling lower-layer protocol and the IP layer (below) and signaling
application protocols (above), including the identifier elements that application protocols (above), including the identifier elements that
appear on these interfaces (Section 4.6). Following this, Section 5 appear on these interfaces (Section 4.6). Following this, Section 5
describes how signaling applications that use the NSIS protocols can describes how signaling applications that use the NSIS protocols can
interact sensibly with network layer operations, specifically routing interact sensibly with network layer operations; specifically,
(and re-routing), IP mobility, and network address translation. routing (and re-routing), IP mobility, and network address
translation (NAT).
Section 6 describes particular signaling applications. The example Section 6 describes particular signaling applications. The example
of signaling for QoS (comparable to core RSVP QoS signaling of signaling for QoS (comparable to core RSVP QoS signaling
functionality) is given in detail in Section 6.1, which describes functionality) is given in detail in Section 6.1, which describes
both the signaling application specific protocol and example modes of both the signaling application specific protocol and example modes of
interaction with network resource management and other deployment interaction with network resource management and other deployment
aspects. However, note that these examples are included only as aspects. However, note that these examples are included only as
background and for explanation; it is not intended to define an background and for explanation; we do not intend to define an
over-arching architecture for carrying out resource management in the over-arching architecture for carrying out resource management in the
Internet. Further possible signaling applications are outlined in Internet. Further possible signaling applications are outlined in
Section 6.2. Section 6.2.
2. Terminology 2. Terminology
Classifier: an entity which selects packets based on their contents Classifier: an entity that selects packets based on their contents
according to defined rules. according to defined rules.
[Data] flow: a stream of packets from sender to receiver which is a [Data] flow: a stream of packets from sender to receiver that is a
distinguishable subset of a packet stream. Each flow is distinguishable subset of a packet stream. Each flow is
distinguished by some flow identifier (see Section 4.6.1). distinguished by some flow identifier (see Section 4.6.1).
Edge node: an (NSIS-capable) node on the boundary of some Edge node: an (NSIS-capable) node on the boundary of some
administrative domain. administrative domain.
Interior nodes: the set of (NSIS-capable) nodes which form an Interior nodes: the set of (NSIS-capable) nodes that form an
administrative domain, excluding the edge nodes. administrative domain, excluding the edge nodes.
NSIS Entity (NE): the function within a node which implements an NSIS NSIS Entity (NE): the function within a node that implements an NSIS
protocol. In the case of path-coupled signaling, the NE will protocol. In the case of path-coupled signaling, the NE will
always be on the data path. always be on the data path.
NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS
protocol component that supports a specific signaling application. protocol component that supports a specific signaling application.
See also Section 3.2.1. See also Section 3.2.1.
NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS
protocol component that will support lower layer (signaling protocol component that will support lower-layer (signaling
application independent) functions. See also Section 3.2.1. application-independent) functions. See also Section 3.2.1.
Path-coupled signaling: a mode of signaling where the signaling Path-coupled signaling: a mode of signaling in which the signaling
messages follow a path that is tied to the data messages. messages follow a path that is tied to the data messages.
Path-decoupled signaling: signaling for state manipulation related to Path-decoupled signaling: signaling for state manipulation related to
data flows, but only loosely coupled to the data path, e.g. at data flows, but only loosely coupled to the data path; e.g., at
the AS level. the AS level.
Peer discovery: the act of locating and/or selecting which NSIS peer Peer discovery: the act of locating and/or selecting which NSIS peer
to carry out signaling exchanges with for a specific data flow. to carry out signaling exchanges with for a specific data flow.
Peer relationship: signaling relationship between two adjacent NSIS Peer relationship: signaling relationship between two adjacent NSIS
entities (i.e. NEs with no other NEs between them). entities (i.e., NEs with no other NEs between them).
Receiver: the node in the network which is receiving the data packets Receiver: the node in the network that is receiving the data packets
in a flow. in a flow.
Sender: the node in the network which is sending the data packets in Sender: the node in the network that is sending the data packets in a
a flow. flow.
Session: application layer flow of information for which some network Session: application layer flow of information for which some network
control state information is to be manipulated or monitored (see control state information is to be manipulated or monitored (see
Section 3.1.5). Section 3.1.5).
Signaling application: the purpose of the NSIS signaling: a signaling Signaling application: the purpose of the NSIS signaling. A
application could be QoS management, firewall control, and so on. signaling application could be QoS management, firewall control,
Totally distinct from any specific user application. and so on. Totally distinct from any specific user application.
3. Overview of Signaling Scenarios and Protocol Structure 3. Overview of Signaling Scenarios and Protocol Structure
3.1 Fundamental Signaling Concepts 3.1. Fundamental Signaling Concepts
3.1.1 Simple Network and Signaling Topology 3.1.1. Simple Network and Signaling Topology
The NSIS suite of protocols is envisioned to support various The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state signaling applications that need to install and/or manipulate state
in the network. This state is related to a data flow and is in the network. This state is related to a data flow and is
installed and maintained on the NSIS Entities (NEs) along the data installed and maintained on the NSIS Entities (NEs) along the data
flow path through the network; not every node has to contain an NE. flow path through the network; not every node has to contain an NE.
The basic protocol concepts do not depend on the signaling The basic protocol concepts do not depend on the signaling
application, but the details of operation and the information carried application, but the details of operation and the information carried
do. This section discusses the basic entities involved with do. This section discusses the basic entities involved with
signaling as well as interfaces between them. signaling as well as interfaces between them.
Two NSIS entities that communicate directly are said to be in a 'peer Two NSIS entities that communicate directly are said to be in a 'peer
relationship'. This concept might loosely be described as an 'NSIS relationship'. This concept might loosely be described as an 'NSIS
hop'; however, there is no implication that it corresponds to a hop'; however, there is no implication that it corresponds to a
single IP hop. Either or both NEs might store some state information single IP hop. Either or both NEs might store some state information
about the other, but there is no assumption that they necessarily about the other, but there is no assumption that they necessarily
establish a long-term signaling connection between themselves. establish a long-term signaling connection between themselves.
It is common to consider a network as composed of various domains, It is common to consider a network as composed of various domains
e.g. for administrative or routing purposes, and the operation of (e.g., for administrative or routing purposes), and the operation of
signaling protocols may be influenced by these domain boundaries. signaling protocols may be influenced by these domain boundaries.
However, it seems there is no reason to expect that an 'NSIS domain' 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 should exactly overlap with an IP domain (AS, area), but it is likely
that its boundaries would consist of boundaries (segments) of one or that its boundaries would consist of boundaries (segments) of one or
several IP domains. several IP domains.
Figure 1 shows a diagram of nearly the simplest possible signaling Figure 1 shows a diagram of nearly the simplest possible signaling
configuration. A single data flow is running from an application in 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 the sender to the receiver via routers R1, R2, and R3. Each host and
two of the routers contain NEs which exchange signaling messages - two of the routers contain NEs that exchange signaling messages --
possibly in both directions - about the flow. This scenario is possibly in both directions -- about the flow. This scenario is
essentially the same as that considered by RSVP for QoS signaling; essentially the same as that considered by RSVP for QoS signaling;
the main difference is that we make no assumptions here about the the main difference is that here we make no assumptions about the
particular sequence of signaling messages that will be invoked. particular sequence of signaling messages that will be invoked.
Sender Receiver Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+ +-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application| |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ | | +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| | | |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ | | +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+ +-----------+ +----+ +----+ +-----------+
+--+ +--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages |NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional) +--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows Figure 1: Simple Signaling and Data Flows
3.1.2 Path-Coupled and Path-Decoupled Signaling 3.1.2. Path-Coupled and Path-Decoupled Signaling
We can consider two basic paradigms for resource reservation We can consider two basic paradigms for resource reservation
signaling, which we refer to as "path-coupled" and "path-decoupled". signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through 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 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 nodes on the data path. (For example, there could be intermediate
signaling-unaware nodes, or the presence of proxies such as shown in signaling-unaware nodes, or the presence of proxies such as those
Figure 2 could prevent the signaling from reaching the path end shown in Figure 2 could prevent the signaling from reaching the path
points). Between adjacent NEs, the route taken by signaling and data end points.) Between adjacent NEs, the route taken by signaling and
might diverge. The path-coupled case can be supported by various data might diverge. The path-coupled case can be supported by
addressing styles, with messages either explicitly addressed to the various addressing styles, with messages either explicitly addressed
neighbor on-path NE, or addressed identically to the data packets but to the neighbor on-path NE, or addressed identically to the data
also with the router alert option (see [8] and [9]) and intercepted. packets, but also with the router alert option (see [8] and [9]), and
These cases are considered in Section 4.2. In the second case, some intercepted. These cases are considered in Section 4.2. In the
network configurations may split the signaling and data paths (see second case, some network configurations may split the signaling and
Section 5.1.1); this is considered an error case for path-coupled data paths (see Section 5.1.1); this is considered an error case for
signaling. path-coupled signaling.
In the path-decoupled case, signaling messages are routed to nodes In the path-decoupled case, signaling messages are routed to nodes
(NEs) which are not assumed to be on the data path, but which are (NEs) that are not assumed to be on the data path, but that are
(presumably) aware of it. Signaling messages will always be directly (presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the signaling endpoints may have no addressed to the neighbor NE, and the signaling endpoints may have no
relation at all with the ultimate data sender or receiver. The relation at all with the ultimate data sender or receiver. The
implications of path-decoupled operation for the NSIS protocols are implications of path-decoupled operation for the NSIS protocols are
considered briefly in Section 3.2.6; however, the initial goal of considered briefly in Section 3.2.6; however, the initial goal of
NSIS and this framework is to concentrate mainly on the path-coupled NSIS and this framework is to concentrate mainly on the path-coupled
case. case.
3.1.3 Signaling to Hosts, Networks and Proxies 3.1.3. Signaling to Hosts, Networks, and Proxies
There are different possible triggers for the signaling protocols. There are different possible triggers for the signaling protocols.
Among them are user applications (that are using NSIS signaling
Amongst them are user applications (that are using NSIS signaling
services), other signaling applications, network management actions, services), other signaling applications, network management actions,
some network events, and so on. The variety of possible triggers some network events, and so on. The variety of possible triggers
requires that the signaling can be initiated and terminated in the requires that the signaling can be initiated and terminated in the
different parts of the network - hosts, domain boundary nodes (edge different parts of the network: hosts, domain boundary nodes (edge
nodes) or interior domain nodes. nodes), or interior domain nodes.
The NSIS protocol suite extends the RSVP model to consider this wider The NSIS protocol suite extends the RSVP model to consider this wider
variety of possible signaling exchanges. As well as the basic variety of possible signaling exchanges. As well as the basic
end-to-end model already described, examples such as end-to-edge and 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 edge-to-edge can be considered. The edge-to-edge case might involve
the edge nodes communicating directly, as well as via the interior the edge nodes communicating directly, as well as via the interior
nodes. nodes.
While the end-to-edge (host-to-network) scenario requires only Although the end-to-edge (host-to-network) scenario requires only
intra-domain signaling, the other cases might need inter-domain NSIS intra-domain signaling, the other cases might need inter-domain NSIS
signaling as well if the signaling endpoints (hosts or network edges) signaling as well if the signaling endpoints (hosts or network edges)
are connected to different domains. Depending on the trust relation are connected to different domains. Depending on the trust relation
between concatenated NSIS domains the edge-to-edge scenario might between concatenated NSIS domains, the edge-to-edge scenario might
cover single domain or multiple concatenated NSIS domains. The cover a single domain or multiple concatenated NSIS domains. The
latter case assumes the existence of trust relations between domains. latter case assumes the existence of trust relations between domains.
In some cases it is desired to be able to initiate and/or terminate 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 NSIS signaling not from the end host that sends/receives the data
flow, but from the some other entities in the network that can be flow, but from some other entities in the network that can be called
called signaling proxies. There could be various reasons for this: signaling proxies. There could be various reasons for this:
signaling on behalf of the end hosts that are not NSIS-aware, signaling on behalf of the end hosts that are not NSIS-aware,
consolidation of the customer accounting (authentication, consolidation of the customer accounting (authentication,
authorization) in respect to consumed application and transport authorization) in respect to consumed application and transport
resources, security considerations, limitation of the physical resources, security considerations, limitation of the physical
connection between host and network and so on. This configuration connection between host and network, and so on. This configuration
can be considered as a kind of "proxy on the data path", see Figure can be considered a kind of "proxy on the data path"; see Figure 2.
2.
Proxy1 Proxy2 Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+ +------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver| |Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | | | | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+ +------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+| |+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+--+ +--+
skipping to change at page 11, line 25 skipping to change at page 9, line 25
+--+ Entity Messages (unidirectional) +--+ Entity Messages (unidirectional)
Appl = signaling application Appl = signaling application
Figure 2: "On path" NSIS proxy Figure 2: "On path" NSIS proxy
This configuration presents two specific challenges for the This configuration presents two specific challenges for the
signaling: signaling:
o A proxy that terminates signaling on behalf of the NSIS-unaware o A proxy that terminates signaling on behalf of the NSIS-unaware
host (or part of the network) should be able to make determination host (or part of the network) should be able to determine that it
that it is the last NSIS aware node along the path. is the last NSIS-aware node along the path.
o Where a proxy initiates NSIS signaling on behalf of the NSIS o Where a proxy initiates NSIS signaling on behalf of the NSIS-
unaware host, interworking with some other "local" technology unaware host, interworking with some other "local" technology
might be required, for example to provide QoS reservation from might be required (for example, to provide QoS reservation from
proxy to the end host in the case of aa QoS signaling proxy to the end host in the case of a QoS signaling application).
application.
+------+ +----+ +----+ +----+ +--------+ +------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver| |Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ | | | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| | +------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ | |+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+ +-..-+ +----+ +--------+
.. ..
.. ..
+-..-+ +-..-+
skipping to change at page 12, line 21 skipping to change at page 10, line 4
.. ..
.. ..
+-..-+ +-..-+
|Appl| |Appl|
+----+ +----+
Appl = signaling PA = Proxy for signaling Appl = signaling PA = Proxy for signaling
application application application application
Figure 3: "Off path" NSIS proxy Figure 3: "Off path" NSIS proxy
Another possible configuration, shown in Figure 3, is where an NE can Another possible configuration, shown in Figure 3, is where an NE can
send and receive signaling information to a remote processor. The send and receive signaling information to a remote processor. The
NSIS protocols may or may not be suitable for this remote NSIS protocols may or may not be suitable for this remote
interaction, but in any case it is not currently part of the NSIS interaction, but in any case it is not currently part of the NSIS
problem. This configuration is supported by considering the NE as a problem. This configuration is supported by considering the NE a
proxy at the signaling application level. This is a natural proxy at the signaling application level. This is a natural
implementation approach for some policy control and centralized implementation approach for some policy control and centralized
control architectures, see also Section 6.1.4. control architectures; see also Section 6.1.4.
3.1.4 Signaling Messages and Network Control State 3.1.4. Signaling Messages and Network Control State
The distinguishing features of the signaling supported by the NSIS The distinguishing features of the signaling supported by the NSIS
protocols are that it is related to specific flows (rather than to protocols are that it is related to specific flows (rather than to
network operation in general), and that it involves nodes in the network operation in general), and that it involves nodes in the
network (rather than running transparently between the end hosts). network (rather than running transparently between the end hosts).
Therefore, each signaling application (upper layer) protocol must Therefore, each signaling application (upper-layer) protocol must
carry per-flow information for the aspects of network-internal carry per-flow information for the aspects of network-internal
operation interesting to that signaling application. An example for operation that are of interest to that signaling application. An
the case of an RSVP-like QoS signaling application would be state example for the case of an RSVP-like QoS signaling application would
data representing resource reservations. However, more generally, be state data representing resource reservations. However, more
the per-flow information might be related to some other control generally, the per-flow information might be related to some other
function in routers and middleboxes along the path. Indeed, the control function in routers and middleboxes along the path. Indeed,
signaling might simply be used to gather per-flow information, the signaling might simply be used to gather per-flow information,
without modifying network operation at all. without modifying network operation at all.
We call this information generically 'network control state'. We call this information 'network control state' generically.
Signaling messages may install, modify, refresh, or simply read this Signaling messages may install, modify, refresh, or simply read this
state from network elements for particular data flows. Usually a state from network elements for particular data flows. Usually a
network element will also manage this information at the per-flow network element will also manage this information at the per-flow
level, although coarser-grained ('per-class') state management is level, although coarser-grained ('per-class') state management is
also possible. also possible.
3.1.5 Data Flows and Sessions 3.1.5. Data Flows and Sessions
Formally, a data flow is a (unidirectional) sequence of packets Formally, a data flow is a (unidirectional) sequence of packets
between the same endpoints which all follow a unique path through the between the same endpoints that all follow a unique path through the
network (determined by IP routing and other network configuration). network (determined by IP routing and other network configuration).
A flow is defined by a packet classifier (in the simplest cases, just A flow is defined by a packet classifier (in the simplest cases, just
the destination address and topological origin are needed). In the destination address and topological origin are needed). In
general we assume that when discussing only the data flow path, we general we assume that when discussing only the data flow path, we
only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple
or equivalent). or equivalent).
A session is an application layer concept for an exchange of packets A session is an application layer concept for an exchange of packets
between two endpoints, for which some network state is to be between two endpoints, for which some network state is to be
allocated or monitored. In simple cases, a session may map to a allocated or monitored. In simple cases, a session may map to a
specific flow; however, signaling applications are allowed to create specific flow; however, signaling applications are allowed to create
more flexible flow:session relationships. (Note that this concept of more flexible flow:session relationships. (Note that this concept of
'session' is different from RSVP, which defines a session as a flow 'session' is different from that of RSVP, which defines a session as
with a specific destination address and transport protocol. The NSIS a flow with a specific destination address and transport protocol.
usage is closer to the session concepts of higher layer protocols.) The NSIS usage is closer to the session concepts of higher-layer
protocols.)
The simplest service provided by NSIS signaling protocols is The simplest service provided by NSIS signaling protocols is the
management of network control state at the level of a specific flow, management of network control state at the level of a specific flow,
as described in the previous subsection. In particular, it should be as described in the previous subsection. In particular, it should be
possible to monitor routing updates as they change the path taken by possible to monitor routing updates as they change the path taken by
a flow and, for example, update network state appropriately. This is a flow and, for example, update network state appropriately. This is
no different from the case for RSVP (local path repair). Where there 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. is a 1:1 flow:session relationship, this is all that is required.
However, for some more complex scenarios (especially mobility and However, for some more complex scenarios (especially mobility and
multihoming related ones, see [1] and the mobility discussion of [5]) multihoming related ones; see [1] and the mobility discussion of
it is desirable to update the flow:session mapping during the session [5]), it is desirable to update the flow:session mapping during the
lifetime. For example, a new flow can be added, and the old one session lifetime. For example, a new flow can be added, and the old
deleted (and maybe in that order, for a 'make-before-break' one deleted (and maybe in that order, for a 'make-before-break'
handover), effectively transferring the network control state between handover), effectively transferring the network control state between
data flows to keep it associated with the same session. Such updates data flows to keep it associated with the same session. Such updates
are best managed by the end systems (generally, systems which are best managed by the end systems (generally, systems that
understand the flow:session mapping and are aware of the packet understand the flow:session mapping and are aware of the packet
classifier change). To enable this, it must be possible to relate classifier change). To enable this, it must be possible to relate
signaling messages to sessions as well as data flows. A session signaling messages to sessions as well as to data flows. A session
identifier (Section 4.6.2) is one component of the solution. identifier (Section 4.6.2) is one component of the solution.
3.2 Layer Model for the Protocol Suite 3.2. Layer Model for the Protocol Suite
3.2.1 Layer Model Overview 3.2.1. Layer Model Overview
In order to achieve a modular solution for the NSIS requirements, the In order to achieve a modular solution for the NSIS requirements, the
NSIS protocol suite will be structured in two layers: NSIS protocol suite will be structured in two layers:
o a 'signaling transport' layer, responsible for moving signaling o a 'signaling transport' layer, responsible for moving signaling
messages around, which should be independent of any particular messages around, which should be independent of any particular
signaling application; and signaling application; and
o a 'signaling application' layer, which contains functionality such o a 'signaling application' layer, which contains functionality such
as message formats and sequences, specific to a particular as message formats and sequences, specific to a particular
signaling application. signaling application.
For the purpose of this document, we use the term 'NSIS Transport 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 Layer Protocol' (NTLP) to refer to the component that will be used in
the transport layer. We also use the term 'NSIS Signaling Layer the transport layer. We also use the term 'NSIS Signaling Layer
Protocol' (NSLP) to refer generically to any protocol within the Protocol' (NSLP) to refer generically to any protocol within the
signaling application layer; in the end, there will be several NSLPs, signaling application layer; in the end, there will be several NSLPs,
largely independent of each other. These relationships are largely independent of each other. These relationships are
illustrated in Figure 4. Note that the NTLP may or may not have an illustrated in Figure 4. Note that the NTLP may or may not have an
interesting internal structure (e.g. including existing transport interesting internal structure (e.g., including existing transport
protocols) but that is not relevant at this level of description. protocols), but that is not relevant at this level of description.
^ +-----------------+ ^ +-----------------+
| | NSIS Signaling | | | NSIS Signaling |
| | Layer Protocol | | | Layer Protocol |
NSIS | +----------------| for middleboxes | NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+ Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling | Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol | | | for QoS | | Layer Protocol |
| +-----------------+ | for ... | | +-----------------+ | for ... |
V +-----------------+ V +-----------------+
skipping to change at page 14, line 47 skipping to change at page 12, line 31
============================================= =============================================
+--------------------------------+ +--------------------------------+
. IP and lower layers . . IP and lower layers .
. . . .
Figure 4: NSIS Protocol Components Figure 4: NSIS Protocol Components
Note that not every generic function has to be located in the NTLP. Note that not every generic function has to be located in the NTLP.
Another option would be to have re-usable components within the Another option would be to have re-usable components within the
signaling application layer. Functionality within the NTLP should be signaling application layer. Functionality within the NTLP should be
restricted to that which interacts strongly with other transport and restricted to what interacts strongly with other transport and
lower layer operations. lower-layer operations.
3.2.2 Layer Split Concept 3.2.2. Layer Split Concept
This section describes the basic concepts underlying the This section describes the basic concepts underlying the
functionality of the NTLP. Firstly, we make a working assumption functionality of the NTLP. First, we make a working assumption that
that the protocol mechanisms of the NTLP operate only between the protocol mechanisms of the NTLP operate only between adjacent NEs
adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), (informally, the NTLP is a 'hop-by-hop' protocol), whereas any
whereas any larger scope issues (including e2e aspects) are left to larger-scope issues (including e2e aspects) are left to the upper
the upper layers. layers.
The way in which the NTLP works can be described as follows: When a 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 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 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 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 downstream), where it is received and the responsibility of the NTLP
ends. Note that there is no assumption here about how the messages ends. Note that there is no assumption here about how the messages
are actually addressed (this is a protocol design issue, and the 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 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, for a given NE does not use any knowledge about addresses,
capabilities, or status of any NEs other than its direct peers. capabilities, or status of any NEs other than its direct peers.
The NTLP in the receiving NE either forwards the message directly, The NTLP in the receiving NE either forwards the message directly or,
or, if there is an appropriate signaling application locally, passes if there is an appropriate signaling application locally, passes it
it upwards for further processing; the signaling application can then upwards for further processing; the signaling application can then
generate another message to be sent via the NTLP. In this way, generate another message to be sent via the NTLP. In this way,
larger scope (including end-to-end) message delivery is achieved. larger-scope (including end-to-end) message delivery is achieved.
This definition relates to NTLP operation. It does not restrict the This definition relates to NTLP operation. It does not restrict the
ability of an NSLP to send messages by other means. For example, an 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 NE in the middle or end of the signaling path could send a message
directly to the other end as a notification of or acknowledgement for directly to the other end as a notification or acknowledgement of
some signaling application event. However, the issues in sending some signaling application event. However, the issues in sending
such messages (endpoint discovery, security, NAT traversal and so on) such messages (endpoint discovery, security, NAT traversal, and so
are so different from the direct peer-peer case that there is no on) are so different from the direct peer-peer case that there is no
benefit in extending the NTLP to include such non-local benefit in extending the NTLP to include such non-local
functionality; instead, an NSLP which requires such messages and functionality. Instead, an NSLP that requires such messages and
wants to avoid traversing the path of NEs should use some other wants to avoid traversing the path of NEs should use some other
existing transport protocol - for example, UDP or DCCP would be a existing transport protocol. For example, UDP or DCCP would be a
good match for many of the scenarios that have been proposed. good match for many of the scenarios that have been proposed.
Acknowledgements and notifications of this type are considered Acknowledgements and notifications of this type are considered
further in Section 3.3.6. further in Section 3.3.6.
One motivation for restricting the NTLP to only peer-relationship One motivation for restricting the NTLP to peer-relationship scope is
scope is that if there are any options or variants in design approach that if there are any options or variants in design approach -- or,
- or, worse, in basic functionality - it is easier to manage the worse, in basic functionality -- it is easier to manage the resulting
resulting complexity if it only impacts direct peers rather than complexity if it only impacts direct peers rather than potentially
potentially the whole Internet. the whole Internet.
3.2.3 Bypassing Intermediate Nodes 3.2.3. Bypassing Intermediate Nodes
Because the NSIS problem includes multiple signaling applications, it Because the NSIS problem includes multiple signaling applications, it
is very likely that a particular NSLP will only be implemented on a 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 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 addition, a node inside an aggregation region will still wish to
ignore signaling messages which are per-flow, even if they are for a ignore signaling messages that are per-flow, even if they are for a
signaling application which the node is able to process in general. signaling application that the node is generally able to process.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE | | NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+| |+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP|| ||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 || || 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+| |+----+| | | |+----+| |+----+|
| || | | | | | | || | | || | | | | | | || |
|+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs Figure 5: Signaling with Heterogeneous NSLPs
Where signaling messages traverse such NSIS-aware intermediate nodes, Where signaling messages traverse such NSIS-aware intermediate nodes,
it is desirable to process them at the lowest level possible (in it is desirable to process them at the lowest level possible (in
particular, on the fastest path). In order to offer a non-trivial particular, on the fastest path). In order to offer a non-trivial
message transfer service (in terms of security, reliability and so message transfer service (in terms of security, reliability and so
on) to the peer NSLP nodes, it is important that the NTLP at on) to the peer NSLP nodes, it is important that the NTLP at
intermediate nodes is as transparent as possible, that is, it carries intermediate nodes is as transparent as possible; that is, it carries
out minimal processing. In addition, if intermediate nodes have to out minimal processing. In addition, if intermediate nodes have to
do slow-path processing of all NSIS messages, this eliminates many of do slow-path processing of all NSIS messages, this eliminates many of
the scaling benefits of aggregation, unless tunneling is used. the scaling benefits of aggregation, unless tunneling is used.
Considering first the case of messages sent with the router alert Considering first the case of messages sent with the router alert
option, there are two complementary methods to achieve this bypassing option, there are two complementary methods to achieve this bypassing
of intermediate NEs: of intermediate NEs:
o At the IP layer, a set of protocol numbers can be used, or a range o At the IP layer, a set of protocol numbers or a range of values in
of values in the router alert option. In this way, messages can the router alert option can be used. In this way, messages can be
be marked with an implied granularity, and routers can choose to marked with an implied granularity, and routers can choose to
apply further slow-path processing only to configured subsets of apply further slow-path processing only to configured subsets of
messages. This is the method used in [10] to distinguish per-flow messages. This is the method used in [10] to distinguish per-flow
and per-aggregate signaling. and per-aggregate signaling.
o The NTLP could process the message but determine that there was no o The NTLP could process the message but determine that there was no
local signaling application it was relevant to. At this stage, local signaling application it was relevant to. At this stage,
the message can be returned unchanged to the IP layer for normal the message can be returned unchanged to the IP layer for normal
forwarding; the intermediate NE has effectively chosen to be forwarding; the intermediate NE has effectively chosen to be
transparent to the message in question. transparent to the message in question.
In both cases, the existence of the intermediate NE is totally hidden In both cases, the existence of the intermediate NE is totally hidden
from the NSLP nodes. If later stages of the signaling use directly from the NSLP nodes. If later stages of the signaling use directly
addressed messages (e.g. for reverse routing), they will not addressed messages (e.g., for reverse routing), they will not involve
involved the intermediate NE at all, except perhaps as a normal the intermediate NE at all, except perhaps as a normal router.
router.
There may be cases where the intermediate NE would like to do some There may be cases where the intermediate NE would like to do some
restricted protocol processing, for example: restricted protocol processing, such as the following:
o Translating addresses in message payloads (compare Section 4.6.1); o Translating addresses in message payloads (compare Section 4.6.1);
note this would have to be done to messages passing both note that this would have to be done to messages passing in both
directions through a node. directions through a node.
o Updating signaling application payloads with local status o Updating signaling application payloads with local status
information (e.g. path property measurement inside a domain). information (e.g., path property measurement inside a domain).
If this can be done without fully terminating the NSIS protocols, If this can be done without fully terminating the NSIS protocols, it
this would allow a more lightweight implementation of the would allow a more lightweight implementation of the intermediate NE,
intermediate NE, and a more direct 'end-to-end' NTLP association and a more direct 'end-to-end' NTLP association between the peer
between the peer NSLPs where the signaling application is fully NSLPs where the signaling application is fully processed. On the
processed. On the other hand, this is only possible with a limited other hand, this is only possible with a limited class of possible
class of possible NTLP designs, and makes it harder for the NTLP to NTLP designs, and makes it harder for the NTLP to offer a security
offer a security service (since messages have to be partially service (since messages have to be partially protected). The
protected). The feasibility of this approach will be evaluated feasibility of this approach will be evaluated during the NTLP
during the NTLP design. design.
3.2.4 Core NSIS Transport Layer Functionality 3.2.4. Core NSIS Transport Layer Functionality
This section describes the basic functionality to be supported by the This section describes the basic functionality to be supported by the
NTLP. Note that the overall signaling solution will always be the NTLP. Note that the overall signaling solution will always be the
result of joint operation of both the NTLP and signaling layer result of joint operation of both the NTLP and the signaling layer
protocols (NSLPs); for example, we can always assume that an NSLP is 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. operating above the NTLP and taking care of end-to-end issues (e.g.,
recovery of messages after restarts). recovery of messages after restarts).
Therefore, NTLP functionality is essentially just efficient upstream Therefore, NTLP functionality is essentially just efficient upstream
and downstream peer-peer message delivery, in a wide variety of and downstream peer-peer message delivery, in a wide variety of
network scenarios. Message delivery includes the act of locating network scenarios. Message delivery includes the act of locating
and/or selecting which NTLP peer to carry out signaling exchanges and/or selecting which NTLP peer to carry out signaling exchanges
with for a specific data flow. This discovery might be an active with for a specific data flow. This discovery might be an active
process (using specific signaling packets) or a passive process (a process (using specific signaling packets) or a passive process (a
side effect of using a particular addressing mode). In addition, it side effect of using a particular addressing mode). In addition, it
appears that the NTLP can sensibly carry out many of the functions of appears that the NTLP can sensibly carry out many of the functions
enabling signaling messages to pass through middleboxes, since this that enable signaling messages to pass through middleboxes, since
is closely related to the problem of routing the signaling messages this is closely related to the problem of routing the signaling
in the first place. Further details about NTLP functionality are messages in the first place. Further details about NTLP
contained in Section 3.2.5 and Section 4.3. functionality are contained in Sections 3.2.5 and 4.3.
3.2.5 State Management Functionality 3.2.5. State Management Functionality
Internet signaling requires the existence and management of state Internet signaling requires the existence and management of state
within the network for several reasons. This section describes how within the network for several reasons. This section describes how
state management functionality is split across the NSIS layers. state management functionality is split across the NSIS layers.
(Note that how the NTLP internal state is managed is a matter for its (Note that how the NTLP internal state is managed is a matter for its
design and indeed implementation.) design and indeed implementation.)
1. Conceptually, the NTLP provides a uniform message delivery 1. Conceptually, the NTLP provides a uniform message delivery
service. It is unaware of the difference in state semantics service. It is unaware of the difference in state semantics
between different types of signaling application message (e.g. between different types of signaling application messages (e.g.,
whether a message changes or just refreshes signaling application whether a message changes, just refreshes signaling application
state, or even has nothing to with signaling application state at state, or even has nothing to with signaling application state at
all). all).
2. An NTLP instance processes and if necessary forwards all 2. An NTLP instance processes and, if necessary, forwards all
signaling application messages "immediately". (It might offer signaling application messages "immediately". (It might offer
different service classes, but these would be distinguished e.g. different service classes, but these would be distinguished by,
by reliability or priority, not state aspects.) This means that for example, reliability or priority, not by state aspects.)
the NTLP does not know explicit timer or message sequence This means that the NTLP does not know explicit timer or message
information for the signaling application; and that signaling sequence information for the signaling application; and that
application messages pass immediately through an NSLP-unaware signaling application messages pass immediately through an
node (their timing cannot be jittered there, nor can messages be NSLP-unaware node. (Their timing cannot be jittered there, nor
stored up to be re-sent on a new paths in case of a later can messages be stored up to be re-sent on a new path in case of
re-routing event). a later re-routing event.)
3. Within any node, it is an implementation decision whether to 3. Within any node, it is an implementation decision whether to
generate/jitter/filter refreshes either separately within each generate/jitter/filter refreshes separately within each signaling
signaling application that needs this functionality, or to application that needs this functionality, or to integrate it
integrate it with the NTLP implementation as a generic with the NTLP implementation as a generic "soft-state management
"soft-state management toolbox"; the choice doesn't affect the toolbox". The choice doesn't affect the NTLP specification at
NTLP specification at all. Implementations might piggy-back NTLP all. Implementations might piggyback NTLP soft-state refresh
soft-state refresh information (if the NTLP works this way) on information (if the NTLP works this way) on signaling application
signaling application messages, or even combine soft-state messages, or they might even combine soft-state management
management between layers. The state machines of the NTLP and between layers. The state machines of the NTLP and NSLPs remain
NSLPs remain logically independent, but an implementation is free logically independent, but an implementation is free to allow
to allow them to interact to reduce the load on the network to them to interact to reduce the load on the network to the same
the same level as would be achieved by a monolithic model. level that would be achieved by a monolithic model.
4. It may be helpful for signaling applications to receive 4. It may be helpful for signaling applications to receive
state-management related 'triggers' from the NTLP, that a peer state-management related 'triggers' from the NTLP indicating that
has failed or become available ("down/up notifications"). These a peer has failed or become available ("down/up notifications").
triggers would be about adjacent NTLP peers, rather than These triggers would be about adjacent NTLP peers, rather than
signaling application peers. We can consider this as another signaling application peers. We can consider this another case
case of route change detection/notification (which the NTLP is of route change detection/notification (which the NTLP is also
also allowed to do anyway). However, apart from generating such allowed to do anyway). However, apart from generating such
triggers, the NTLP takes no action itself on such events, other triggers, the NTLP takes no action itself on such events, other
than to ensure that subsequent signaling messages are correctly than to ensure that subsequent signaling messages are routed
routed. correctly.
5. The existence of these triggers doesn't replace NSLP refreshes as 5. The existence of these triggers doesn't replace NSLP refreshes as
the mechanism for maintaining liveness at the signaling the mechanism for maintaining liveness at the signaling
application level. In this sense, up/down notifications are application level. In this sense, up/down notifications are
advisories which allow faster reaction to events in the network, advisories that allow faster reaction to events in the network,
but shouldn't be built into NSLP semantics. (This is essentially but that shouldn't be built into NSLP semantics. (This is
the same distinction - with the same rationale - as SNMP makes essentially the same distinction, with the same rationale, that
between notifications and normal message exchanges.) SNMP makes between notifications and normal message exchanges.)
3.2.6 Path De-Coupled Operation 3.2.6. Path-Decoupled Operation
Path-decoupled signaling is defined as signaling for state Path-decoupled signaling is defined as signaling for state
installation along the data path, without the restriction of passing installation along the data path, without the restriction of passing
only through nodes that are located on the data path. Signaling only through nodes that are located on the data path. Signaling
messages can be routed to nodes off the data path, but which are messages can be routed to nodes that are off the data path, but that
(presumably) aware of it. This allows a looser coupling between are (presumably) aware of it. This allows a looser coupling between
signaling and data plane nodes, e.g. at the autonomous system level. signaling and data plane nodes (e.g., at the autonomous system
Although support for path-decoupled operation is not one of the level). Although support for path-decoupled operation is not one of
initial goals of the NSIS work, this section is included for the initial goals of the NSIS work, this section is included for
completeness and to capture some initial considerations for future completeness and to capture some initial considerations for future
reference. reference.
The main advantages of path-decoupled signaling are ease of The main advantages of path-decoupled signaling are ease of
deployment and support of additional functionality. The ease of deployment and support of additional functionality. The ease of
deployment comes from a restriction of the number of impacted nodes deployment comes from a restriction of the number of impacted nodes
in case of deployment and/or upgrade of an NSLP. It would allow, for in case of deployment and/or upgrade of an NSLP. Path-decoupled
instance, deploying a solution without upgrading any of the routers signaling would allow, for instance, deploying a solution without
in the data plane. Additional functionality that can be supported upgrading any of the routers in the data plane. Additional
includes the use of off-path proxies to support authorization or functionality that can be supported includes the use of off-path
accounting architectures. proxies to support authorization or accounting architectures.
There are potentially significant differences in the way that the two There are potentially significant differences in the way that the two
signaling paradigms should be analyzed. Using a single centralized signaling paradigms should be analyzed. Using a single centralized
off-path NE may increase the requirements in terms of message off-path NE may increase the requirements in terms of message
handling; on the other hand, path-decoupled signaling is equally handling; on the other hand, path-decoupled signaling is equally
applicable to distributed off-path entities. Failure recovery applicable to distributed off-path entities. Failure recovery
scenarios need to be analyzed differently because fate-sharing scenarios need to be analyzed differently because fate-sharing
between data and control plane can no longer be assumed. between data and control planes can no longer be assumed.
Furthermore, the interpretation of sender/receiver orientation Furthermore, the interpretation of sender/receiver orientation
becomes less natural. With the local operation of the NTLP, the becomes less natural. With the local operation of the NTLP, the
impact of path-decoupled signaling on the routing of signaling impact of path-decoupled signaling on the routing of signaling
messages is presumably restricted to the problem of peer messages is presumably restricted to the problem of peer
determination. The assumption that the off-path NSIS nodes are determination. The assumption that the off-path NSIS nodes are
loosely tied to the data path suggests, however, that peer loosely tied to the data path suggests, however, that peer
determination can still be based on L3 routing information. This determination can still be based on L3 routing information. This
means that a path-decoupled signaling solution could be implemented means that a path-decoupled signaling solution could be implemented
using a lower layer protocol presenting the same service interface to using a lower-layer protocol presenting the same service interface to
NSLPs as the path-coupled NTLP. A new message transport protocol NSLPs as the path-coupled NTLP. A new message transport protocol
(possibly derived from the path-coupled NTLP) would be needed, but (possibly derived from the path-coupled NTLP) would be needed, but
NSLP specifications and the inter-layer interaction would be NSLP specifications and the inter-layer interaction would be
unchanged from the path-coupled case. unchanged from the path-coupled case.
3.3 Signaling Application Properties 3.3. Signaling Application Properties
It is clear that many signaling applications will require specific It is clear that many signaling applications will require specific
protocol behavior in their NSLP. This section outlines some of the protocol behavior in their NSLP. This section outlines some of the
options for NSLP behavior; further work on selecting from these options for NSLP behavior; further work on selecting from these
options would depend on detailed analysis of the signaling options would depend on detailed analysis of the signaling
application in question. application in question.
3.3.1 Sender/Receiver Orientation 3.3.1. Sender/Receiver Orientation
In some signaling applications, a node at one end of the data flow In some signaling applications, a node at one end of the data flow
takes responsibility for requesting special treatment - such as a takes responsibility for requesting special treatment (such as a
resource reservation - from the network. Which end may depend on the resource reservation) from the network. Which end may depend on the
signaling application, or characteristics of the network deployment. signaling application, or on characteristics of the network
deployment.
A sender-initiated approach is when the sender of the data flow In a sender-initiated approach, the sender of the data flow requests
requests and maintains the treatment for that flow. In a and maintains the treatment for that flow. In a receiver-initiated
receiver-initiated approach the receiver of the data flow requests approach, the receiver of the data flow requests and maintains the
and maintains the treatment for that flow. The NTLP itself has no treatment for that flow. The NTLP itself has no freedom in this
freedom in this area: next NTLP peers have to be discovered in the area: Next NTLP peers have to be discovered in the sender-to-receiver
sender to receiver direction, but after that time the default direction, but after that the default assumption is that signaling is
assumption is that signaling is possible both upstream and downstream possible both upstream and downstream (unless a signaling application
(unless possibly a signaling application specifically indicates this specifically indicates that this is not required). This implies that
is not required). This implies that backward routing state must be backward routing state must be maintained by the NTLP or that
maintained by the NTLP or that backward routing information must be backward routing information must be available in the signaling
available in the signaling message. message.
The sender and receiver initiated approaches have several differences The sender- and receiver-initiated approaches have several
in their operational characteristics. The main ones are as follows: differences in their operational characteristics. The main ones are
as follows:
o In a receiver-initiated approach, the signaling messages traveling o In a receiver-initiated approach, the signaling messages traveling
from the receiver to the sender must be backward routed such that from the receiver to the sender must be backward routed such that
they follow exactly the same path as was followed by the signaling they follow exactly the same path as was followed by the signaling
messages belonging to the same flow traveling from the sender to messages belonging to the same flow traveling from the sender to
the receiver. In a sender-initiated approach, provided the receiver. In a sender-initiated approach, provided that
acknowledgements and notifications can be securely delivered to acknowledgements and notifications can be delivered securely to
the sending node, backward routing is not necessary, and nodes do the sending node, backward routing is not necessary, and nodes do
not have to maintain backward routing state. not have to maintain backward routing state.
o In a sender-initiated approach, a mobile node can initiate a o In a sender-initiated approach, a mobile node can initiate a
reservation for its outgoing flows as soon as it has moved to reservation for its outgoing flows as soon as it has moved to
another roaming subnetwork. In a receiver-initiated approach, a another roaming subnetwork. In a receiver-initiated approach, a
mobile node has to inform the receiver about its handover, thus mobile node has to inform the receiver about its handover, thus
allowing the receiver to initiate a reservation for these flows. allowing the receiver to initiate a reservation for these flows.
For incoming flows, the reverse argument applies. For incoming flows, the reverse argument applies.
o In general, setup and modification will be fastest if the node o In general, setup and modification will be fastest if the node
responsible for authorizing these actions can initiate them responsible for authorizing these actions can initiate them
directly within the NSLP. A mismatch between authorizing and directly within the NSLP. A mismatch between authorizing and
initiating NEs will cause additional message exchanges either in initiating NEs will cause additional message exchanges, either in
the NSLP or in a protocol executed prior to NSIS invocation. the NSLP or in a protocol executed prior to NSIS invocation.
Depending on how the authorization for a particular signaling Depending on how the authorization for a particular signaling
application is done, this may favor either sender or receiver application is done, this may favor either sender- or receiver-
initiated signaling. Note that this may complicate modification initiated signaling. Note that this may complicate modification
of network control state for existing flows. of network control state for existing flows.
3.3.2 Uni- and Bi-Directional Operation 3.3.2. Uni- and Bi-Directional Operation
For some signaling applications and scenarios, signaling may only be For some signaling applications and scenarios, signaling may only be
considered for a unidirectional data flow. However, in other cases, considered for a unidirectional data flow. However, in other cases,
there may be interesting relationships between the signaling for the there may be interesting relationships in the signaling between the
two flows of a bi-directional session; an example is QoS for a voice 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 call. Note that the path in the two directions may differ due to
asymmetric routing. In the basic case, bi-directional signaling can asymmetric routing. In the basic case, bi-directional signaling can
simply use a separate instance of the same signaling mechanism in simply use a separate instance of the same signaling mechanism in
each direction. each direction.
In constrained topologies where parts of the route are symmetric, it In constrained topologies where parts of the route are symmetric, it
may be possible to use a more unified approach to bi-directional may be possible to use a more unified approach to bi-directional
signaling, e.g. carrying the two signaling directions in common signaling; e.g., carrying the two signaling directions in common
messages. This optimization might be used for example to make mobile messages. This optimization might be used for example to make mobile
QoS signaling more efficient. QoS signaling more efficient.
In either case, the correlation of the signaling for the two flow In either case, the correlation of the signaling for the two flow
directions is carried out in the NSLP. The NTLP would simply be directions is carried out in the NSLP. The NTLP would simply be
enabled to bundle the messages together. enabled to bundle the messages together.
3.3.3 Heterogeneous Operation 3.3.3. Heterogeneous Operation
It is likely that the appropriate way to describe the state NSIS is It is likely that the appropriate way to describe the state for which
signaling for will vary from one part of the network to another NSIS is signaling will vary from one part of the network to another
(depending on signaling application). For example in the QoS case, (depending on the signaling application). For example, in the QoS
resource descriptions that are valid for inter-domain links will case, resource descriptions that are valid for inter-domain links
probably be different from those useful for intra-domain operation will probably be different from those useful for intra-domain
(and the latter will differ from one domain to another). operation (and the latter will differ from one domain to another).
One way to address this issue is to consider the state description One way to address this issue is to consider the state description
used within the NSLP as carried in globally-understood objects and used within the NSLP as carried in globally-understood objects and
locally-understood objects. The local objects are only applicable locally-understood objects. The local objects are only applicable
for intra-domain signaling, while the global objects are mainly used for intra-domain signaling, while the global objects are mainly used
in inter-domain signaling. Note that the local objects are still in inter-domain signaling. Note that the local objects are still
part of the protocol but are inserted, used and removed by one single part of the protocol but are inserted, used, and removed by one
domain. single domain.
The purpose of this division is to provide additional flexibility in The purpose of this division is to provide additional flexibility in
defining the objects carried by the NSLP such that only the objects defining the objects carried by the NSLP such that only the objects
applicable in a particular setting are used. One approach for applicable in a particular setting are used. One approach for
reflecting the distinction is that local objects could be put into reflecting the distinction is that local objects could be put into
separate local messages that are initiated and terminated within one separate local messages that are initiated and terminated within one
single domain; an alternative is that they could be "stacked" within single domain; an alternative is that they could be "stacked" within
the NSLP messages that are used anyway for inter-domain signaling. the NSLP messages that are used anyway for inter-domain signaling.
3.3.4 Aggregation 3.3.4. Aggregation
It is a well known problem that per-flow signaling in large-scale It is a well-known problem that per-flow signaling in large-scale
networks presents scaling challenges because of the large number of networks presents scaling challenges because of the large number of
flows that may traverse individual nodes. flows that may traverse individual nodes.
The possibilities for aggregation at the level of the NTLP are quite The possibilities for aggregation at the level of the NTLP are quite
limited; the primary scaling approach for path-coupled signaling is limited; the primary scaling approach for path-coupled signaling is
for a signaling application to group flows together and perform for a signaling application to group flows together and to perform
signaling for the aggregate, rather than for the flows individually. signaling for the aggregate, rather than for the flows individually.
The aggregate may be created in a number of ways: for example, the 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 DSCP individual flows may be sent down a tunnel, or given a common
marking. The aggregation and deaggregation points perform per flow Differentiated Services Code Point (DSCP) marking. The aggregation
signaling, but nodes within the aggregation region should only be and de-aggregation points perform per flow signaling, but nodes
forced to process signaling messages for the aggregate. This depends within the aggregation region should only be forced to process
on the ability of the interior nodes to ignore the per-flow signaling signaling messages for the aggregate. This depends on the ability of
as discussed in Section 3.2.3. 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 Individual NSLPs will need to specify what aggregation means in their
context, and how it should be performed. For example, in the QoS context, and how it should be performed. For example, in the QoS
context it is possible to add together the resources specified in a context it is possible to add together the resources specified in a
number of separate reservations. In the case of other applications, number of separate reservations. In the case of other applications,
such as signaling to NATs and firewalls, the feasibility (and even such as signaling to NATs and firewalls, the feasibility (and even
the meaning) of aggregation is less clear. the meaning) of aggregation is less clear.
3.3.5 Peer-Peer and End-End Relationships 3.3.5. Peer-Peer and End-End Relationships
The assumption in this framework is that the NTLP will operate The assumption in this framework is that the NTLP will operate
'locally', that is, just over the scope of a single peer 'locally'; that is, just over the scope of a single peer
relationship. End-to-end operation is built up by concatenating relationship. End-to-end operation is built up by concatenating
these relationships. Non-local operation (if any) will take place in these relationships. Non-local operation (if any) will take place in
NSLPs. NSLPs.
The peering relations may also have an impact on the required amount The peering relations may also have an impact on the required amount
of state at each NSIS entity. When direct interaction with remote 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 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 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 achieved by keeping per-flow state at the NSIS entities, as is done
RSVP. Another approach would be to maintain a record route object in in RSVP. Another approach would be to maintain a record route object
the messages; this object would be carried within the NSIS protocols, in the messages; this object would be carried within the NSIS
rather than depending on the route recording functionality provided protocols, rather than depend on the route-recording functionality
by the IP layer. provided by the IP layer.
3.3.6 Acknowledgements and Notifications 3.3.6. Acknowledgements and Notifications
We are assuming that the NTLP provides a simple message transfer We are assuming that the NTLP provides a simple message transfer
service, and any acknowledgements or notifications it generates are service, and that any acknowledgements or notifications it generates
handled purely internally (and apply within the scope of a single are handled purely internally (and apply within the scope of a single
NTLP peer relationship). NTLP peer relationship).
However, we expect that some signaling applications will require However, we expect that some signaling applications will require
acknowledgements regarding the failure/success of state installation acknowledgements regarding the failure/success of state installation
along the data path, and this will be an NSLP function. along the data path, and this will be an NSLP function.
Acknowledgements can be sent along the sequence of NTLP peer Acknowledgements can be sent along the sequence of NTLP peer
relationships towards the signaling initiator, which relieves the relationships towards the signaling initiator, which relieves the
requirements on the security associations that need to be maintained requirements on the security associations that need to be maintained
by NEs and can allow NAT traversal in both directions. (If this by NEs and that can allow NAT traversal in both directions. (If this
direction is towards the sender, it implies maintaining reverse direction is towards the sender, it implies maintaining reverse
routing state in the NTLP). In certain circumstances (e.g. trusted routing state in the NTLP.) In certain circumstances (e.g., trusted
domains), an optimization could be to send acknowledgements directly domains), an optimization could be to send acknowledgements directly
to the signaling initiator outside the NTLP (see Section 3.2.2), to the signaling initiator outside the NTLP (see Section 3.2.2),
although any such approach would have to take into account the although any such approach would have to take into account the
necessity of handling denial of service attacks launched from outside necessity of handling denial of service attacks launched from outside
the network. the network.
The semantics of the acknowledgement messages are of particular The semantics of the acknowledgement messages are of particular
importance. An NE sending a message could assume responsibility for importance. An NE sending a message could assume responsibility for
the entire downstream chain of NEs, indicating for instance the the entire downstream chain of NEs, indicating (for instance) the
availability of reserved resources for the entire downstream path. availability of reserved resources for the entire downstream path.
Alternatively, the message could have a more local meaning, Alternatively, the message could have a more local meaning,
indicating for instance that a certain failure or degradation indicating (for instance) that a certain failure or degradation
occurred at a particular point in the network. occurred at a particular point in the network.
Notifications differ from acknowledgements because they are not Notifications differ from acknowledgements because they are not
(necessarily) generated in response to other signaling messages. (necessarily) generated in response to other signaling messages.
This means that it may not be obvious to determine where the This means that it may not be obvious how to determine where the
notification should be sent. Other than that, the same notification should be sent. Other than that, the same
considerations apply as for acknowledgements. One useful distinction considerations apply as for acknowledgements. One useful distinction
to make would be to differentiate between notifications that trigger to make would be to differentiate between notifications that trigger
a signaling action and others that don't. The security requirements a signaling action and others that don't. The security requirements
for the latter are less stringent, which means they could be sent for the latter are less stringent, which means they could be sent
directly to the NE they are destined for (provided this NE can be directly to the NE they are destined for (provided that this NE can
determined). be determined).
3.3.7 Security and Other AAA Issues 3.3.7. Security and Other AAA Issues
In some cases it will be possible to achieve the necessary level of In some cases, it will be possible to achieve the necessary level of
signaling security by using basic 'channel security' mechanisms [11] signaling security by using basic 'channel security' mechanisms [11]
at the level of the NTLP, and the possibilities are described in at the level of the NTLP, and the possibilities are described in
Section 4.7. In other cases, signaling applications may have Section 4.7. In other cases, signaling applications may have
specific security requirements, in which case they are free to invoke specific security requirements, in which case they are free to invoke
their own authentication and key exchange mechanisms and apply their own authentication and key exchange mechanisms and to apply
'object security' to specific fields within the NSLP messages. 'object security' to specific fields within the NSLP messages.
In addition to authentication, the authorisation (to manipulate In addition to authentication, the authorization (to manipulate
network control state) has to be considered as functionality above network control state) has to be considered as functionality above
the NTLP level, since it will be entirely application specific. the NTLP level, since it will be entirely application specific.
Indeed, authorisation decisions may be handed off to a third party in Indeed, authorization decisions may be handed off to a third party in
the protocol (e.g. for QoS, the resource management function as the protocol (e.g., for QoS, the resource management function as
described in Section 6.1.4). Many different authorisation models are described in Section 6.1.4). Many different authorization models are
possible, and the variations impact: possible, and the variations impact:
o what message flows take place - for example, whether authorisation o what message flows take place -- for example, whether
information is carried along with a control state modification authorization information is carried along with a control state
request, or is sent in the reverse direction in response to it; modification request or is sent in the reverse direction in
response to it;
o what administrative relationships are required - for example, o what administrative relationships are required -- for example,
whether authorisation takes place only between peer signaling whether authorization takes place only between peer signaling
applications, or over longer distances. applications, or over longer distances.
Because the NTLP operates only between adjacent peers, and places no Because the NTLP operates only between adjacent peers and places no
constraints on the direction or order in which signaling applications constraints on the direction or order in which signaling applications
can send messages, these authorisation aspects are left open to be can send messages, these authorization aspects are left open to be
defined by each NSLP. Further background discussion of this issue is defined by each NSLP. Further background discussion of this issue is
contained in [12]. contained in [12].
4. The NSIS Transport Layer Protocol 4. The NSIS Transport Layer Protocol
This section describes the overall functionality required from the This section describes the overall functionality required from the
NTLP. It mentions possible protocol components within the NTLP layer NTLP. It mentions possible protocol components within the NTLP layer
and the different possible addressing modes that can be utilized, as and the different possible addressing modes that can be utilized, as
well as the assumed transport and state management functionality. well as the assumed transport and state management functionality.
The interfaces between NTLP and the layers above and below it are The interfaces between NTLP and the layers above and below it are
identified, with a description of the identity elements that appear identified, with a description of the identity elements that appear
on these interfaces. on these interfaces.
It is not the intention of this discussion to design the NTLP or even This discussion is not intended to design the NTLP or even to
to enumerate design options, although some are included as examples. enumerate design options, although some are included as examples.
The goal is to provide a general discussion of required functionality The goal is to provide a general discussion of required functionality
and to highlight some of the issues associated with this. and to highlight some of the issues associated with this.
4.1 Internal Protocol Components 4.1. Internal Protocol Components
The NTLP includes all functionality below the signaling application The NTLP includes all functionality below the signaling application
layer and above the IP layer. The functionality that is required 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 within the NTLP is outlined in Section 3.2.4, with some more details
in Section 3.2.5 and Section 4.3. in Sections 3.2.5 and 4.3.
Some NTLP functionality could be provided via components operating as Some NTLP functionality could be provided via components operating as
sublayers within the NTLP design. For example, if specific transport sublayers within the NTLP design. For example, if specific transport
capabilities are required, such as congestion avoidance, capabilities are required (such as congestion avoidance,
retransmission, security and so on, then existing protocols, such as retransmission, and security), then existing protocols (such as
TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP. This TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This
possibility is not required or excluded by this framework. possibility is not required or excluded by this framework.
If peer-peer addressing (Section 4.2) is used for some messages, then If peer-peer addressing (Section 4.2) is used for some messages, then
active next-peer discovery functionality will be required within the active next-peer discovery functionality will be required within the
NTLP to support the explicit addressing of these messages. This NTLP to support the explicit addressing of these messages. This
could use message exchanges for dynamic peer discovery as a sublayer could use message exchanges for dynamic peer discovery as a sublayer
within the NTLP; there could also be an interface to external within the NTLP; there could also be an interface to external
mechanisms to carry out this function. mechanisms to carry out this function.
==================== =========================== ==================== ===========================
skipping to change at page 26, line 18 skipping to change at page 24, line 5
| | | | .............| | | | | .............|
NSIS | | Monolithic | |+----------+. Peer .| NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .| Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .| Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............| | | | |+----------+.............|
V +------------------+ +-------------------------+ V +------------------+ +-------------------------+
==================== =========================== ==================== ===========================
Figure 6: Options for NTLP Structure Figure 6: Options for NTLP Structure
4.2 Addressing 4.2. Addressing
There are two ways to address a signaling message being transmitted There are two ways to address a signaling message being transmitted
between NTLP peers: between NTLP peers:
o peer-peer, where the message is addressed to a neighboring NSIS o peer-peer, where the message is addressed to a neighboring NSIS
entity that is known to be closer to the destination NE. entity that is known to be closer to the destination NE.
o end-to-end, where the message is addressed to the flow destination o end-to-end, where the message is addressed to the flow destination
directly, and intercepted by an intervening NE. directly and intercepted by an intervening NE.
With peer-peer addressing, an NE will determine the address of the 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 next NE based on the payload of the message (and potentially on the
previous NE). This requires the address of the destination NE to be previous NE). This requires that the address of the destination NE
derivable from the information present in the payload, either by be derivable from the information present in the payload, either by
using some local routing table or through participation in active using some local routing table or through participation in active
peer discovery message exchanges. Peer-peer addressing inherently peer discovery message exchanges. Peer-peer addressing inherently
supports tunneling of messages between NEs, and is equally applicable supports tunneling of messages between NEs, and is equally applicable
to the path-coupled and path-decoupled cases. to the path-coupled and path-decoupled cases.
In the case of end-to-end addressing, the message is addressed to the 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 data flow receiver, and (some of) the NEs along the data path
intercept the messages. The routing of the messages should follow intercept the messages. The routing of the messages should follow
exactly the same path as the associated data flow (but see Section exactly the same path as the associated data flow (but see
5.1.1 on this point). Note that securing messages sent this way Section 5.1.1 on this point). Note that securing messages sent this
raises some interesting security issues (these are discussed in [2]). way raises some interesting security issues (these are discussed in
In addition, it is a matter of the protocol design what should be [2]). In addition, it is a matter of the protocol design what should
used as the source address of the message (the flow source or be used as the source address of the message (the flow source or
signaling source). signaling source).
It is not possible at this stage to mandate one addressing mode or It is not possible at this stage to mandate one addressing mode or
the other. Indeed, each is necessary for some aspects of NTLP the other. Indeed, each is necessary for some aspects of NTLP
operation: in particular, initial discovery of the next downstream operation: In particular, initial discovery of the next downstream
peer will usually require end-to-end addressing, whereas reverse peer will usually require end-to-end addressing, whereas reverse
routing will always require peer-peer addressing. For other message routing will always require peer-peer addressing. For other message
types, the choice is a matter of protocol design. The mode used is 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 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 available from the flow identifier (Section 4.6.1) or locally stored
NTLP state. NTLP state.
4.3 Classical Transport Functions 4.3. Classical Transport Functions
The NSIS signaling protocols are responsible for transporting The NSIS signaling protocols are responsible for transporting
(signaling) data around the network; in general, this requires (signaling) data around the network; in general, this requires
functionality such as congestion management, reliability, and so on. functionality such as congestion management, reliability, and so on.
This section discusses how much of this functionality should be This section discusses how much of this functionality should be
provided within the NTLP. It appears that this doesn't affect the 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. 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 in terms of the semantics of the inter-layer interaction); it is much
more a question of the overall performance/complexity tradeoff more a question of the overall performance/complexity tradeoff
implied by placing certain functions within each layer. implied by placing certain functions within each layer.
Note that, following the discussion at the end of Section 3.2.3, Note that, per the discussion at the end of Section 3.2.3, there may
there may be cases where intermediate nodes wish to modify messages be cases where intermediate nodes wish to modify messages in transit
in transit even though they do not perform full signaling application even though they do not perform full signaling application
processing. In this case, not all of the following functionality processing. In this case, not all the following functionality would
would be invoked at every intermediate node. be invoked at every intermediate node.
The following functionality is assumed to lie within the NTLP: The following functionality is assumed to lie within the NTLP:
1. Bundling together of small messages (comparable to [13]) can be 1. Bundling together of small messages (comparable to [13]) can be
provided locally by the NTLP as an option if desired; it doesn't provided locally by the NTLP as an option, if desired; it doesn't
affect the operation of the network elsewhere. The NTLP should affect the operation of the network elsewhere. The NTLP should
always support unbundling, to avoid the cost of negotiating the always support unbundling, to avoid the cost of negotiating the
feature as an option. (The related function of refresh feature as an option. (The related function of refresh
summarization - where objects in a refresh message are replaced summarization -- where objects in a refresh message are replaced
with a reference to a previous message identifier - is left to with a reference to a previous message identifier -- is left to
NSLPs which can then do this in a way tuned to the state NSLPs, which can then do this in a way tuned to the state
management requirements of the signaling application. Additional management requirements of the signaling application. Additional
transparent compression functionality could be added to the NTLP transparent compression functionality could be added to the NTLP
design later as a local option.) Note that end-to-end addressed design later as a local option.) Note that end-to-end addressed
messages for different flows cannot be bundled safely unless the messages for different flows cannot be bundled safely unless the
next node on the outgoing interface is known to be NSIS-aware. next node on the outgoing interface is known to be NSIS-aware.
2. Message fragmentation should be provided by the NTLP when needed. 2. When needed, message fragmentation should be provided by the
The use of IP fragmentation for large messages may lead to NTLP. The use of IP fragmentation for large messages may lead to
reduced reliability and be incompatible with some addressing reduced reliability and may be incompatible with some addressing
schemes. Therefore, this functionality should be provided within schemes. Therefore, this functionality should be provided within
the NTLP as a service for NSLPs that generate large messages. the NTLP as a service for NSLPs that generate large messages.
How the NTLP determines and accommodates MTU constraints is left How the NTLP determines and accommodates Maximum Transmission
as a matter of protocol design. To avoid imposing the cost of Unit (MTU) constraints is left as a matter of protocol design.
reassembly on intermediate nodes, the fragmentation scheme used To avoid imposing the cost of reassembly on intermediate nodes,
should allow for the independent forwarding of individual the fragmentation scheme used should allow for the independent
fragments towards a node hosting an interested NSLP. forwarding of individual fragments towards a node hosting an
interested NSLP.
3. There can be significant benefits for signaling applications if 3. There can be significant benefits for signaling applications if
state-changing messages are delivered reliably (as introduced in state-changing messages are delivered reliably (as introduced in
[13] for RSVP; see also the more general analysis of [14]). This [13] for RSVP; see also the more general analysis of [14]). This
does not change any assumption about the use of soft-state by does not change any assumption about the use of soft-state by
NSLPs to manage signaling application state, and leaves the NSLPs to manage signaling application state, and it leaves the
responsibility for detecting and recovering from application responsibility for detecting and recovering from application
layer error conditions in the NSLP. However, it means that such layer error conditions in the NSLP. However, it means that such
functionality does not need to be tuned to handle fast recovery functionality does not need to be tuned to handle fast recovery
from message loss due to congestion or corruption in the lower from message loss due to congestion or corruption in the lower
layers, and also means that the NTLP can prevent the layers, and it also means that the NTLP can prevent the
amplification of message loss rates caused by fragmentation. amplification of message loss rates caused by fragmentation.
Reliable delivery functionality is invoked by the NSLP on a Reliable delivery functionality is invoked by the NSLP on a
message-by-message basis and is always optional to use. message-by-message basis and is always optional to use.
4. The NTLP should not allow signaling messages to cause congestion 4. The NTLP should not allow signaling messages to cause congestion
in the network (i.e. at the IP layer). Congestion could be in the network (i.e., at the IP layer). Congestion could be
caused by retransmission of lost signaling packets or by upper caused by retransmission of lost signaling packets or by upper
layer actions (e.g. a flood of signaling updates to recover from layer actions (e.g., a flood of signaling updates to recover from
a route change). In some cases it may be possible to engineer a route change). In some cases, it may be possible to engineer
the network to ensure that signaling cannot overload it; in other the network to ensure that signaling cannot overload it; in
cases, the NTLP would have to detect congestion and adapt the others, the NTLP would have to detect congestion and to adapt the
rate at which it allows signaling messages to be transmitted. rate at which it allows signaling messages to be transmitted.
Principles of congestion control in Internet protocols are given Principles of congestion control in Internet protocols are given
in [15]. The NTLP may or may not be able to detect overload in 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 the control plane itself (e.g., an NSLP-aware node several
NTLP-hops away which cannot keep up with the incoming message NTLP-hops away that cannot keep up with the incoming message
rate) and indicate this as a flow-control condition to local rate) and indicate this as a flow-control condition to local
signaling applications. However, for both the congestion and signaling applications. However, for both the congestion and
overload cases, it is up to the signaling applications themselves overload cases, it is up to the signaling applications themselves
to adapt their behavior accordingly. to adapt their behavior accordingly.
4.4 Lower Layer Interfaces 4.4. Lower Layer Interfaces
The NTLP interacts with 'lower layers' of the protocol stack for the The NTLP interacts with 'lower layers' of the protocol stack for the
purposes of sending and receiving signaling messages. This framework purposes of sending and receiving signaling messages. This framework
places the lower boundary of the NTLP at the IP layer. The interface places the lower boundary of the NTLP at the IP layer. The interface
to the lower layer is therefore very simple: to the lower layer is therefore very simple:
o The NTLP sends raw IP packets o The NTLP sends raw IP packets
o The NTLP receives raw IP packets. In the case of peer-peer o The NTLP receives raw IP packets. In the case of peer-peer
addressing, they have been addressed directly to it. In the case addressing, they have been addressed directly to it. In the case
of end-to-end addressing, this will be achieved by intercepting of end-to-end addressing, this will be achieved by intercepting
packets that have been marked in some special way (by special packets that have been marked in some special way (by special
protocol number or by some option interpreted within the IP layer, protocol number or by some option interpreted within the IP layer,
such as the router alert option). such as the router alert option).
o The NTLP receives indications from the IP layer (including local o The NTLP receives indications from the IP layer (including local
forwarding tables and routing protocol state) which provide some forwarding tables and routing protocol state) that provide some
information about route changes and similar events (see Section information about route changes and similar events (see
5.1). Section 5.1).
For correct message routing, the NTLP needs to have some information For correct message routing, the NTLP needs to have some information
about link and IP layer configuration of the local networking stack. about link and IP layer configuration of the local networking stack.
In general, it needs to know how to select the outgoing interface for In general, it needs to know how to select the outgoing interface for
a signaling message, where this must match the interface that will be a signaling message and where this must match the interface that will
used by the corresponding flow. This might be as simple as just 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 allowing the IP layer to handle the message using its own routing
table. There is no intention to do something different from IP table. There is no intention to do something different from IP
routing (for end-to-end addressed messages); however, some hosts routing (for end-to-end addressed messages); however, some hosts
allow applications to bypass routing for their data flows, and the allow applications to bypass routing for their data flows, and the
NTLP processing must account for this. Further network layer NTLP processing must account for this. Further network layer
information would be needed to handled scoped addresses (if such information would be needed to handle scoped addresses (if such
things ever exist). things ever exist).
Configuration of lower layer operation to handle flows in particular Configuration of lower-layer operation to handle flows in particular
ways is handled by the signaling application. ways is handled by the signaling application.
4.5 Upper Layer Services 4.5. Upper Layer Services
The NTLP offers transport layer services to higher layer signaling The NTLP offers transport-layer services to higher-layer signaling
applications for two purposes: sending and receiving signaling applications for two purposes: sending and receiving signaling
messages, and exchanging control and feedback information. messages, and exchanging control and feedback information.
For sending and receiving messages, two basic control primitives are For sending and receiving messages, two basic control primitives are
required: required:
o Send Message, to allow the signaling application to pass data to o Send Message, to allow the signaling application to pass data to
the NTLP for transport. the NTLP for transport.
o Receive Message, to allow the NTLP to pass received data to the o Receive Message, to allow the NTLP to pass received data to the
signaling application. signaling application.
The NTLP and signaling application may also want to exchange other The NTLP and signaling application may also want to exchange other
control information, such as: control information, such as the following:
o Signaling application registration/de-registration, so that o Signaling application registration/de-registration, so that
particular signaling application instances can register their particular signaling application instances can register their
presence with the transport layer. This may also require some presence with the transport layer. This may also require some
identifier to be agreed between the NTLP and signaling application identifier to be agreed upon between the NTLP and signaling
to support the exchange of further control information and to application to support the exchange of further control information
allow the de-multiplexing of incoming data. and to allow the de-multiplexing of incoming data.
o NTLP configuration, allowing signaling applications to indicate o NTLP configuration, allowing signaling applications to indicate
what optional NTLP features they want to use, and to configure what optional NTLP features they want to use, and to configure
NTLP operation, such as controlling what transport layer state NTLP operation, such as controlling what transport layer state
should be maintained. should be maintained.
o Error messages, to allow the NTLP to indicate error conditions to o Error messages, to allow the NTLP to indicate error conditions to
the signaling application and vice versa. the signaling application, and vice versa.
o Feedback information, such as route change indications so that the o Feedback information, such as route change indications so that the
signaling application can decide what action to take. signaling application can decide what action to take.
4.6 Identity Elements 4.6. Identity Elements
4.6.1 Flow Identification 4.6.1. Flow Identification
The flow identification is a method of identifying a flow in a unique 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 way. All packets associated with the same flow will be identified by
the same flow identifier. The key aspect of the flow identifier is the same flow identifier. The key aspect of the flow identifier is
to provide enough information such that the signaling flow receives to provide enough information such that the signaling flow receives
the same treatment along the data path as the actual data itself, the same treatment along the data path as the actual data itself;
i.e. consistent behavior is applied to the signaling and data flows i.e., consistent behavior is applied to the signaling and data flows
by a NAT or policy-based forwarding engine. by a NAT or policy-based forwarding engine.
Information that could be used in flow identification may include: Information that could be used in flow identification may include:
o source IP address; o source IP address;
o destination IP address; o destination IP address;
o protocol identifier and higher layer (port) addressing; o protocol identifier and higher layer (port) addressing;
o flow label (typical for IPv6); o flow label (typical for IPv6);
o SPI field for IPsec encapsulated data; o SPI field for IPsec encapsulated data; and
o DSCP/TOS field o DSCP/TOS field.
It is assumed that at most limited wildcarding on these identifiers It is assumed that at most limited wildcarding on these identifiers
is needed. is needed.
We've assumed here that the flow identification is not hidden within We assume here that the flow identification is not hidden within the
the NSLP, but is explicitly part of the NTLP. The justification for NSLP, but is explicitly part of the NTLP. The justification for this
this is that it might be valuable to be able to do NSIS processing is that being able to do NSIS processing, even at a node which was
even at a node which was unaware of the specific signaling unaware of the specific signaling application (see Section 3.2.3)
application (see Section 3.2.3): an example scenario would be might be valuable. An example scenario would be messages passing
messages passing through an addressing boundary where the flow through an addressing boundary where the flow identification had to
identification had to be re-written. be re-written.
4.6.2 Session Identification 4.6.2. Session Identification
There are circumstances where it is important to be able to refer to There are circumstances in which being able to refer to signaling
signaling application state independently of the underlying flow. application state independently of the underlying flow is important.
For example, if the address of one of the flow endpoints changes due 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 to a mobility event, it is desirable to be able to change the flow
identifier without having to install a completely new reservation. identifier without having to install a completely new reservation.
The session identifier provides a method to correlate the signaling The session identifier provides a method to correlate the signaling
about the different flows with the same network control state. about the different flows with the same network control state.
The session identifier is essentially a signaling application The session identifier is essentially a signaling application
concept, since it is only used in non-trivial state management concept, since it is only used in non-trivial state management
actions that are application specific. However, we assume here that actions that are application specific. However, we assume here that
it should be visible within the NTLP. This enables it to be used to it should be visible within the NTLP. This enables it to be used to
control NTLP behavior, for example, by controlling how the transport control NTLP behavior; for example, by controlling how the transport
layer should forward packets belonging to this session (as opposed to layer should forward packets belonging to this session (as opposed to
this signaling application). In addition, the session identifier can this signaling application). In addition, the session identifier can
be used by the NTLP to demultiplex received signaling messages be used by the NTLP to demultiplex received signaling messages
between multiple instances of the same signaling application, if such between multiple instances of the same signaling application, if such
an operational scenario is supported (see Section 4.6.3 for more an operational scenario is supported (see Section 4.6.3 for more
information on signaling application identification). information on signaling application identification).
To be useful for mobility support, the session identifier should be To be useful for mobility support, the session identifier should be
globally unique, and it should not be modified end-to-end. It is globally unique, and it should not be modified end-to-end. It is
well known that it is practically impossible to generate identifiers well known that it is practically impossible to generate identifiers
in a way which guarantees this property; however, using a large in a way that guarantees this property; however, using a large random
random number makes it highly likely. In any case, the NTLP ascribes number makes it highly likely. In any case, the NTLP ascribes no
no valuable semantics to the identifier (such as 'session valuable semantics to the identifier (such as 'session ownership');
ownership'); this problem is left to the signaling application, which this problem is left to the signaling application, which may be able
may be able to secure it to use for this purpose. to secure it to be used for this purpose.
4.6.3 Signaling Application Identification 4.6.3. Signaling Application Identification
Since the NTLP can be used to support several NSLP types, there is a Because the NTLP can be used to support several NSLP types, there is
need to identify which type a particular signaling message exchange a need to identify which type a particular signaling message exchange
is being used for. This is to support: is being used for. This is to support:
o processing of incoming messages - the NTLP should be able to o processing of incoming messages -- the NTLP should be able to
demultiplex these towards the appropriate signaling applications; demultiplex these towards the appropriate signaling applications;
and
o processing of general messages at an NSIS aware intermediate node o processing of general messages at an NSIS-aware intermediate node
- if the node does not handle the specific signaling application, -- if the node does not handle the specific signaling application,
it should be able to make a forwarding decision without having to it should be able to make a forwarding decision without having to
parse upper layer information. parse upper-layer information.
No position is taken on the form of the signaling application No position is taken on the form of the signaling application
identifier, or even the structure of the signaling application identifier, or even the structure of the signaling application
'space' - free-standing applications, potentially overlapping groups 'space': free-standing applications, potentially overlapping groups
of capabilities, etc. These details should not influence the rest of of capabilities, etc. These details should not influence the rest of
the NTLP design. the NTLP design.
4.7 Security Properties 4.7. Security Properties
It is assumed that the only security service required within the NTLP It is assumed that the only security service required within the NTLP
is channel security. Channel security requires a security is channel security. Channel security requires a security
association to be established between the signaling endpoints, which association to be established between the signaling endpoints, which
is carried out via some authentication and key management exchange. is carried out via some authentication and key management exchange.
This functionality could be provided by reusing a standard protocol. This functionality could be provided by reusing a standard protocol.
In order to protect a particular signaling exchange, the NSIS entity In order to protect a particular signaling exchange, the NSIS entity
needs to select the security association that it has in place with needs to select the security association that it has in place with
the next NSIS entity that will be receiving the signaling message. the next NSIS entity that will be receiving the signaling message.
skipping to change at page 32, line 29 skipping to change at page 30, line 27
NTLP (see Section 4.2). NTLP (see Section 4.2).
Channel security can provide many different types of protection to Channel security can provide many different types of protection to
signaling exchanges, including integrity and replay protection and signaling exchanges, including integrity and replay protection and
encryption. It is not clear which of these is required at the NTLP encryption. It is not clear which of these is required at the NTLP
layer, although most channel security mechanisms support them all. layer, although most channel security mechanisms support them all.
It is also not clear how tightly an NSLP can 'bind' to the channel It is also not clear how tightly an NSLP can 'bind' to the channel
security service provided by the NTLP. security service provided by the NTLP.
Channel security can also be applied to the signaling messages with Channel security can also be applied to the signaling messages with
differing granularity, i.e. all or parts of the signaling message differing granularity; i.e., all or parts of the signaling message
may be protected. For example, if the flow is traversing a NAT, only 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 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 should be protected. (Alternatively, if the NAT takes part in NTLP
security procedures, it only needs to be given access to the message security procedures, it only needs to be given access to the message
fields containing addresses, often just the flow id). It is an open fields containing addresses, often just the flow id.) Which parts of
question as to which parts of the NTLP messages need protecting, and the NTLP messages need protecting is an open question, as is what
what type of protection should be applied to each. type of protection should be applied to each.
5. Interactions with Other Protocols 5. Interactions with Other Protocols
5.1 IP Routing Interactions 5.1. IP Routing Interactions
The NTLP is responsible for determining the next node to be visited The NTLP is responsible for determining the next node to be visited
by the signaling protocol. For path-coupled signaling, this next by the signaling protocol. For path-coupled signaling, this next
node should be one that will be visited by the data flow. In node should be one that will be visited by the data flow. In
practice, this peer discovery will be approximate, as any node could practice, this peer discovery will be approximate, as any node could
use any feature of the peer discovery packet to route it differently use any feature of the peer discovery packet to route it differently
from the corresponding data flow packets. Divergence between data from the corresponding data flow packets. Divergence between the
and signaling path can occur due to load sharing or load balancing data and signaling paths can occur due to load sharing or load
(Section 5.1.1). An example specific to the case of QoS is given in balancing (Section 5.1.1). An example specific to the case of QoS is
Section 6.1.1. Route changes cause a temporary divergence between given in Section 6.1.1. Route changes cause a temporary divergence
the data path and the path on which signaling state has been between the data path and the path on which signaling state has been
installed. The occurrence, detection and impact of route changes is installed. The occurrence, detection, and impact of route changes is
described in Section 5.1.2. A description of this issue in the described in Section 5.1.2. A description of this issue in the
context of QoS is given in Section 6.1.2. context of QoS is given in Section 6.1.2.
5.1.1 Load Sharing and Policy-Based Forwarding 5.1.1. Load Sharing and Policy-Based Forwarding
Load sharing or load balancing is a network optimization technique Load sharing or load balancing is a network optimization technique
that exploits the existence of multiple paths to the same destination that exploits the existence of multiple paths to the same destination
in order to obtain benefits in terms of protection, resource in order to obtain benefits in terms of protection, resource
efficiency or network stability. It has been proposed for a number efficiency, or network stability. It has been proposed for a number
of routing protocols, such as OSPF [16] and others. In general, load of routing protocols, such as OSPF [16] and others. In general, load
sharing means that packet forwarding will take into account header sharing means that packet forwarding will take into account header
fields in addition to the destination address; a general discussion fields in addition to the destination address; a general discussion
of such techniques and the problems they cause is provided in [17]. of such techniques and the problems they cause is provided in [17].
The significance of load sharing in the context of NSIS is that The significance of load sharing in the context of NSIS is that
routing of signaling messages using end-to-end addressing does not routing of signaling messages using end-to-end addressing does not
guarantee that these messages will follow the data path. guarantee that these messages will follow the data path. Policy-
Policy-based forwarding for data packets - where the outgoing link is based forwarding for data packets -- where the outgoing link is
selected based on policy information about fields additional to the selected based on policy information about fields additional to the
packet destination address - has the same impact. Signaling and data packet destination address -- has the same impact. Signaling and
packets may diverge because of both of these techniques. data packets may diverge because of both of these techniques.
If signaling packets are given source and destination addresses If signaling packets are given source and destination addresses
identical to data packets, signaling and data may still diverge identical to data packets, signaling and data may still diverge
because of layer 4 load-balancing (based on protocol or port). Such because of layer-4 load balancing (based on protocol or port). Such
techniques would also cause ICMP errors to be misdirected to the techniques would also cause ICMP errors to be misdirected to the
source of the data because of the source address spoofing. If source of the data because of source address spoofing. If signaling
signaling packets are made identical in the complete 5-tuple, packets are made identical in the complete 5-tuple, divergence may
divergence may still occur because of the presence of router alert still occur because of the presence of router alert options. The
options. The same ICMP misdirection applies, and it becomes same ICMP misdirection applies, and it becomes difficult for the end
difficult for the end systems to distinguish between data and systems to distinguish between data and signaling packets. Finally,
signaling packets. Finally, QoS routing techniques may base the QoS routing techniques may base the routing decision on any field in
routing decision on any field in the packet header (e.g. DSCP, ...). the packet header (e.g., DSCP).
5.1.2 Route Changes 5.1.2. Route Changes
In a connectionless network, each packet is independently routed In a connectionless network, each packet is independently routed
based on its header information. Whenever a better route towards the based on its header information. Whenever a better route towards the
destination becomes available, this route is installed in the destination becomes available, this route is installed in the
forwarding table and will be used for all subsequent (data and forwarding table and will be used for all subsequent (data and
signaling) packets. This can cause a divergence between the path signaling) packets. This can cause a divergence between the path
along which state has been installed and the path along which along which state has been installed and the path along which
forwarding will actually take place. The problem of route changes is forwarding will actually take place. The problem of route changes is
reduced if route pinning is performed. Route pinning refers to the reduced if route pinning is performed. Route pinning refers to the
independence of the path taken by certain data packets from independence of the path taken by certain data packets from
reachability changes caused by routing updates from an Interior reachability changes caused by routing updates from an Interior
Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP). Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).
Nothing about NSIS signaling prevents route pinning being used as a Nothing about NSIS signaling prevents route pinning from being used
network engineering technique, provided it is done in a way which as a network engineering technique, provided that it is done in a way
preserves the common routing of signaling and data. However, even if that preserves the common routing of signaling and data. However,
route pinning is used, it cannot be depended on to prevent all route even if route pinning is used, it cannot be depended on to prevent
changes (for example in the case of link failures). all route changes (for example, in the case of link failures).
Handling route changes requires the presence of three processes in Handling route changes requires the presence of three processes in
the signaling protocol: the signaling protocol:
1. route change detection 1. route change detection
2. installation of state on the new path 2. installation of state on the new path
3. removal of state on the old path 3. removal of state on the old path
Many route change detection methods can be used, some needing Many route change detection methods can be used, some needing
explicit protocol support and some of which are explicit protocol support, and some of which are implementation-
implementation-internal. They differ in their speed of reaction and internal. They differ in their speed of reaction and in the types of
the types of change they can detect. In rough order of increasing change they can detect. In rough order of increasing applicability,
applicability, they can be summarized as: they can be summarized as follows:
1. monitoring changes in local forwarding table state 1. monitoring changes in local forwarding table state
2. monitoring topology changes in a link-state routing protocol 2. monitoring topology changes in a link-state routing protocol
3. inference from changes in data packet TTL 3. inference from changes in data packet TTL
4. inference from loss of packet stream in a flow-aware router 4. inference from loss of packet stream in a flow-aware router
5. inference from changes in signaling packet TTL 5. inference from changes in signaling packet TTL
skipping to change at page 35, line 4 skipping to change at page 32, line 36
3. inference from changes in data packet TTL 3. inference from changes in data packet TTL
4. inference from loss of packet stream in a flow-aware router 4. inference from loss of packet stream in a flow-aware router
5. inference from changes in signaling packet TTL 5. inference from changes in signaling packet TTL
6. changed route of an end-to-end addressed signaling packet 6. changed route of an end-to-end addressed signaling packet
7. changed route of a specific end-to-end addressed probe packet 7. changed route of a specific end-to-end addressed probe packet
These methods can be categorized as being based on network monitoring These methods can be categorized as being based on network monitoring
(methods 1-2), based on data packet monitoring (methods 3-4) and (methods 1-2), on data packet monitoring (methods 3-4) and on
based on monitoring signaling protocol messages (methods 5-7); method monitoring signaling protocol messages (methods 5-7); method 6 is the
6 is the baseline method of RSVP. The network monitoring methods can baseline method of RSVP. The network monitoring methods can only
only detect local changes; in particular, method 1 can only detect an detect local changes; in particular, method 1 can only detect an
event which changes the immediate next downstream hop, and method 2 event that changes the immediate next downstream hop, and method 2
can only detect changes within the scope of the link-state protocol. can only detect changes within the scope of the link-state protocol.
Methods 5-7 which are contingent on monitoring signaling messages Methods 5-7, which are contingent on monitoring signaling messages,
become less effective as soft state refresh rates are reduced. become less effective as soft-state refresh rates are reduced.
When a route change has been detected, it is important that state is 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 installed as quickly as possible along the new path. It is not
guaranteed that the new path will be able to provide the same guaranteed that the new path will be able to provide the same
characteristics that were available on the old path. In order to be characteristics that were available on the old path. To avoid
able to avoid duplicate state installation or, worse, rejection of duplicate state installation or, worse, rejection of the signaling
the signaling message because of previously installed state, it is message because of previously installed state, it is important to be
important to be able to recognize the new signaling message as able to recognize the new signaling message as belonging to an
belonging to an existing session. In this respect, we distinguish existing session. In this respect, we distinguish between route
between route changes with associated change of the flow changes with associated change of the flow identification (e.g., in
identification (e.g. in case of a mobility event when the IP source case of a mobility event when the IP source might change) and route
might change) and route changes without change of the flow changes without change of the flow identification (e.g., in case of a
identification (e.g. in case of a link failure along the path). The link failure along the path). The former case requires an identifier
former case requires an identifier independent from the flow independent from the flow identification; i.e., the session
identification, i.e. the session identifier (Section 4.6.2). identifier (Section 4.6.2). Mobility issues are discussed in more
Mobility issues are discussed in more detail in Section 5.2. detail in Section 5.2.
When state has been installed along the new path, the existing state 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, on the old path needs to be removed. With the soft-state principle,
this will happen automatically because of the lack of refresh this will happen automatically because of the lack of refresh
messages. Depending on the refresh timer, however, it may be messages. Depending on the refresh timer, however, it may be
required to tear down this state much faster (e.g. because it is required to tear down this state much faster (e.g., because it is
tied to an accounting record). In that case, the teardown message tied to an accounting record). In that case, the teardown message
needs to be able to distinguish between the new path and the old needs to be able to distinguish between the new path and the old
path. path.
In some environments, it is desired to provide connectivity and per In some environments, it is desirable to provide connectivity and
flow or per class state management with high-availability per-flow or per-class state management with high-availability
characteristics, i.e. with rapid transparent recovery even in the characteristics; i.e., with rapid transparent recovery, even in the
presence of route changes. This may need interactions with protocols presence of route changes. This may require interactions with
which are used to manage the routing in this case, such as VRRP [18]. 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 Our basic assumption about such interactions is that the NTLP would
be responsible for detecting the route change and ensuring that be responsible for detecting the route change and ensuring that
signaling messages were re-routed consistently (in the same way as signaling messages were re-routed consistently (in the same way as
the data traffic); but that the further state re-synchronization the data traffic). However, further state re-synchronization
(including failover between 'main' and 'standby' nodes in the high (including failover between 'main' and 'standby' nodes in the high
availability case) would be the responsibility of the signaling availability case) would be the responsibility of the signaling
application and its NSLP, possibly triggered by the NTLP. application and its NSLP, and would possibly be triggered by the
NTLP.
5.2 Mobility and Multihoming Interactions 5.2. Mobility and Multihoming Interactions
The issues associated with mobility and multihoming are a The issues associated with mobility and multihoming are a
generalization of the basic route change case of the previous generalization of the basic route change case of the previous
section. As well as the fact that packets for a given session are no section. As well as the fact that packets for a given session are no
longer traveling over a single topological path, the following extra longer traveling over a single topological path, the following extra
considerations arise: considerations arise:
1. The use of IP-layer mobility and multihoming means that more than 1. The use of IP-layer mobility and multihoming means that more than
one IP source or destination address will be associated with a one IP source or destination address will be associated with a
single session. The same applies if application layer solutions single session. The same applies if application-layer solutions
(e.g. SIP-based approaches) are used. (e.g., SIP-based approaches) are used.
2. Mobile IP and associated protocols use some special 2. Mobile IP and associated protocols use some special
encapsulations for some segments of the data path. encapsulations for some segments of the data path.
3. The double route may persist for some time in the network (e.g. 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 in the case of a 'make-before-break' handover being done by a
multihomed host). multihomed host).
4. Conversely, the re-routing may be rapid and routine (unlike 4. Conversely, the re-routing may be rapid and routine (unlike
network internal route changes), increasing the importance of network-internal route changes), increasing the importance of
rapid state release on old paths. rapid state release on old paths.
The interactions between mobility and signaling have been extensively The interactions between mobility and signaling have been extensively
analyzed in recent years, primarily in the context of RSVP and Mobile analyzed in recent years, primarily in the context of RSVP and Mobile
IP interaction (e.g. the mobility discussion of [5]), but also in IP interaction (e.g., the mobility discussion of [5]), but also in
the context of other types of network (e.g. [19]); a general review that of other types of network (e.g., [19]). A general review of the
of the fundamental interactions is given in [20], which provides fundamental interactions is given in [20], which provides further
further details on many of the subjects considered in this section. details on many of the subjects considered in this section.
We are assuming that the signaling will refer to 'outer' IP headers We assume that the signaling will refer to 'outer' IP headers when
when defining the flows it is controlling. There are two main defining the flows it is controlling. There are two main reasons for
reasons for this. The first is that the data plane will usually be this. The first is that the data plane will usually be unable to
unable to work in terms of anything else when implementing per-flow work in terms of anything else when implementing per-flow treatment
treatment (e.g. we cannot expect a router will analyse inner headers (e.g., we cannot expect that a router will analyze inner headers to
to decide how to schedule packets). The second reason is that we are decide how to schedule packets). The second reason is that we are
implicitly relying on the security provided by the network implicitly relying on the security provided by the network
infrastructure to ensure that the correct packets are given the infrastructure to ensure that the correct packets are given the
special treatment being signaled for, and this is built on the special treatment being signaled for, and this is built on the
relationship between packet source and destination addresses and relationship between packet source and destination addresses and
network topology (this is essentially the same approach that is used network topology. (This is essentially the same approach that is
as the basis of route optimization security in Mobile IPv6 [21]). used as the basis of route optimization security in Mobile IPv6
The consequence of this assumption is that we see the packet streams [21].) The consequence of this assumption is that we see the packet
to (or from) different addresses as different flows, and where a flow streams to (or from) different addresses as different flows. Where a
is carried inside a tunnel this is seen as a different flow again. flow is carried inside a tunnel, it is seen as a different flow
The encapsulation issues (point (2) above) are therefore to be again. The encapsulation issues (point (2) above) are therefore to
handled the same way as other tunneling cases (Section 5.4). be handled the same way as other tunneling cases (Section 5.4).
The most critical aspect is therefore the fact that multiple flows Therefore, the most critical aspect is that multiple flows are being
are being used, and the signaling for them needs to be correlated used, and the signaling for them needs to be correlated. This is the
together. This is the intended role of the session identifier (see intended role of the session identifier (see Section 4.6.2, which
Section 4.6.2, which also describes some of the security requirements also describes some of the security requirements for such an
for such an identifier). Although the session identifier is visible identifier). Although the session identifier is visible at the NTLP,
at the NTLP, it is the signaling application which is responsible for the signaling application is responsible for performing the
performing the correlation (and doing so securely). The NTLP correlation (and for doing so securely). The NTLP responsibility is
responsibility is limited to delivering the signaling messages for limited to delivering the signaling messages for each flow between
each flow between the correct signaling application peers. The the correct signaling application peers. The locations at which the
locations at which the correlation takes place are the end system and correlation takes place are the end system and the signaling-
the signaling application aware node in the network where the flows application-aware node in the network where the flows meet. (This
meet (this node is generally referred to as the "crossover router"; node is generally referred to as the "crossover router"; it can be
it can be anywhere in the network). anywhere in the network.)
Although much work has been done in the past on finding the crossover Although much work has been done in the past on finding the crossover
router directly from information held in particular mobility router directly from information held in particular mobility
signaling protocols, the initial focus of NSIS work should be to have signaling protocols, the initial focus of NSIS work should be a
a solution which is not tightly bound to any single mobility solution that is not tightly bound to any single mobility approach.
approach. In other words, it should be possible to determine the In other words, it should be possible to determine the crossover
crossover router based on NSIS signaling. (This doesn't rule out the router based on NSIS signaling. (This doesn't rule out the
possibility that some implementations may be able to do this possibility that some implementations may be able to do this
discovery faster, e.g. by being tightly integrated with local discovery faster; e.g., by being tightly integrated with local
mobility management protocols; this is directly comparable to mobility management protocols. This is directly comparable to
spotting route changes in fixed networks by being routing aware.) spotting route changes in fixed networks by being routing aware.)
Note that the crossover router discovery may involve end-to-end Note that the crossover router discovery may involve end-to-end
signaling exchanges (especially for flows towards the mobile or signaling exchanges (especially for flows towards the mobile or
multihomed node) which raises a latency concern; on the other hand, multihomed node), which raises a latency concern. On the other hand,
end-to-end signaling will have been necessary in any case, both at end-to-end signaling will have been necessary in any case, at the
the application level (to communicate changed addresses) and also to application level not only to communicate changed addresses, but also
update packet classifiers along the path. It is a matter for further to update packet classifiers along the path. It is a matter for
analysis to decide how these exchanges could be combined or carried further analysis to decide how these exchanges could be combined or
out in parallel. carried out in parallel.
On the shared part of the path, signaling is needed at least to On the shared part of the path, signaling is needed at least to
update the packet classifiers to include the new flow, although if update the packet classifiers to include the new flow, although if
correlation with the existing flow is possible it should be possible correlation with the existing flow is possible it should be possible
to bypass any policy or admission control processing. State to bypass any policy or admission control processing. State
installation on the new path (and possibly release on the old one) installation on the new path (and possibly release on the old one)
are also required. Which entity (one of the end hosts or the are also required. Which entity (one of the end hosts or the
crossover router) controls all these procedures depends on which crossover router) controls all these procedures depends on which
entities are authorised to carry out network state manipulations, so entities are authorized to carry out network state manipulations, so
this is therefore a matter of signaling application and NSLP design. this is therefore a matter of signaling application and NSLP design.
The approach may depend on the sender/receiver orientation of the The approach may depend on the sender/receiver orientation of the
original signaling (see Section 3.3.1). In addition, in the mobility 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 case, the old path may no longer be directly accessible to the mobile
node; inter-access-router communication may be required to release node; inter-access-router communication may be required to release
state in these circumstances. state in these circumstances.
The frequency of handovers in some network types encourages the The frequency of handovers in some network types makes fast handover
consideration of fast handover support protocols, for selection of support protocols desirable, for selecting the optimal access router
the optimal access router to hand over to (for example, [22]), and for handover (for example, [22]), and for transferring state
transfer of state information to avoid having to regenerate it in the information to avoid having to regenerate it in the new access router
new access router after handover (for example, [23]). Both these after handover (for example, [23]). Both of these procedures could
procedures could have strong interactions with signaling protocols, have strong interactions with signaling protocols. The access router
the former because a selection criterion might be what network selection might depend on the network control state that could be
control state could be supported on the path through the new access supported on the path through the new access router. Transfer of
router, the latter because signaling application state or NTLP/NSLP signaling application state or NTLP/NSLP protocol state may be a
protocol state may be a candidate for context transfer. candidate for context transfer.
5.3 Interactions with NATs 5.3. Interactions with NATs
Because at least some messages will almost inevitably contain Because at least some messages will almost inevitably contain
addresses and possibly higher layer information as payload, we must addresses and possibly higher-layer information as payload, we must
consider the interaction with address translation devices (NATs). consider the interaction with address translation devices (NATs).
These considerations apply both to 'traditional' NATs of various These considerations apply both to 'traditional' NATs of various
types (as defined in [24]) as well as some IPv4/v6 transition types (as defined in [24]) as well as some IPv4/v6 transition
mechanisms such as SIIT [25]. mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25].
In the simplest case of an NSIS unaware NAT in the path, payloads In the simplest case of an NSIS-unaware NAT in the path, payloads
will be uncorrected and signaling will refer to the flow incorrectly. will be uncorrected, and signaling will refer to the flow
Applications could attempt to use STUN [26] or similar techniques to incorrectly. Applications could attempt to use STUN [26] or similar
detect and recover from the presence of the NAT. Even then, NSIS techniques to detect and recover from the presence of the NAT. Even
protocols would have to use a well known encapsulation (TCP/UDP/ICMP) then, NSIS protocols would have to use a well-known encapsulation
to avoid being dropped by more cautious low-end NAT devices. (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT
devices.
A simple 'NSIS-aware' NAT would require flow identification A simple 'NSIS-aware' NAT would require flow identification
information to be in the clear and not integrity protected. An information to be in the clear and not to be integrity protected. An
alternative conceptual approach is to consider the NAT functionality alternative conceptual approach is to consider the NAT functionality
being part of message processing itself, in which case the part of message processing itself, in which case the translating node
translating node can take part natively in any NSIS protocol security can take part natively in any NSIS protocol security mechanisms.
mechanisms. Depending on NSIS protocol layering, it would be Depending on NSIS protocol layering, it would be possible for this
possible for this processing to be done in an NSIS entity which was processing to be done in an NSIS entity that was otherwise ignorant
otherwise ignorant of any particular signaling applications. This is of any particular signaling applications. This is the motivation for
the motivation for including basic flow identification information in including basic flow identification information in the NTLP
the NTLP (Section 4.6.1). (Section 4.6.1).
Note that all of this discussion is independent of the use of a Note that all of this discussion is independent of the use of a
specific NSLP for general control of NATs (and firewalls). This is specific NSLP for general control of NATs (and firewalls). That case
considered in Section 6.2. is considered in Section 6.2.
5.4 Interactions with IP Tunneling 5.4. Interactions with IP Tunneling
Tunneling is used in the Internet for a number of reasons such as Tunneling is used in the Internet for a number of reasons, such as
flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
private networking, and so on. An NSIS solution must continue to private networking, and so on. An NSIS solution must continue to
work in the presence of these techniques, i.e. the presence of the work in the presence of these techniques. The presence of the tunnel
tunnel should not cause problems for end-to-end signaling, and it should not cause problems for end-to-end signaling, and it should
should also be possible to use NSIS signaling to control the also be possible to use NSIS signaling to control the treatment of
treatment of the packets carrying the tunneled data. the packets carrying the tunneled data.
It is assumed that the NSIS approach will be similar to that of [27], 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 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 with that data flow and is invisible to nodes along the path of the
tunnel (other than the endpoints). This provides backwards tunnel (other than the endpoints). This provides backwards
compatibility with networks where the tunnel endpoints do not support compatibility with networks where the tunnel endpoints do not support
the NSIS protocols. We assume that NEs will not unwrap tunnel the NSIS protocols. We assume that NEs will not unwrap tunnel
encapsulations to find and process tunneled signaling messages. encapsulations to find and process tunneled signaling messages.
To signal for the packets carrying the tunneled data, the tunnel is To signal for the packets carrying the tunneled data, the tunnel is
considered as a new data flow in its own right, and NSIS signaling is considered a new data flow in its own right, and NSIS signaling is
applied recursively to it. This requires signaling support in at applied to it recursively. This requires signaling support in at
least one tunnel endpoint. In some cases (where the signaling least one tunnel endpoint. In some cases (where the signaling
initiator is at the opposite end of the data flow from the tunnel initiator is at the opposite end of the data flow from the tunnel
initiator - i.e. in the case of receiver initiated signaling), there initiator; i.e., in the case of receiver initiated signaling), the
needs to be the ability to provide a binding between the original ability to provide a binding between the original flow identification
flow identification and that for the tunneled flow. It is left open and that for the tunneled flow is needed. It is left open here
here whether this should be an NTLP or an NSLP function. whether this should be an NTLP or an NSLP function.
6. Signaling Applications 6. Signaling Applications
This section gives an overview of NSLPs for particular signaling This section gives an overview of NSLPs for particular signaling
applications. The assumption is that the NSLP uses the generic applications. The assumption is that the NSLP uses the generic
functionality of the NTLP given earlier; this section describes functionality of the NTLP given earlier; this section describes
specific aspects of NSLP operation. It is intended to clarify by specific aspects of NSLP operation. It includes simple examples that
simple examples how NSLPs fit into the framework. It does not are intended to clarify how NSLPs fit into the framework. It does
replace or even form part of the formal NSLP protocol specifications; not replace or even form part of the formal NSLP protocol
in particular, initial designs are being developed for NSLPs for specifications; in particular, initial designs are being developed
resource reservation [28] and middlebox communication [29]. for NSLPs for resource reservation [28] and middlebox communication
[29].
6.1 Signaling for Quality of Service 6.1. Signaling for Quality of Service
In the case of signaling for QoS, all the basic NSIS concepts of In the case of signaling for QoS, all the basic NSIS concepts of
Section 3.1 apply. In addition, there is an assumed directionality Section 3.1 apply. In addition, there is an assumed directionality
of the signaling process, in that one end of the signaling flow takes of the signaling process, in that one end of the signaling flow takes
responsibility for actually requesting the resource. This leads to responsibility for actually requesting the resource. This leads to
the following definitions: the following definitions:
o QoS NSIS Initiator (QNI): the signaling entity which makes the o QoS NSIS Initiator (QNI): the signaling entity that makes the
resource request, usually as a result of user application request. resource request, usually as a result of user application request.
o QoS NSIS Responder (QNR): the signaling entity that acts as the o QoS NSIS Responder (QNR): the signaling entity that acts as the
endpoint for the signaling and can optionally interact with endpoint for the signaling and that can optionally interact with
applications as well. applications as well.
o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR
which propagates NSIS signaling further through the network. that propagates NSIS signaling further through the network.
Each of these entities will interact with a resource management Each of these entities will interact with a resource management
function (RMF) which actually allocates network resources (router function (RMF) that actually allocates network resources (router
buffers, interface bandwidth and so on). buffers, interface bandwidth, and so on).
Note that there is no constraint on which end of the signaling flow 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 should take the QNI role: With respect to the data flow direction, it
could be at the sending or receiving end. could be at the sending or receiving end.
6.1.1 Protocol Message Semantics 6.1.1. Protocol Message Semantics
The QoS NSLP will include a set of messages to carry out resource The QoS NSLP will include a set of messages to carry out resource
reservations along the signaling path. A possible set of message reservations along the signaling path. A possible set of message
semantics for the QoS NSLP is shown below. Note that the 'direction' semantics for the QoS NSLP is shown below. Note that the 'direction'
column in the table below only indicates the 'orientation' of the column in the table below only indicates the 'orientation' of the
message. Messages can be originated and absorbed at QNF nodes as 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 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 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 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 a reservation, during or after setup. This seems mainly a matter of
assumptions about authorization, and the possibilities might depend assumptions about authorization, and the possibilities might depend
on resource type specifics. on resource type specifics.
The table also explicitly includes a refresh operation. This does The table also explicitly includes a refresh operation. This does
nothing to a reservation except extend its lifetime, and is one nothing to a reservation except extend its lifetime, and it is one
possible state management mechanism (see next section). possible state management mechanism (see next section).
+-----------+-----------+-------------------------------------------+ +-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation | | Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+ +-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow | | Request | I-->R | Create a new reservation for a flow |
| | | | | | | |
| Modify | I-->R | Modify an existing reservation | | Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | | | | (&R-->I?) | |
| | | | | | | |
skipping to change at page 41, line 31 skipping to change at page 39, line 5
| | | | | | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a | | Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request | | Reject | | reservation request |
| | | | | | | |
| Notify | I-->R & | Report an event detected within the | | Notify | I-->R & | Report an event detected within the |
| | R-->I | network | | | R-->I | network |
| | | | | | | |
| Refresh | I-->R | State management (see Section 6.1.2) | | Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+ +-----------+-----------+-------------------------------------------+
6.1.2 State Management 6.1.2. State Management
The prime purpose of NSIS is to manage state information along the The primary purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in within the NTLP (state related to message transport) are described in
Section 4. The QoS NSLP will typically have to handle additional Section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made. state related to the desired resource reservation to be made.
There two critical issues to be considered in building a robust NSLP There two critical issues to be considered in building a robust NSLP
to handle this problem: to handle this problem:
o The protocol must be scalable. It should allow minimization of o The protocol must be scalable. It should allow minimization of
the resource reservation state storage demands that it implies for the resource reservation state-storage demands that it implies for
intermediate nodes; in particular, storage of state per 'micro' intermediate nodes; in particular, storage of state per 'micro'
flow is likely to be impossible except at the very edge of the flow is likely to be impossible except at the very edge of the
network. A QoS signaling application might require per flow or network. A QoS signaling application might require per-flow or
lower granularity state; examples of each for the case of QoS lower granularity state; examples of each for the case of QoS
would be IntServ [30] or RMD [31] (per 'class' state) would be IntServ [30] or RMD [31] (per 'class' state),
respectively. respectively.
o The protocol must be robust against failure and other conditions, o The protocol must be robust against failure and other conditions
which imply that the stored resource reservation state has to be that imply that the stored resource reservation state has to be
moved or removed. moved or removed.
For resource reservations, soft state management is typically used as For resource reservations, soft-state management is typically used as
a general robustness mechanism. According to the discussion of a general robustness mechanism. According to the discussion of
Section 3.2.5, the soft state protocol mechanisms are built into the Section 3.2.5, the soft-state protocol mechanisms are built into the
NSLP for the specific signaling application that needs them; the NTLP NSLP for the specific signaling application that needs them; the NTLP
sees this simply as a sequence of (presumably identical) messages. sees this simply as a sequence of (presumably identical) messages.
6.1.3 Route Changes and QoS Reservations 6.1.3. Route Changes and QoS Reservations
In this section, we will explore the expected interaction between In this section, we will explore the expected interaction between
resource signaling and routing updates (the precise source of routing resource signaling and routing updates (the precise source of routing
updates does not matter). The normal operation of the NSIS protocol updates does not matter). The normal operation of the NSIS protocol
will lead to the situation depicted in Figure 7, where the reserved will lead to the situation depicted in Figure 7, where the reserved
resources match the data path. resources match the data path.
reserved +-----+ reserved +-----+ reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF | =========>| QNF |===========>| QNF |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 42, line 30 skipping to change at page 40, line 4
will lead to the situation depicted in Figure 7, where the reserved will lead to the situation depicted in Figure 7, where the reserved
resources match the data path. resources match the data path.
reserved +-----+ reserved +-----+ reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF | =========>| QNF |===========>| QNF |
+-----+ +-----+ +-----+ +-----+
---------------------------------------> --------------------------------------->
data path data path
Figure 7: Normal NSIS Protocol Operation Figure 7: Normal NSIS Protocol Operation
A route change can occur while such a reservation is in place. The A route change can occur while such a reservation is in place. The
route change will be installed immediately and any data will be route change will be installed immediately, and any data will be
forwarded on the new path. This situation is depicted Figure 8. forwarded on the new path. This situation is depicted Figure 8.
Resource reservation on the new path will only be started once the Resource reservation on the new path will only be started once the
next control message is routed along the new path. This means that next control message is routed along the new path. This means that
there is a certain time interval during which resources are not there is a certain time interval during which resources are not
reserved on (part of) the data path, and certain delay or reserved on (part of) the data path, and certain delay or
drop-sensitive applications will require this time interval to be drop-sensitive applications will require that this time interval be
minimised. Several techniques to achieve this could be considered. minimized. Several techniques to achieve this could be considered.
As an example, RSVP [7] has the concept of local repair, where the As an example, RSVP [7] has the concept of local repair, whereby the
router may be triggered by a route change. In that case the RSVP router may be triggered by a route change. In that case, the RSVP
node can start sending PATH messages directly after the route has node can start sending PATH messages directly after the route has
been changed. Note that this option may not be available if no been changed. Note that this option may not be available if no
per-flow state is kept in the NF. Another approach would be to per-flow state is kept in the QNF. Another approach would be to
pre-install back-up state, and it would be the responsibility of the pre-install backup state, and it would be the responsibility of the
QoS-NSLP to do this, but mechanisms for identifying back-up paths and QoS-NSLP to do this. However, mechanisms for identifying backup
routing the necessary signaling messages along them are not currently paths and routing the necessary signaling messages along them are not
considered in the NSIS requirements and framework. currently considered in the NSIS requirements and framework.
Route update Route update
| |
v v
reserved +-----+ reserved +-----+ reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF | =========>| QNF |===========>| QNF |
+-----+ +-----+ +-----+ +-----+
-------- || -------- ||
\ || +-----+ \ || +-----+
| ===========>| QNF | | ===========>| QNF |
| +-----+ | +-----+
+---------------------------> +--------------------------->
data path data path
Figure 8: Route Change Figure 8: Route Change
It is not guaranteed that the new path will be able to provide the The new path might not be able to provide the same guarantees that
same guarantees that were available on the old path. Therefore, it were available on the old path. Therefore, it might be desirable for
might be desirable for the QNF to wait until resources have been the QNF to wait until resources have been reserved on the new path
reserved on the new path before allowing the route change to be before allowing the route change to be installed (unless, of course,
installed (unless of course the old path no longer exists). However, the old path no longer exists). However, delaying the route change
delaying the route change installation while waiting for reservation installation while waiting for reservation setup needs careful
setup needs careful analysis of the interaction with the routing analysis of the interaction with the routing protocol being used, in
protocol being used, in order to avoid routing loops. order to avoid routing loops.
Another example related to route changes is denoted as severe Another example related to route changes is denoted as severe
congestion and is explained in [31]. This solution adapts to a route congestion and is explained in [31]. This solution adapts to a route
change, when a route change creates congestion on the new routed change when a route change creates congestion on the new routed path.
path.
6.1.4 Resource Management Interactions 6.1.4. Resource Management Interactions
The QoS NSLP itself is not involved in any specific resource The QoS NSLP itself is not involved in any specific resource
allocation or management techniques. The definition of an NSLP for allocation or management techniques. The definition of an NSLP for
resource reservation with Quality of Service, however, implies the resource reservation with Quality of Service, however, implies the
notion of admission control. For a QoS NSLP, the measure of notion of admission control. For a QoS NSLP, the measure of
signaling success will be the ability to reserve resources from the signaling success will be the ability to reserve resources from the
total resource pool that is provisioned in the network. We define total resource pool that is provisioned in the network. We define
the function responsible for allocating this resource pool as the the function responsible for allocating this resource pool as the
Resource Management Function (RMF). The RMF is responsible for all Resource Management Function (RMF). The RMF is responsible for all
resource provisioning, monitoring and assurance functions in the resource provisioning, monitoring, and assurance functions in the
network. network.
A QoS NSLP will rely on the RMF to do resource management and to A QoS NSLP will rely on the RMF to do resource management and to
provide inputs for admission control. In this model, the RMF acts as provide inputs for admission control. In this model, the RMF acts as
a server towards client NSLP(s). It is noted, however, that the RMF a server towards client NSLP(s). Note, however, that the RMF may in
may in turn use another NSLP instance to do the actual resource turn use another NSLP instance to do the actual resource provisioning
provisioning in the network. In this case, the RMF acts as the in the network. In this case, the RMF acts as the initiator (client)
initiator (client) of an NSLP. of an NSLP.
This essentially corresponds to a multi-level signaling paradigm, This essentially corresponds to a multi-level signaling paradigm,
with an 'upper' level handling internetworking QoS signaling, with an 'upper' level handling internetworking QoS signaling
possibly running end-to-end, and a 'lower' level handling the more (possibly running end-to-end), and a 'lower' level handling the more
specialized intradomain QoS signaling, running between just the edges specialized intra-domain QoS signaling (running between just the
of the network (see [10], [32], and [33] for a discussion of similar edges of the network). (See [10], [32], and [33] for a discussion of
architectures). Given that NSIS signaling is already supposed to be similar architectures.) Given that NSIS signaling is already
able to support multiple instances of NSLPs for a given flow, and supposed to be able to support multiple instances of NSLPs for a
limited scope (e.g. edge-to-edge) operation, it is not currently given flow and limited scope (e.g., edge-to-edge) operation, it is
clear that supporting the multi-level model leads to any new protocol not currently clear that supporting the multi-level model leads to
requirements for the QoS NSLP. any new protocol requirements for the QoS NSLP.
The RMF may or may not be co-located with a QNF (note that The RMF may or may not be co-located with a QNF (note that
co-location with a QNI/QNR can be handled logically as a combination co-location with a QNI/QNR can be handled logically as a combination
between QNF and QNI/QNR). To cater for both cases, we define a between QNF and QNI/QNR). To cater for both cases, we define a
(possibly logical) NF-RMF interface. Over this interface, (possibly logical) QNF-RMF interface. Over this interface,
information may be provided from the RMF about monitoring, resource information may be provided from the RMF about monitoring, resource
availability, topology, and configuration. In the other direction, availability, topology, and configuration. In the other direction,
the interface may be used to trigger requests for resource the interface may be used to trigger requests for resource
provisioning. One way to formalize the interface between the QNF and provisioning. One way to formalize the interface between the QNF and
the RMF is via a Service Level Agreement (SLA). The SLA may be the RMF is via a Service Level Agreement (SLA). The SLA may be
static or it may be dynamically updated by means of a negotiation static or it may be dynamically updated by means of a negotiation
protocol. Such a protocol is outside the scope of NSIS. protocol. Such a protocol is outside the scope of NSIS.
There is no assumed restriction on the placement of the RMF. It may There is no assumed restriction on the placement of the RMF. It may
be a centralized RMF per domain, several off-path distributed RMFs, be a centralized RMF per domain, several off-path distributed RMFs,
or an on-path RMF per router. The advantages and disadvantages of or an on-path RMF per router. The advantages and disadvantages of
both approaches are well-known. Centralization typically allows both approaches are well-known. Centralization typically allows
decisions to be taken using more global information with more decisions to be taken using more global information, with more
efficient resource utilization as a result. It also facilitates efficient resource utilization as a result. It also facilitates
deployment or upgrade of policies. Distribution allows local deployment or upgrade of policies. Distribution allows local
decision processes and rapid response to data path changes. decision processes and rapid response to data path changes.
6.2 Other Signaling Applications 6.2. Other Signaling Applications
As well as the use for 'traditional' QoS signaling, it should be As well as the use for 'traditional' QoS signaling, it should be
possible to develop NSLPs for other signaling applications which possible to develop NSLPs for other signaling applications that
operate on different types of network control state. One specific operate on different types of network control state. One specific
case is setting up flow-related state in middleboxes (firewalls, case is setting up flow-related state in middleboxes (firewalls,
NATs, and so on). Requirements for such communication are given in NATs, and so on). Requirements for such communication are given in
[4]. Other examples include network monitoring and testing, and [4]. Other examples include network monitoring and testing, and
tunnel endpoint discovery. tunnel endpoint discovery.
7. Security Considerations 7. Security Considerations
This document describes a framework for signaling protocols which This document describes a framework for signaling protocols that
assumes a two-layer decomposition, with a common lower layer (NTLP) assumes a two-layer decomposition, with a common lower layer (NTLP)
supporting a family of signaling application specific upper layer supporting a family of signaling-application-specific upper-layer
protocols (NSLPs). The overall security considerations for the protocols (NSLPs). The overall security considerations for the
signaling therefore depend on the joint security properties assumed signaling therefore depend on the joint security properties assumed
or demanded for each layer. or demanded for each layer.
Security for the NTLP is discussed in Section 4.7. We have assumed Security for the NTLP is discussed in Section 4.7. We have assumed
that, apart from being resistant to denial of service attacks against that, apart from being resistant to denial of service attacks against
itself, the main role of the NTLP will be to provide message itself, the main role of the NTLP will be to provide message
protection over the scope of a single peer relationship, between protection over the scope of a single peer relationship, between
adjacent signaling application entities. (See Section 3.2.3 for a adjacent signaling application entities. (See Section 3.2.3 for a
discussion of the case where these entities are separated by more discussion of the case where these entities are separated by more
than one NTLP hop.) These functions can ideally be provided by an than one NTLP hop.) These functions can ideally be provided by an
existing channel security mechanism, preferably using an external key existing channel security mechanism, preferably using an external key
management mechanism based on mutual authentication. Examples of management mechanism based on mutual authentication. Examples of
possible mechanisms are TLS, IPsec and SSH. However, there are possible mechanisms are TLS, IPsec and SSH. However, there are
interactions between the actual choice of security protocol and the interactions between the actual choice of security protocol and the
rest of the NTLP design. Primarily, most existing channel security rest of the NTLP design. Primarily, most existing channel security
mechanisms require explicit identification of the peers involved at mechanisms require explicit identification of the peers involved at
the network and/or transport level. This conflicts with those the network and/or transport level. This conflicts with those
aspects of path-coupled signaling operation (e.g. discovery) where aspects of path-coupled signaling operation (e.g., discovery) where
this information is not even implicitly available because peer this information is not even implicitly available because peer
identities are unknown; the impact of this 'next-hop problem' on RSVP identities are unknown; the impact of this 'next-hop problem' on RSVP
design is discussed in the security properties document [6] and also design is discussed in the security properties document [6] and also
influences many parts of the threat analysis [2]. Therefore, this influences many parts of the threat analysis [2]. Therefore, this
framework does not mandate the use of any specific channel security framework does not mandate the use of any specific channel security
protocol; instead, this has to be integrated with the design of the protocol; instead, this has to be integrated with the design of the
NTLP as a whole. NTLP as a whole.
Security for the NSLPs is entirely dependent on signaling application Security for the NSLPs is entirely dependent on signaling application
requirements. In some cases, no additional protection may be requirements. In some cases, no additional protection may be
required compared to what is provided by the NTLP. In other cases, required compared to what is provided by the NTLP. In other cases,
more sophisticated object-level protection and the use of public key more sophisticated object-level protection and the use of public-
based solutions may be required. In addition, the NSLP needs to key-based solutions may be required. In addition, the NSLP needs to
consider the authorisation requirements of the signaling application. consider the authorization requirements of the signaling application.
Authorisation is a complex topic, for which a very brief overview is Authorization is a complex topic, for which a very brief overview is
provided in Section 3.3.7. provided in Section 3.3.7.
Another factor is that NTLP security mechanisms operate only locally, Another factor is that NTLP security mechanisms operate only locally,
whereas NSLP mechanisms may also need to operate over larger regions whereas NSLP mechanisms may also need to operate over larger regions
(not just between adjacent peers) especially for authorisation (not just between adjacent peers), especially for authorization
aspects; this complicates the analysis of basing signaling aspects. This complicates the analysis of basing signaling
application security on NTLP protection. application security on NTLP protection.
An additional concern for signaling applications is the session An additional concern for signaling applications is the session
identifier security issue (Section 4.6.2 and Section 5.2). The identifier security issue (Sections 4.6.2 and 5.2). The purpose of
purpose of this identifier is to decouple session identification (as this identifier is to decouple session identification (as a handle
a handle for network control state) from session "location" (i.e. for network control state) from session "location" (i.e., the data
the data flow endpoints). The identifier/locator distinction has flow endpoints). The identifier/locator distinction has been
been extensively discussed in the user plane for end-to-end data extensively discussed in the user plane for end-to-end data flows,
flows, and is known to lead to non-trivial security issues in binding and is known to lead to non-trivial security issues in binding the
the two together again; our problem is the analogue in the control two together again. Our problem is the analogue in the control
plane, and is at least similarly complex, because of the need to plane, and is at least similarly complex, because of the need to
involve nodes in the interior of the network as well. involve nodes in the interior of the network as well.
Further work on this and other security design will depend on a Further work on this and other security design will depend on a
refinement of the NSIS threats work begun in [2]. refinement of the NSIS threats work begun in [2].
8. References 8. References
8.1 Normative References 8.1. Normative References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004. April 2004.
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
draft-ietf-nsis-threats-06 (work in progress), October 2004. Steps in Signaling (NSIS)", RFC 4081, June 2005.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS) [3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003. Solution for Mobile IP", RFC 3583, September 2003.
[4] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, [4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements", RFC "Middlebox Communications (midcom) Protocol Requirements",
3304, August 2002. RFC 3304, August 2002.
8.2 Informative References 8.2. Informative References
[5] Manner, J., "Analysis of Existing Quality of Service Signaling [5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service
Protocols", draft-ietf-nsis-signalling-analysis-04 (work in Signaling Protocols", Work in Progress, December 2004.
progress), May 2004.
[6] Tschofenig, H., "RSVP Security Properties", [6] Tschofenig, H., "RSVP Security Properties", Work in Progress,
draft-ietf-nsis-rsvp-sec-properties-05 (work in progress), February 2005.
September 2004.
[7] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC [9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
2711, October 1999. RFC 2711, October 1999.
[10] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, [10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on [11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003. Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Tschofenig, H., "NSIS Authentication, Authorization and [12] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work Accounting Issues", Work in Progress, March 2003.
in progress), March 2003.
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC [13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
2961, April 2001. Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
[14] Ji, P., Ge, Z., Kurose, J. and D. Townsley, "A Comparison of [14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of
Hard-State and Soft-State Signaling Protocols", Computer Hard-State and Soft-State Signaling Protocols", Computer
Communication Review Volume 33, Number 4, October 2003. Communication Review, Volume 33, Number 4, October 2003.
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, [15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000. September 2000.
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, [16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda,
A. and T. Przygienda, "QoS Routing Mechanisms and OSPF A., and T. Przygienda, "QoS Routing Mechanisms and OSPF
Extensions", RFC 2676, August 1999. Extensions", RFC 2676, August 1999.
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and [17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000. Multicast Next-Hop Selection", RFC 2991, November 2000.
[18] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., [18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
Hunt, P., Higginson, P., Shand, M. and A. Lindem, "Virtual 3768, April 2004.
Router Redundancy Protocol", RFC 2338, April 1998.
[19] Heijenk, G., Karagiannis, G., Rexhepi, V. and L. Westberg, [19] Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg,
"DiffServ Resource Management in IP-based Radio Access "DiffServ Resource Management in IP-based Radio Access
Networks", Proceedings of 4th International Symposium on Networks", Proceedings of 4th International Symposium on
Wireless Personal Multimedia Communications WPMC'01, September Wireless Personal Multimedia Communications WPMC'01, September
9 - 12 2001. 9 - 12 2001.
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, [20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth,
E. and Y. Khouaja, "Evaluation of Mobility and QoS E., and Y. Khouaja, "Evaluation of Mobility and QoS
Interaction", Computer Networks Volume 38, Issue 2, pp 137-163, Interaction", Computer Networks Volume 38, Issue 2, p. 137-163,
5 February 2002. 5 February 2002.
[21] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[22] Liebsch, M., "Candidate Access Router Discovery", [22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and
draft-ietf-seamoby-card-protocol-08 (work in progress), E. Shim, "Candidate Access Router Discovery (CARD)", Work in
September 2004. Progress, May 2005.
[23] Kempf, J., "Problem Description: Reasons For Performing Context [23] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374, Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002. September 2002.
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", [25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000. RFC 2765, February 2000.
[26] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - [26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP [27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000. Operation Over IP Tunnels", RFC 2746, January 2000.
[28] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for [28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-05 Quality-of-Service signaling", Work in Progress, February 2005.
(work in progress), October 2004.
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol [29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-04 (work in progress), (NSLP)", Work in Progress, February 2005.
October 2004.
[30] Braden, B., Clark, D. and S. Shenker, "Integrated Services in [30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994. the Internet Architecture: an Overview", RFC 1633, June 1994.
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., [31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Partain, D., Pop, O., Rexhepi, V., Szabo, R. and A. Takacs, Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs,
"Resource Management in Diffserv (RMD): A Functionality and "Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop Performance Behavior Overview", Seventh International Workshop
on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April on Protocols for High-Speed networks PfHSN 2002, 22 - 24
2002. April 2002.
[32] Ferrari, D., Banerjea, A. and H. Zhang, "Network Support for [32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach", Berkeley Multimedia - A Discussion of the Tenet Approach",
TR-92-072, November 1992. Berkeley TR-92-072, November 1992.
[33] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit [33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet", RFC Differentiated Services Architecture for the Internet",
2638, July 1999. RFC 2638, July 1999.
Appendix A. Contributors
Several parts of the introductory sections of this document (in
particular, in Sections 3.1 and 3.3) are based on contributions from
Ilya Freytsis, then of Cetacean Networks, Inc.
Bob Braden originally proposed "A Two-Level Architecture for Internet
Signalling" as an Internet-Draft in November 2001. This document
served as an important starting point for the framework discussed
herein, and the authors owe a debt of gratitude to Bob for this
proposal.
Appendix B. Acknowledgements
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for
significant contributions in particular areas of this document. In
addition, the authors would like to acknowledge Cedric Aoun, Attila
Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler,
Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De
Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne,
Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars
Westberg, and Lixia Zhang for insights and inputs during this and
previous framework activities. Dave Oran, Michael Richardson, and
Alex Zinin provided valuable comments during the final review stages.
Authors' Addresses Authors' Addresses
Robert Hancock Robert Hancock
Siemens/Roke Manor Research Siemens/Roke Manor Research
Old Salisbury Lane Old Salisbury Lane
Romsey, Hampshire SO51 0ZN Romsey, Hampshire SO51 0ZN
UK UK
EMail: robert.hancock@roke.co.uk EMail: robert.hancock@roke.co.uk
skipping to change at page 50, line 14 skipping to change at page 48, line 25
Georgios Karagiannis Georgios Karagiannis
University of Twente University of Twente
P.O. BOX 217 P.O. BOX 217
7500 AE Enschede 7500 AE Enschede
The Netherlands The Netherlands
EMail: g.karagiannis@ewi.utwente.nl EMail: g.karagiannis@ewi.utwente.nl
John Loughney John Loughney
Nokia Research Center Nokia Research Center
11-13 Italahdenkatu 11-13 Itamerenkatu
Helsinki 00180 Helsinki 00180
Finland Finland
EMail: john.loughney@nokia.com EMail: john.loughney@nokia.com
Sven van den Bosch Sven Van den Bosch
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
EMail: sven.van_den_bosch@alcatel.be EMail: sven.van_den_bosch@alcatel.be
Appendix A. Contributors Full Copyright Statement
Several parts of the introductory sections of this document (in Copyright (C) The Internet Society (2005).
particular, in Section 3.1 and Section 3.3) are based on
contributions from Ilya Freytsis, then of Cetacean Networks, Inc.
Appendix B. Acknowledgements This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor This document and the information contained herein are provided on an
Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
significant contributions in particular areas of this draft. In OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
addition, the authors would like to acknowledge Cedric Aoun, Attila ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler, INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne,
Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars
Westberg, and Lixia Zhang for insights and inputs during this and
previous framework activities. Dave Oran, Michael Richardson and
Alex Zinin provided valuable comments during the final review stages.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/