draft-ietf-nsis-fw-02.txt   draft-ietf-nsis-fw-03.txt 
NSIS Working Group NSIS Working Group
Internet Draft Robert Hancock (editor) Internet Draft Robert Hancock (editor)
Siemens/Roke Manor Research Siemens/Roke Manor Research
Ilya Freytsis Ilya Freytsis
Cetacean Networks Cetacean Networks
Georgios Karagiannis Georgios Karagiannis
Ericsson University of Twente
John Loughney John Loughney
Nokia Nokia
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Document: draft-ietf-nsis-fw-02.txt Document: draft-ietf-nsis-fw-03.txt
Expires: September 2003 March 2003 Expires: December 2003 June 2003
Next Steps in Signaling: Framework Next Steps in Signaling: Framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 11 skipping to change at page 2, line 11
part in such signaling, and the relationship between signaling and part in such signaling, and the relationship between signaling and
the rest of network operation. We decompose the overall signaling the rest of network operation. We decompose the overall signaling
protocol suite into a generic (lower) layer, with a separate upper protocol suite into a generic (lower) layer, with a separate upper
layers for each specific signaling application. An initial proposal layers for each specific signaling application. An initial proposal
for the split between these layers is given, describing the overall for the split between these layers is given, describing the overall
functionality of the lower layer, and discussing the ways that upper functionality of the lower layer, and discussing the ways that upper
layer behavior can be adapted to specific signaling application layer behavior can be adapted to specific signaling application
requirements. requirements.
This framework also considers the general interactions between This framework also considers the general interactions between
signaling and other network layer functions, specifically routing and signaling and other network layer functions, specifically routing,
mobility. The different routing and mobility events that impact mobility, and address translators. The different events that impact
signaling operation are described, along with how their handling signaling operation are described, along with how their handling
should be divided between the generic and application-specific should be divided between the generic and application-specific
layers. Finally, an example signaling application (for Quality of layers. Finally, an example signaling application (for Quality of
Service) is described in more detail. Service) is described in more detail.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in RFC-2119 [1].
[Editor's note: if - as is likely - we don't end up using these words [Editor's note: if - as is likely - we don't end up using these words
in the framework, this paragraph will disappear.] in the framework, this paragraph will disappear.]
Table of Contents Table of Contents
1. Introduction...................................................3 1 Introduction ...................................................3
1.1 Definition of the NSIS Signaling Problem ...................3 1.1 Definition of the NSIS Signaling Problem .................3
1.2 Scope and Structure of the NSIS Framework ..................4 1.2 Scope and Structure of the NSIS Framework ................4
2. Terminology....................................................5 2 Terminology ....................................................5
3. Overview of Signaling Scenarios and Protocol Structure.........6 3 Overview of Signaling Scenarios and Protocol Structure .........6
3.1 Fundamental Signaling Concepts .............................6 3.1 Fundamental Signaling Concepts ...........................6
3.1.1 Simple Network and Signaling Topology ..................6 3.1.1 Simple Network and Signaling Topology ..................6
3.1.2 Signaling to Hosts, Networks and Proxies ...............7 3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7
3.1.3 Signaling Messages and Network Control State ...........9 3.1.3 Signaling to Hosts, Networks and Proxies ...............8
3.1.4 Data Flows and Sessions ...............................10 3.1.4 Signaling Messages and Network Control State ..........10
3.2 Layer Model for the Protocol Suite ........................11 3.1.5 Data Flows and Sessions ...............................10
3.2 Layer Model for the Protocol Suite ......................11
3.2.1 Layer Model Overview ..................................11 3.2.1 Layer Model Overview ..................................11
3.2.2 Layer Split Concept ...................................12 3.2.2 Layer Split Concept ...................................13
3.2.3 Core NTLP Functionality ...............................13 3.2.3 Core NTLP Functionality ...............................14
3.2.4 Path De-Coupled Operation .............................14 3.2.4 State Management Functionality ........................14
3.3 Signaling Application Properties ..........................14 3.2.5 Path De-Coupled Operation .............................15
3.3.1 Sender/Receiver Orientation ...........................15 3.3 Signaling Application Properties ........................16
3.3.2 Uni- and Bi-Directional Operation .....................16 3.3.1 Sender/Receiver Orientation ...........................16
3.3.3 Heterogeneous Operation ...............................16 3.3.2 Uni- and Bi-Directional Operation .....................17
3.3.4 Peer-Peer and End-End Relationships ...................17 3.3.3 Heterogeneous Operation ...............................18
3.3.5 Acknowledgements and Notifications ....................17 3.3.4 Peer-Peer and End-End Relationships ...................18
3.3.6 Security and other AAA Issues .........................18 3.3.5 Acknowledgements and Notifications ....................19
3.4 Open Layer Model Issues ...................................19 3.3.6 Security and Other AAA Issues .........................19
3.4.1 Classical Transport Functionality .....................19 4 The NSIS Transport Layer Protocol .............................20
3.4.2 State Management ......................................20 4.1 Internal Protocol Components ............................20
4. The NSIS Transport Layer Protocol.............................21 4.2 Addressing ..............................................21
4.1 Internal Protocol Components ..............................21 4.3 Classical Transport Functions ...........................22
4.2 Addressing ................................................22 4.4 Lower Layer Interfaces ..................................23
4.3 Lower Layer Interfaces ....................................22 4.5 Upper Layer Services ....................................24
4.4 Upper Layer Services ......................................23 4.6 Identity Elements .......................................24
4.5 Identity Elements .........................................24 4.6.1 Flow Identification ...................................24
4.5.1 Flow Identification ...................................24 4.6.2 Session Identification ................................25
4.5.2 Session Identification ................................24 4.6.3 Signaling Application Identification ..................25
4.5.3 Signaling Application Identification ..................25 4.7 Security Properties .....................................26
4.6 Security Properties .......................................25 5 Interactions with Other Protocols .............................26
5. Interactions with Other Protocols.............................26 5.1 IP Routing Interactions .................................26
5.1 IP Routing Interactions ...................................26 5.1.1 Load Sharing and Policy-Based Forwarding ..............27
5.1.1 Load Sharing and Policy-Based Forwarding ..............26
5.1.2 Route Changes .........................................28 5.1.2 Route Changes .........................................28
5.1.3 Router Redundancy .....................................29 5.1.3 Router Redundancy .....................................29
5.2 Mobility Interactions .....................................29 5.2 Mobility Interactions ...................................29
5.2.1 Addressing and Encapsulation ..........................30 5.2.1 Addressing and Encapsulation ..........................30
5.2.2 Localized Path Repair .................................30 5.2.2 Localized Path Repair .................................31
5.2.3 Update on the Unchanged Path ..........................31 5.2.3 Update on the Unchanged Path ..........................31
5.2.4 Interaction with Mobility Signaling ...................31 5.2.4 Interaction with Mobility Signaling ...................31
5.2.5 Interaction with Context Transfer .....................33 5.2.5 Interaction with Seamless Handover Protocols ..........33
5.3 Interactions with NATs ....................................33 5.3 Interactions with NATs ..................................33
6. Signaling Applications........................................34 6 Signaling Applications ........................................34
6.1 Signaling for Quality of Service ..........................34 6.1 Signaling for Quality of Service ........................34
6.1.1 Protocol Messages .....................................34 6.1.1 Protocol Messages .....................................34
6.1.2 State Management ......................................35 6.1.2 State Management ......................................35
6.1.3 QoS Forwarding ........................................36 6.1.3 QoS Forwarding ........................................36
6.1.4 Route Changes and QoS Reservations ....................36 6.1.4 Route Changes and QoS Reservations ....................36
6.1.5 Resource Management Interactions ......................38 6.1.5 Resource Management Interactions ......................38
6.2 Other Signaling Applications ..............................39 6.2 Other Signaling Applications ............................39
7. Security Considerations.......................................39 7 Security Considerations .......................................39
8. Change History................................................40 8 Change History ................................................40
8.1 Changes from draft-ietf-nsis-fw-01.txt ....................40 8.1 Changes from draft-ietf-nsis-fw-02.txt ..................40
8.2 Changes from draft-ietf-nsis-fw-01.txt ..................40
References.......................................................41 References.......................................................41
Acknowledgments..................................................44 Acknowledgments..................................................43
Authors' Addresses...............................................44 Authors' Addresses...............................................44
Intellectual Property Considerations.............................45 Intellectual Property Considerations.............................45
Full Copyright Statement.........................................46 Full Copyright Statement.........................................45
1. Introduction 1 Introduction
1.1 Definition of the NSIS Signaling Problem 1.1 Definition of the NSIS Signaling Problem
The NSIS working group is considering protocols for signaling The NSIS working group is considering protocols for signaling
information about a data flow along its path in the network. information about a data flow along its path 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 independent of the signaling itself; that is, signaling to set up the
routes themselves is not considered. Instead, the signaling simply routes themselves is not considered. Instead, the signaling simply
interacts with nodes along the data flow path. Additional 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; this is 'path-coupled' signaling in through these nodes themselves (i.e. the 'path-coupled' case, see
the sense described in [3], and that only unicast data flows are section 3.1.2) and that only unicast data flows are considered.
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 [4]. However, there are two generalizations. Firstly, the by RSVP [2]. However, there are two generalizations. Firstly, the
intention is that NSIS designs protocols that can be used in intention is that components of the NSIS protocols suite will be
different parts of the Internet, for different needs, without usable in different parts of the Internet, for different needs,
requiring a complete end-to-end deployment (in particular, the without requiring a complete end-to-end deployment (in particular,
signaling protocol messages may not need to run all the way between the signaling protocol messages may not need to run all the way
the data flow endpoints). between the data flow endpoints).
Secondly, the signaling is intended for more purposes than just QoS Secondly, 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 is to define both the signaling application. The scope of NSIS work is to define both the
generic protocol, and initially an upper layer suitable for QoS generic protocol, and initially an upper layer suitable for QoS
signaling similar to the corresponding functionality in RSVP. Further signaling similar to the corresponding functionality in RSVP. Further
signaling applications may be considered later. signaling applications, such as middlebox signaling, 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 [3]; other related requirements can be found in [5] and defined in [3] and a separate security threats document [4]; other
[6]. This framework does not replace or update these requirements. related requirements can be found in [5] and [6]. This framework does
Discussions about lessons to be learned from existing signaling and not replace or update these requirements. Discussions about lessons
resource protocols are contained in a separate analysis document [7]. to be learned from existing signaling and resource protocols are
contained in separate analysis documents [7], [8].
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 how the signaling work within the broader networking context, and how the signaling
protocols should be structured at the overall level. Therefore, it protocols should be structured at the overall level. 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 framework for NSIS is given in section 3. Section 3.1 The basic context for NSIS protocols is given in section 3. Section
describes the fundamental elements of NSIS operation in comparison to 3.1 describes the fundamental elements of NSIS protocol operation in
RSVP; in particular, section 3.1.2 describes more general signaling comparison to RSVP; in particular, section 3.1.3 describes more
scenarios, and 3.1.3 defines a broader class of signaling general signaling scenarios, and 3.1.4 defines a broader class of
applications for which the NSIS protocols should be useful. The two- signaling applications for which the NSIS protocols should be useful.
layer protocol architecture that supports this generality is The two-layer protocol architecture that supports this generality is
described in section 3.2, and section 3.3 gives examples of the ways described in section 3.2, and section 3.3 gives examples of the ways
in which particular signaling application properties can be in which particular signaling application properties can be
accommodated within signaling layer protocol behavior. accommodated within signaling layer protocol 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
protocol detailed design or even design options, although some are protocol detailed design or even design options, although some are
described as examples. The emphasis is on defining the interfaces described as examples. It describes the interfaces between this lower
between this lower layer protocol and the IP layer and signaling layer protocol and the IP layer (below) and signaling application
application protocols, including the identity elements that appear on protocols (above), including the identity elements that appear on
these interfaces. Following this, section 5 describes how signaling these interfaces. Following this, section 5 describes how signaling
applications that use the NSIS protocols can interact sensibly with applications that use the NSIS protocols can interact sensibly with
network layer operations, specifically routing (and re-routing), IP network layer operations, specifically routing (and re-routing), IP
mobility, and network address translation. mobility, and network address translation.
Section 6 describes particular signaling applications. The example of Section 6 describes particular signaling applications. The example of
signaling for QoS (comparable to core RSVP QoS signaling signaling for QoS (comparable to core RSVP QoS signaling
functionality) is described 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 over- background and for explanation; it is not intended to define an over-
arching architecture for carrying out resource management in the 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
[Editor's note: it is a matter of taste where we put this.] [Editor's note: it is a matter of taste where we put this.]
Classifier - an entity which selects packets based on their contents Classifier - an entity which 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 which is a
distinguishable subset of a packet stream. Each flow is distinguished distinguishable subset of a packet stream. Each flow is distinguished
by some flow identifier (see section 4.5.1). by some flow identifier (see section 4.6.1).
Edge node - a (NSIS-capable) node on the boundary of some Edge node - a (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 which 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 Entity (NE) - the function within a node which implements an
NSIS protocol. In the case of path-coupled signaling, the NE will NSIS protocol. In the case of path-coupled signaling, the NE will
always be on the data path. always be on the data path.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
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 Receiver - the node in the network which is receiving the data
packets in a flow. packets in a flow.
Sender - the node in the network which is sending the data packets in Sender - the node in the network which is sending the data packets in
a flow. a flow.
Session - application layer flow of information for which some Session - application layer flow of information for which some
network control state information is to be manipulated or monitored network control state information is to be manipulated or monitored
(see section 4.5.2). (see section 4.6.2).
Signaling application - the purpose of the NSIS signaling: a service Signaling application - the purpose of the NSIS signaling: a service
could be QoS management, firewall control, and so on. Totally could be QoS management, firewall control, and so on. Totally
distinct from any specific user application. 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 installed in the network. This state is related to a data flow and is installed
and maintained on the NSIS Entities (NEs) along the data flow path and maintained on the NSIS Entities (NEs) along the data flow path
through the network; not every node has to contain an NE. The basic through the network; not every node has to contain an NE. The basic
skipping to change at page 7, line 45 skipping to change at page 7, line 46
| |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 Signaling to Hosts, Networks and Proxies 3.1.2 Path-Coupled and Path-Decoupled Signaling
There are different possible triggers for the NSIS signaling. Amongst We can consider two basic paradigms for resource reservation
them are signaling applications (that are using NSIS signaling signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through
nodes (NEs) that are in the data path. They do not have to reach all
the nodes on the data path (for example, there could be proxies
distinct from the sender and receiver as described in section 3.1.3,
or intermediate signaling-unaware nodes); and between adjacent NEs,
the route taken by signaling and data might diverge. The path-coupled
case can be supported by various addressing styles, with messages
either explicitly addressed to the neighbor on-path NE, or routed
identically to the data packets and intercepted. These cases are
considered in section 4.2. In the second case, some network
configurations may split the signaling and data paths (see section
5.1.1); this is considered an error case for path-coupled signaling.
In the path-decoupled case, signaling messages are routed to nodes
(NEs) which are not assumed to be on the data path, but which are
(presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the signaling endpoints may have no
relation at all with the ultimate data sender or receiver. The
implications of path-decoupled operation for the NSIS protocols are
considered briefly in section 3.2.5; however, the initial goal of
NSIS and this framework is to concentrate mainly on the path-coupled
case.
3.1.3 Signaling to Hosts, Networks and Proxies
There are different possible triggers for the signaling protocols.
Amongst them are user applications (that are using NSIS signaling
services), other instances of the signaling, network management services), other instances of the signaling, network management
actions, some network events, and so on. The variety of possible actions, some network events, and so on. The variety of possible
triggers requires that the signaling can be initiated and terminated triggers requires that the signaling can be initiated and terminated
in the different parts of the network - hosts, domain boundary nodes in the different parts of the network - hosts, domain boundary nodes
(edge nodes) or interior domain nodes. (edge nodes) or interior domain nodes.
NSIS extends the RSVP model to consider this wider variety of The NSIS protocol suite extends the RSVP model to consider this wider
possible signaling exchanges. As well as the basic end-to-end model variety of possible signaling exchanges. As well as the basic end-to-
already described, examples such as end-to-edge and edge-to-edge can end model already described, examples such as end-to-edge and edge-
be considered. The edge-to-edge case might involve the edge nodes to-edge can be considered. The edge-to-edge case might involve the
communicating directly, as well as via the interior nodes. edge nodes communicating directly, as well as via the interior nodes.
While end-to-edge (host-to-network) scenario requires only intra- While the end-to-edge (host-to-network) scenario requires only intra-
domain signaling, the other cases might need inter-domain NSIS 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 latter cover single domain or multiple concatenated NSIS domains. The latter
case assumes the existence of the trust relation between domains. case assumes the existence of the trust relation 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 on the network that can be flow, but from the some other entities in the network that can be
called signaling proxies. There could be various reasons for this: called 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 can connection between host and network and so on. This configuration can
be considered as a kind of "on the data path", see Figure 2. be considered as a kind of "proxy on the data path", see Figure 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|| +--------+
|+--+| |+--+| |+--+| |+--+| |+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+--+ +--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages |NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ 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 a set of specific challenges to the NSIS This configuration presents 2 specific challenges for the signaling:
signaling:
*) The proxy that terminates signaling on behalf of the NSIS-unaware *) The 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 make determination
that it is a last NSIS aware node along the path. that it is a last NSIS aware node along the path.
*) Where a proxy initiates NSIS signaling on behalf of the NSIS *) Where a proxy initiates NSIS signaling on behalf of the NSIS
unaware host, interworking with some other "local" technology might unaware host, interworking with some other "local" technology might
be required, for example to provide QoS reservation from proxy to the be required, for example to provide QoS reservation from proxy to the
end host in the case of QoS signaling application. end host in the case of QoS signaling application.
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 off path for and from remote send and receive signaling information to a remote processor. The
processing. The NSIS protocols may or may not be suitable for this NSIS protocols may or may not be suitable for this remote
remote processing but in any case it is not currently part of the interaction, but in any case it is not currently part of the NSIS
NSIS problem. This configuration is supported by considering the NE problem. This configuration is supported by considering the NE as a
as 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.5. control architectures, see also section 6.1.5.
Receiver
+------+ +----+ +----+ +----+ +-----------+ +------+ +----+ +----+ +----+ +-----------+
|Sender|----->| PA |----->| R2 |----->| R3 | ---->|Application| |Sender|----->| PA |----->| R2 |----->| R3 | ---->| Receiver |
| | |+--+| |+--+| +----+ | +--+ | | | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|===|NE| | +------+ ||NE||======||NE||==================|===|NE| |
|+--+| |+--+| | +--+ | |+--+| |+--+| | +--+ |
+-..-+ +----+ +-----------+ +-..-+ +----+ +-----------+
.. ..
.. ..
..
..
+-..-+ +-..-+
|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
3.1.3 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 corresponding to that signaling application. An example for operation interesting to that signaling application. An example for
the case of an RSVP-like QoS signaling application would be state the case of an RSVP-like QoS signaling application would be state
data representing resource reservations. However, more generally, the data representing resource reservations. However, more generally, the
per-flow information might be related to some other control function per-flow information might be related to some other control function
in routers and middleboxes along the path. Indeed, the signaling in routers and middleboxes along the path. Indeed, the signaling
might simply be used to gather per-flow information, without might simply be used to gather per-flow information, without
modifying network operation at all. modifying network operation at all.
We call this information generically 'network control state'. We call this information generically 'network control state'.
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 state management is also possible. level, although coarser-grained ('per-class') state management is
also possible.
3.1.4 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 follow a unique path through the between the same endpoints which all follow a unique path through the
network (determined by IP routing and other network layer network (determined by IP routing and other network configuration). A
configuration). A flow is defined by a packet classifier (in the flow is defined by a packet classifier (in the simplest cases, just
simple cases, just the destination address and topological origin are the destination address and topological origin are needed). In
needed). In general we assume that when discussing only the data flow general we assume that when discussing only the data flow path, we
path, we only need to consider 'simple' fixed classifiers (e.g. IPv4 only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple
5-tuple or equivalent). or equivalent).
A session is an application layer concept for a (unidirectional) flow A session is an application layer concept for a (unidirectional) flow
of information between two endpoints, for which some network state is of information between two endpoints, for which some network state is
to be allocated or monitored. (Note that this use of the term to be allocated or monitored. (Note that this use of the term
'session' is distinct from the usage in RSVP. It is closer to the 'session' is not identical to the usage in RSVP. It is closer to the
session concept of, for example, the Session Initiation Protocol.) session concept of, for example, the Session Initiation Protocol.)
The simplest service provided by NSIS signaling is network control The simplest service provided by NSIS signaling protocols is
state management at the flow level, as described in the previous management of network control state at the level of a specific flow,
subsection. In particular, it is possible to monitor routing updates as described in the previous subsection. In particular, it should be
as they change the path taken by a flow and, for example, update possible to monitor routing updates as they change the path taken by
network state appropriately. This is no different from the case for a flow and, for example, update network state appropriately. This is
RSVP (local path repair). Where there is a 1:1 flow:session no different from the case for RSVP (local path repair). Where there
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-related However, for some more complex scenarios (especially mobility and
ones, see [3] and [8]) it is desirable to update the flow:session multihoming related ones, see [3] and the mobility discussion of [7])
relationship during the session lifetime. For example, a new flow can it is desirable to update the flow:session mapping during the session
be added, and the old one deleted (and maybe in that order, for a lifetime. For example, a new flow can be added, and the old one
'make-before-break' handover), effectively transferring the network deleted (and maybe in that order, for a 'make-before-break'
control state between data flows to keep it associated with the same handover), effectively transferring the network control state between
session. Such updates can only be managed by the end systems (because data flows to keep it associated with the same session. Such updates
of the packet classifier change). To enable this, it must be possible are best managed by the end systems (generally, systems which
for end systems to relate signaling messages to sessions as well as understand the flow:session mapping and are aware of the packet
data flows. classifier change). To enable this, it must be possible to relate
signaling messages to sessions as well as data flows. A session
identifier (section 4.6.2) is one component of the solution.
3.2 Layer Model for the Protocol Suite 3.2 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, it In order to achieve a modular solution for the NSIS requirements, the
is proposed to structure the NSIS protocol suite into 2 layers, NSIS protocol suite will be structured in 2 layers:
similar to the original proposal in [9]:
*) a 'signaling transport' layer, responsible for moving signaling *) 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
*) a 'signaling application' layer, which contains functionality *) a 'signaling application' layer, which contains functionality
such as message formats and sequences, specific to a particular such 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 component Protocol' (NSLP) to refer generically to any protocol within the
within the signaling application layer; in the end, there will be signaling application layer; in the end, there will be several NSLPs,
several NSLPs. These relationships are illustrated in Figure 4. Note largely independent of each other. These relationships are
that the NTLP may or may not have an interesting internal structure illustrated in Figure 4. Note that the NTLP may or may not have an
(e.g. based on the use of existing transport protocols) but that is interesting internal structure (e.g. including existing transport
not relevant at this level. 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 something | | +-----------------+ | for ... |
| +-----------------+ | else |
V +-----------------+ V +-----------------+
============================================= =============================================
^ +--------------------------------+ NSIS ^ +--------------------------------+
NSIS | | |
Transport | | NSIS Transport Layer Protocol | Transport | | NSIS Transport Layer Protocol |
Layer | | | Layer V +--------------------------------+
V +--------------------------------+
============================================= =============================================
+--------------------------------+ +--------------------------------+
| |
. 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 that which interacts strongly with other transport and
lower layer operations. lower layer operations.
Because NSIS problem includes multiple signaling applications, it is
very likely that a particular NSLP will only be implemented on a
subset of the NSIS-aware nodes on a path, as shown in Figure 5.
Messages for unrecognized NSLPs are forwarded at the NTLP level.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| 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
Because NSIS problem includes multiple signaling applications, it is
very likely that a particular NSLP will only be implemented on a
subset of the NSIS-aware nodes on a path, as shown in Figure 5.
Messages for unrecognized NSLPs are forwarded at the NTLP level.
3.2.2 Layer Split Concept 3.2.2 Layer Split Concept
This section describes the basic concepts which underlie how the This section describes the basic concepts underlying the
necessary functionality within the NTLP can be determined. Firstly, functionality of the NTLP. Firstly, we make a working assumption that
we make a working assumption that the protocol mechanisms of the NTLP the protocol mechanisms of the NTLP operate only between adjacent NEs
operate only between adjacent NEs (informally, the NTLP is a 'hop-by- (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger
hop' protocol), whereas any larger scope issues (including e2e scope issues (including e2e aspects) are left to the upper layers.
aspects) are left to the upper 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 (up- or down- to the NTLP to get it to the next NE along the path (up- or down-
stream), where it is received and the responsibility of the NTLP stream), 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, if there is an appropriate signaling application locally, passes or, if there is an appropriate signaling application locally, passes
it upwards for further processing; the signaling application can then it upwards for further processing; the signaling application can then
generate another message to be sent via the NTLP. In this way, larger generate another message to be sent via the NTLP. In this way, larger
scope (including end-to-end) message delivery can be automatically scope (including end-to-end) message delivery is achieved.
achieved.
This definition relates to NTLP operation. It is not intended to This definition relates to NTLP operation. It does not restrict the
restrict the ability of an NSLP to send messages by other means. For ability of an NSLP to send messages by other means. For example, an
example, an NE in the middle or end of the signaling path could send NE in the middle or end of the signaling path could send a message
a message directly to the other end as a notification of or directly to the other end as a notification of or acknowledgement for
acknowledgement for some signaling application event. However, it some signaling application event. However, the issues in sending such
appears that the issues in sending such messages (endpoint discovery, messages (endpoint discovery, security, NAT traversal and so on) are
security, NAT traversal and so on) are so different from the direct so different from the direct peer-peer case that there is no benefit
peer-peer case that there is no benefit in extending the scope of the in extending the NTLP to include such non-local functionality;
NTLP to include such non-local functionality; instead, an NSLP which instead, an NSLP which requires such messages and wants to avoid
requires such messages and wants to avoid traversing the path of NEs traversing the path of NEs should use some other existing transport
should use some other existing transport protocol - for example, UDP protocol - for example, UDP or DCCP would be a good match for many of
would be a good match for many of the scenarios that have been the scenarios that have been proposed. Acknowledgements and
proposed. Acknowledgements and notifications of this type are notifications of this type are considered further in section 3.3.5.
considered further in section 3.3.5.
One motivation for restricting the NTLP to only peer-relationship One motivation for restricting the NTLP to only peer-relationship
scope is that if there are any options or variants in design approach scope is that if there are any options or variants in design approach
- or, worse, in basic functionality - it is easier to manage the - or, worse, in basic functionality - it is easier to manage the
resulting complexity if it only impacts direct peers rather than resulting complexity if it only impacts direct peers rather than
potentially the whole network. potentially the whole Internet.
3.2.3 Core NTLP Functionality 3.2.3 Core NTLP 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 analysis has to be based on considering NSLP and NTLP. Note that the overall signaling solution will always be the
NTLP operation jointly; for example, we can always assume that an result of joint NSLP and NTLP operation; for example, we can always
NSLP is operating above the NTLP and taking care of end-to-end issues assume that an NSLP is operating above the NTLP and taking care of
(e.g. recovery of messages after restarts and so on). end-to-end issues (e.g. 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 most of the functions of appears that the NTLP can sensibly carry out many of the functions of
enabling signaling messages to pass through middleboxes, since this enabling signaling messages to pass through middleboxes, since this
is closely related to the problem of routing the signaling messages is closely related to the problem of routing the signaling messages
in the first place. in the first place. Further details about NTLP functionality are
contained in sections 3.2.4 and 4.3.
Two major open issues remain about NTLP functionality, namely what 3.2.4 State Management Functionality
classical transport capabilities (congestion avoidance,
retransmission and so on) it should have, or whether these functions
can be left entirely to the upper layers; and to what extent the NTLP
should provide a common state management service to the signaling
applications. These questions are discussed in section 3.4.
3.2.4 Path De-Coupled Operation Internet signaling requires the existence and management of state
within the network for several reasons. This section describes how
state management functionality is split across the NSIS layers.
0. How the NTLP internal state is managed is a matter for its design
and indeed implementation.
1. Conceptually, the NTLP provides a uniform message delivery
service. It is unaware of the difference in state semantics between
different types of signaling application message (e.g. whether a
message changes or just refreshes signaling application state, or
even has nothing to with signaling application state at all).
2. An NTLP instance processes and if necessary forwards all signaling
application messages "immediately". (It might offer different service
classes, but these would be distinguished e.g. by reliability or
priority, not state aspects.) This means that the NTLP does not know
explicit timer or message sequence information for the signaling
application; and that signaling application messages pass immediately
through an NSLP-unaware node (they can't be jittered there, or re-
sent onto alternative paths if re-routing takes place later).
3. Within any node, it's an implementation decision whether to
generate/jitter/filter refreshes either separately within each
signaling application that needs this functionality, or as part of
generic/shared code (a "soft-state management toolbox") more closely
associated with the NTLP. The choice doesn't affect the NTLP
specification at all. Implementations might piggy-back NTLP soft-
state refresh information (if the NTLP works this way) on signaling
application messages, or even combine soft-state management between
layers. The state machines of the NTLP and NSLPs remain logically
independent, but an implementation is free to allow them to interact
to reduce the load on the network to the same level as would be
achieved by a monolithic model.
4. It may be helpful for signaling applications to receive state-
management related 'triggers' from the NTLP, that a peer has failed
or become available ("down/up notifications"). These triggers would
be about adjacent NTLP peers, rather than signaling application
peers. We can consider this as another case of route change
detection/notification (which the NTLP is also allowed to do anyway).
However, apart from generating such triggers, the NTLP takes no
action itself on such events, other than to ensure that subsequent
signaling messages are correctly routed.
5. The existence of these triggers doesn't replace NSLP refreshes as
the mechanism for maintaining liveness at the signaling application
level. In this sense, up/down notifications are advisories which
allow faster reaction to events in the network, but shouldn't be
built into NSLP semantics. (This is essentially the same distinction
- with the same rationale - as SNMP makes between traps and normal
message exchanges.)
3.2.5 Path De-Coupled 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 (NEs) that are located on the data path. Signaling only through nodes that are located on the data path. Signaling
messages can be routed to NEs off the data path, but which are messages can be routed to nodes off the data path, but which are
(presumably) aware of it. This allows a looser coupling between NEs (presumably) aware of it. This allows a looser coupling between
and data plane nodes, e.g. at the AS level. signaling and data plane nodes, e.g. at the autonomous system level.
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. It would allow, for
instance, deploying a solution without upgrading any of the routers instance, deploying a solution without upgrading any of the routers
in the data plane. Additional functionality that can be supported in the data plane. Additional functionality that can be supported
includes the use of off-path proxies to support authorization or includes the use of off-path proxies to support authorization or
accounting architectures. 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. This effect, however, is orthogonal to the NSIS charter, handling; on the other hand, path-decoupled signaling is equally
since path-decoupled signaling is equally applicable to distributed applicable to distributed off-path entities. Failure recovery
off-path entities. Failure recovery scenarios need to be analyzed scenarios need to be analyzed differently because fate-sharing
differently because fate-sharing between data and control plane can between data and control plane can no longer be assumed. Furthermore,
no longer be assumed. Furthermore, the interpretation of the interpretation of sender/receiver orientation becomes less
sender/receiver orientation becomes less obvious. With the local natural. With the local operation of NTLP, the impact of path-
operation of NTLP, the impact of path-decoupled signaling on the decoupled signaling on the routing of signaling messages is
routing of signaling messages is presumably restricted to the problem presumably restricted to the problem of peer determination. The
of peer determination. The assumption that the off-path NEs are assumption that the off-path NSIS nodes are loosely tied to the data
loosely tied to the data path suggests, however, that peer path suggests, however, that peer determination can still be based on
determination can still be based on L3 routing information. L3 routing information. This means that a path-decoupled signaling
solution could be implemented using a lower layer protocol presenting
the same service interface to NSLPs as the path-coupled NTLP.
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 application in options would depend on detailed analysis of the signaling
question. application in question.
3.3.1 Sender/Receiver Orientation 3.3.1 Sender/Receiver Orientation
In some signaling applications, one end of the data flow takes In some signaling applications, a node at one end of the data flow
responsibility for requesting special treatment - such as a resource takes responsibility for requesting special treatment - such as a
reservation - from the network. The appropriate 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 characteristics of the network deployment.
A sender-initiated approach is when the sender of the data flow A sender-initiated approach is when the sender of the data flow
requests and maintains the resource reservation used for that flow. requests and maintains the treatment for that flow. In a receiver-
In a receiver-initiated approach the receiver of the data flow initiated approach the receiver of the data flow requests and
requests and maintains the resource reservation used for that flow. maintains the treatment for that flow. The NTLP itself has no freedom
The NTLP has no freedom in this area: next peers have to be in this area: next NTLP peers have to be discovered in the sender to
discovered in the sender to receiver direction, but after that time receiver direction, but after that time the default assumption is
the default assumption is that signaling is possible both upstream that signaling is possible both upstream and downstream (unless
and downstream (unless possibly an application specifically indicates possibly a signaling application specifically indicates this is not
this is not required). This implies that backward routing state must required). This implies that backward routing state must be
be maintained or that backward routing information must be available maintained by the NTLP or that backward routing information must be
in the signaling packet. available in the signaling message.
The sender and receiver initiated approaches have several differences The sender and receiver initiated approaches have several differences
in operational characteristics. The main ones are as follows: in their operational characteristics. The main ones are as follows:
*) In a receiver-initiated approach, the signaling messages traveling *) 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 the messages belonging to the same flow traveling from the sender to the
receiver. This implies that a backward routing state per flow must be receiver. In a sender-initiated approach, provided acknowledgements
maintained. When using a sender-initiated approach, provided and notifications can be securely delivered to the sending node,
acknowledgements and notifications can be securely delivered to the backward routing is not necessary, and nodes do not have to maintain
sending node, backward routing is not necessary, and nodes do not backward routing state.
have to maintain backward routing states.
*) In a sender-initiated approach, a mobile node can initiate a *) In a sender-initiated approach, a mobile node can initiate a
reservation for its outgoing flows as soon as it has moved to another reservation for its outgoing flows as soon as it has moved to another
roaming subnetwork. In a receiver-initiated approach, a mobile node roaming subnetwork. In a receiver-initiated approach, a mobile node
has to inform the receiver about its handover procedure, thus has to inform the receiver about its handover, thus allowing the
allowing the receiver to initiate a reservation for these flows. For receiver to initiate a reservation for these flows. For incoming
incoming flows, the reverse argument applies. flows, the reverse argument applies.
*) A sender- (receiver-) initiated approach will allow faster setup *) A sender- (receiver-) initiated approach will allow faster setup
and modification if the sender (receiver) is also authorized to carry and modification if the sender (receiver) is also authorized to carry
out the operation. A mismatch between authorizing and initiating NEs out the operation. A mismatch between authorizing and initiating NEs
will cause additional message exchanges either in the NSLP or in a will cause additional message exchanges either in the NSLP or in a
protocol executed prior to NSIS invocation. Note that this may protocol executed prior to NSIS invocation. Note that this may
complicate modifications of network control state for existing flows. complicate modifications of network control state for existing flows.
*) Where the signaling is looking for the last (nearest to receiver) *) Where the signaling is looking for the last (nearest to receiver)
NE on the data path, receiver oriented signaling is most efficient; NE on the data path, receiver oriented signaling is most efficient;
sender orientation would be possible, but take more messages. sender orientation would be possible, but take more messages.
*) In either case, the initiator can generally be informed faster *) In either case, the initiator can generally be informed faster
about reservation failures than the remote end. about reservation failures than the remote end.
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 one direction of the data flow. However, in other considered for a unidirectional data flow. However, in other cases,
cases, there may be interesting relationships between the signaling there may be interesting relationships between the signaling for the
for the two directions; an example is QoS for a voice call. In the two flows of a bi-directional session; an example is QoS for a voice
basic case, bi-directional signaling can simply use a separate call. Note that the path in the two directions may differ due to
instance of the same signaling mechanism in each direction. Note that asymmetric routing. In the basic case, bi-directional signaling can
the path in the two directions may differ due to asymmetric routing. simply use a separate instance of the same signaling mechanism in
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 NSIS is
signaling for will vary from one part of the network to another signaling for will vary from one part of the network to another
(depending on signaling application). For example in the QoS case, (depending on signaling application). For example in the QoS case,
resource descriptions that are valid for inter-domain links will resource descriptions that are valid for inter-domain links will
probably be different from those useful for intra-domain operation probably be different from those useful for intra-domain operation
(and the latter will differ from one NSIS domain to another). (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
carried within the NSLP as divided in globally-understood objects used within the NSLP as carried in globally-understood objects and
("global objects") and locally-understood objects ("local objects"). locally-understood objects. The local objects are only applicable for
The local objects are only applicable for intra-domain signaling, intra-domain signaling, while the global objects are mainly used in
while the global objects are mainly used in inter-domain signaling. inter-domain signaling. Note that the local objects are still part of
Note that such local objects are still part of the NSIS protocol and the protocol but are inserted, used and removed by one single domain.
can be inserted, used and removed by one 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 those objects defining the objects carried by the NSLP such that only the objects
that are applicable in a particular setting are used. An example applicable in a particular setting are used. One approach for
approach for reflecting the distinction in the signaling is that reflecting the distinction is that local objects could be put into
local objects could be put into separate local messages that are separate local messages that are initiated and terminated within one
initiated and terminated within one single NSIS domain and/or they single domain; an alternative is that they could be "stacked" within
could be "stacked" within the NSLP messages that are used for inter- the NSLP messages that are used anyway for inter-domain signaling.
domain signaling.
3.3.4 Peer-Peer and End-End Relationships 3.3.4 Peer-Peer and End-End Relationships
The assumption taken 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 simply relationship. End-to-end operation is built up by concatenating these
concatenating these relationships. Any non-local operation (if any) relationships. Non-local operation (if any) will take place in NSLPs.
will take place only in particular 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 can be achieved that a message has followed through the network. This can be achieved
by keeping per-flow state at the NSIS entities or by maintaining a by keeping per-flow state at the NSIS entities or by maintaining a
record route object in the messages. record route object in the messages.
Note that, for the reasons discussed in section 3.2.1, NSLP peers are Note that NSLP peers are not always NTLP peers (section 3.2.1). This
not inevitably NTLP peers. This has a number of implications for the has a number of implications for the relationship between the
relationship between the signaling layers, in that NSLP peers may signaling layers, in that NSLP peers may depend on the service
depend on the service provided by a concatenation of NTLP peer provided by a concatenation of NTLP peer relationships rather than a
relationships rather than a single one, which makes it harder to single one, which makes it harder to depend strongly on some NTLP
exploit fully some NTLP properties (e.g. channel security, properties (e.g. channel security, reliability).
reliability).
3.3.5 Acknowledgements and Notifications 3.3.5 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 any acknowledgements or notifications it generates are
handled purely internally (and apply within the scope of a single handled purely internally (and apply within the scope of a single
peer relationship). NTLP peer relationship).
However, we expect that some signaling applications will requires However, we expect that some signaling applications will requires
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 ensure NAT traversal in both directions. (If this by NEs and can allow NAT traversal in both directions. (If this
direction is towards the flow 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 can be made by sending acknowledgements domains), an optimization can be to send acknowledgements directly to
directly to the signaling initiator (see section 3.2.2). the signaling initiator outside the NTLP (see section 3.2.2).
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. This (necessarily) generated in response to other signaling messages. This
means that it may not be obvious to determine where the notification means that it may not be obvious to determine where the notification
should be sent. Other than that, the same considerations apply as for should be sent. Other than that, the same considerations apply as for
acknowledgements. One useful distinction to make would be to acknowledgements. One useful distinction to make would be to
differentiate between notifications that trigger a signaling action differentiate between notifications that trigger a signaling action
and others that don't. The security requirements for the latter are and others that don't. The security requirements for the latter are
less stringent, which means they could be sent directly to the NE less stringent, which means they could be sent directly to the NE
they are destined for (provided this NE can be determined). they are destined for (provided this NE can be determined).
3.3.6 Security and other AAA Issues 3.3.6 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 [10] signaling security by using basic 'channel security' mechanisms [9]
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.6. In other cases, signaling applications may have specific section 4.7. In other cases, signaling applications may have specific
security requirements, in which case they are free to invoke their security requirements, in which case they are free to invoke their
own authentication and key exchange mechanisms and apply 'object own authentication and key exchange mechanisms and apply 'object
security' to specific fields within the NSLP messages. security' to specific fields within the NSLP messages.
In addition to authentication, authorisation (to manipulate network In addition to authentication, the authorisation (to manipulate
control state) has to be considered as functionality above the NTLP network control state) has to be considered as functionality above
level, since it will be entirely application specific. Indeed, the NTLP level, since it will be entirely application specific.
authorisation decisions may be handed off to a third party in the Indeed, authorisation decisions may be handed off to a third party in
protocol (e.g. for QoS, the resource management function as described the protocol (e.g. for QoS, the resource management function as
in section 6.1.5). Many different authorisation models are possible, described in section 6.1.5). Many different authorisation models are
and the variations impact possible, and the variations impact:
*) what message flows take place - for example, whether authorisation *) what message flows take place - for example, whether authorisation
information is carried along with a control state modification information is carried along with a control state modification
request, or is sent in the reverse direction in response to it; request, or is sent in the reverse direction in response to it;
*) what administrative relationships are required - for example, *) what administrative relationships are required - for example,
whether authorisation takes place only between peer signaling whether authorisation 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 authorisation 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 [11]. contained in [10].
3.4 Open Layer Model Issues
3.4.1 Classical Transport Functionality
The first major issue is the extent to which the NTLP should include
'traditional' transport like functions, or whether these should be
seen as either fundamentally unnecessary or automatically handled by
the upper layers. The following functions have been identified as
candidates:
1. Local retransmission to improve reliability. The argument in favor
is that the NTLP can recover from congestive loss or corruption much
more rapidly than end-to-end (NSLP) mechanisms; the argument against
is that the additional complexity in the NTLP is not needed for all
signaling applications. (It's assumed that the NTLP is not actually
providing perfect message delivery guarantees or notifications, for
example because NSLP peers may be separated by more than one NTLP
peer relationship. A signaling application that needs peer-peer
acknowledgements of this nature should define them within the NSLP.)
In-order message delivery and duplicate detection are related
functions.
2. Congestion control. Here, the question is whether the NTLP should
include a common mechanism which protects the local portion of the
network from overload, or whether this can be derived from the
behavior of each signaling application.
3. Message fragmentation. For NSLPs that generate large messages, it
will be necessary to fragment and re-assemble them efficiently within
the network, where the use IP fragmentation may lead to reduced
reliability and be incompatible with some addressing schemes. (It's
assumed that the counterpart functionality, of bundling small
messages together, can be provided locally by the NTLP as an option
if desired; it doesn't affect the operation of the network
elsewhere.)
4. Flow control. Here, the question is how a receiving NSLP should be
protected from overload - whether the NTLP should provide a flow
controlled channel, or whether this should be managed using
application layer acknowledgements, for example.
It appears that all these issues don't affect the basic way in which
the NSLP/NTLP layers relate to each other (e.g. in terms of the
semantics of the inter-layer interaction); it is much more a question
of the overall performance/complexity tradeoff implied by placing
certain functions within each layer.
3.4.2 State Management
It is clear that the NTLP may have to manage some per-flow state to
carry out its message delivery functions (for example, state about
the reverse route for signaling messages, or state needed for route
change detection). How this state is stored and managed is an
internal matter for the NTLP (see section 4), and the details (in
particular, any connection model it might use) is in any case
entirely invisible to the signaling applications.
However, signaling applications are frequently managing network
control state for their own purposes, and it is an open issue how
much the NTLP should provide a common service to do this for them.
The simplest case is that the NTLP simply delivers messages, and any
state-related aspects (lifetimes, message semantics and so on) are
entirely invisible to it, being part of the signaling application
data. This provides the simplest interface between NTLP and NSLP.
The other extreme is where the NTLP provides a complete state
management service, including explicit commands for creation,
modification and deletion of state with known lifetimes in remote
nodes. This service could make it easy to write new signaling
applications, at the cost of increasing the complexity of the
NTLP/NSLP interface; in particular, there would be many more events
and error conditions to generate within the NTLP, and there may be
several different types of state management semantics required by
different signaling applications. The commonality with other parts of
NTLP functionality is not clear.
An intermediate case is where there is particular support for the
refresh messages used for soft-state maintenance. The characteristics
of these messages are that they can be sent and processed without
invoking signaling application specific logic, and that their timing
can be manipulated to fit in with other NTLP requirements (e.g.
jittering to avoid network synchronization, or to allow bundling with
other messages). Therefore, provided this functionality can be
defined simply and universally, there may be benefits in supporting
it within the NTLP itself. The implication would be that some NTLP
messages contain timing and other control information (to allow the
refresh to be handled correctly at intermediate NSLP-unaware nodes).
In addition, the automatic generation and reception of refreshes
could be handled above or below the NSLP/NTLP boundary (this seems to
be mainly an API issue).
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. and the different possible addressing modes that can be utilized, as
The interfaces between NTLP and the layers above and below it are well as the assumed transport and state management functionality. The
interfaces between NTLP and the layers above and below it are
identified, with a description of the identity elements that appear 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 It is not the intention of this discussion to design the NTLP or even
to discuss design options, although some are described as examples. to 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 described in section 3.2. within the NTLP is outlined in section 3.2.3, with some more details
in sections 3.2.4 and 4.3.
Some NTLP functionality could be provided via components existing 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, security and so on, then existing protocols, such as
TCP or TLS, could be incorporated into the NTLP. This possibility is TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP. This
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
active next-peer discovery functionality will be required within the
NTLP to support the explicit addressing of these messages. This could
use message exchanges for dynamic peer discovery as a sublayer within
the NTLP; there could also be an interface to external mechanisms to
carry out this function.
==================== =========================== ==================== ===========================
^ +------------------+ +-------------------------+ ^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions | | | | | NSIS Specific Functions |
| | | | .............| | | | | .............|
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
If peer-peer addressing (section 4.2) is used for some messages, then
active next-peer discovery functionality will be required within the
NTLP to support the explicit addressing of these messages. (This
could use message exchanges for dynamic peer discovery as a sublayer
within the NTLP; there could also be an interface to external
mechanisms to carry out this function.)
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 NSIS peers: between NTLP peers:
*) peer-peer, where the message is addressed to a neighboring NSIS *) 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.
*) end-to-end, where the message is addressed to the destination *) end-to-end, where the message is addressed to the flow
directly, and intercepted by an intervening NE. destination directly, and intercepted by an intervening NE.
With peer-peer addressing, an NE will determine that 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 the address of the destination NE to be
derivable from the information present in the payload. This can be derivable from the information present in the payload, either by
achieved through the availability of a local routing table or through using some local routing table or through participation in active
participation in active peer discovery message exchanges. Peer-peer peer discovery message exchanges. Peer-peer addressing inherently
addressing inherently supports tunneling of messages between NEs, and supports tunneling of messages between NEs, and is equally applicable
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 section
5.1.1 on this point). Note that securing messages sent this way 5.1.1 on this point). Note that securing messages sent this way
raises some interesting security issues (these are discussed in raises some interesting security issues (these are discussed in [4]).
[12]).
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.5.1) or locally stored available from the flow identifier (section 4.6.1) or locally stored
NTLP state. NTLP state.
4.3 Lower Layer Interfaces 4.3 Classical Transport Functions
The NSIS signaling protocols are responsible for transporting
(signaling) data around the network; in general, this requires
functionality such as congestion management, reliability, and so on.
This section discusses how much of this functionality should be
provided within the NTLP. It appears that this doesn't affect the
basic way in which the NSLP/NTLP layers relate to each other (e.g. in
terms of the semantics of the inter-layer interaction); it is much
more a question of the overall performance/complexity tradeoff
implied by placing certain functions within each layer.
The following functionality is assumed to lie within the NTLP:
1. Bundling together of small messages (comparable to [11]) can be
provided locally by the NTLP as an option if desired; it doesn't
affect the operation of the network elsewhere. The NTLP should
always support unbundling, to avoid the cost of negotiating the
feature as an option. Note that end-to-end addressed messages for
different flows cannot be bundled safely unless the next node on
the outgoing interface is known to be NSIS-aware.
2. Message fragmentation should be provided by the NTLP when needed.
For NSLPs that generate large messages, it will be necessary to
fragment them efficiently within the network, where the use of IP
fragmentation may lead to reduced reliability and be incompatible
with some addressing schemes. To avoid imposing the cost of
reassembly on intermediate nodes, the fragmentation scheme used
should allow for the independent forwarding of individual
fragments towards a node hosting an interested NSLP.
The placement of the following functionality is still open:
1. Overload detection and control. Here, the question is whether the
NTLP should include common mechanisms to handle overload at the
IP layer ("congestion control") and NTLP/NSLP layers (loosely
"flow control"). The arguments here are complex and somewhat
interrelated; a temporary summary can be found in [12].
2. Local retransmission to improve reliability. The argument in
favor is that the NTLP can recover from congestive loss or
corruption much more rapidly than end-to-end (NSLP) mechanisms;
the argument against is that the additional complexity in the
NTLP is not needed for all signaling applications. (It's assumed
that the NTLP is not actually providing perfect message delivery
guarantees or notifications, for example because NSLP peers may
be separated by more than one NTLP peer relationship. A signaling
application that needs peer-peer acknowledgements of this nature
should define them within the NSLP.) In-order message delivery
and duplicate detection are related functions.
3. Message summarization. Benefits have been found (see [11]) in
having the signaling protocol transport only 'tags' for refresh
signaling messages rather than the full messages themselves. In
the more flexible NSIS signaling environment, it is not clear if
this functionality can be provided correctly by the NTLP, or
whether it has to be done (less efficiently) by each NSLP.
These open issues will be resolved in a future version of this
document.
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:
*) The NTLP sends raw IP packets *) The NTLP sends raw IP packets
*) The NTLP receives raw IP packets. In the case of peer-peer *) The NTLP receives raw IP packets. In the case of peer-peer
addressing, they have been addressed directly to it. In the case of addressing, they have been addressed directly to it. In the case of
end-to-end addressing, this will be achieved by intercepting packets end-to-end addressing, this will be achieved by intercepting packets
that have been marked in some special way (by special protocol number that have been marked in some special way (by special protocol number
or by some option interpreted within the IP layer, such as the Router or by some option interpreted within the IP layer, such as the Router
Alert option [13] and [14]). Alert option [13] and [14]).
*) The NTLP receives indications from the IP layer regarding route *) The NTLP receives indications from the IP layer regarding route
changes and similar events (see section 5.1). changes and similar events (see 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.
For example, it needs to know: In general, it needs to know how to select the outgoing interface for
*) [in general] how to select the outgoing interface for a signaling a signaling message, where this must match the interface that will be
message, in case this needs to match the interface that will be used used by the corresponding flow. This might be as simple as just
by the corresponding flow. This might be as simple as just allowing allowing the IP layer to handle the message using its own routing
the IP layer to handle the message using its own routing table. There table. There is no intention to do something different from IP
is no intention to do something different from IP routing (for end- routing (for end-to-end addressed messages); however, some hosts
to-end addressed messages); however, some hosts allow applications to allow applications to bypass routing for their data flows, and the
bypass routing for their data flows, and the NTLP processing must NTLP processing must account for this. Further network layer
account for this. information would be needed to handled scoped addresses (if such
*) [in the case of IPv6] what address scopes are associated with the things ever will exist).
interface that messages are sent and received on (to interpret scoped
addresses in flow identification, if these are to be allowed).
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.4 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:
*) Send Message, to allow the signaling application to pass data to *) Send Message, to allow the signaling application to pass data to
the NTLP for transport. the NTLP for transport.
*) Receive Message, to allow the NTLP to pass received data to the *) Receive Message, to allow the NTLP to pass received data to the
skipping to change at page 24, line 4 skipping to change at page 24, line 30
*) Signaling application registration/de-registration, so that *) 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 to identifier to be agreed between the NTLP and signaling application to
allow support the exchange of further control information and to allow support the exchange of further control information and to
allow the de-multiplexing of incoming data. allow the de-multiplexing of incoming data.
*) NTLP configuration, allowing signaling applications to indicate *) NTLP configuration, allowing signaling applications to indicate
what optional NTLP features they want to use, and to configure NTLP what optional NTLP features they want to use, and to configure NTLP
operation, such as controlling what transport layer state should be operation, such as controlling what transport layer state should be
maintained. maintained.
*) Error messages, to allow the NTLP to indicate error conditions to *) Error messages, to allow the NTLP to indicate error conditions to
the signaling application and vice versa. the signaling application and vice versa.
*) Feedback information, such as route change indications so that *) Feedback information, such as route change indications so that the
the signaling application can decide what action to take. signaling application can decide what action to take.
The exact form of the primitives used across this interface and the
information exchanged by them depends on a decision about what the
responsibility of the layers is either side of the interface, and
where state is managed (see section 3.4.2).
4.5 Identity Elements 4.6 Identity Elements
4.5.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 that actual data itself, the same treatment along the data path as that 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:
skipping to change at page 24, line 45 skipping to change at page 25, line 16
(further analysis may be required). (further analysis may be required).
We've assumed here that the flow identification is not hidden within We've assumed here that the flow identification is not hidden within
the NSLP, but is explicitly part of the NTLP. The justification for the NSLP, but is explicitly part of the NTLP. The justification for
this is that it might be valuable to be able to do NSIS processing this is that it might be valuable to be able to do NSIS processing
even at a node which was unaware of the specific signaling even at a node which was unaware of the specific signaling
application (see section 3.2.1): an example scenario would be application (see section 3.2.1): an example scenario would be
messages passing through an addressing boundary where the flow messages passing through an addressing boundary where the flow
identification had to be re-written. identification had to be re-written.
4.5.2 Session Identification 4.6.2 Session Identification
There are circumstances where it is important to be able to refer to There are circumstances where it is important to be able to refer to
signaling application state independently of the underlying flow. signaling application state independently of the underlying flow.
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
skipping to change at page 25, line 17 skipping to change at page 25, line 35
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.5.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 well globally unique, and it should not be modified end-to-end. It is well
known that it is practically impossible to generate identifiers in a known that it is practically impossible to generate identifiers in a
way which guarantees this property; however, using a large random way which guarantees this property; however, using a large random
number makes it highly likely. In any case, the NTLP ascribes no number makes it highly likely. In any case, the NTLP ascribes no
valuable semantics to the identifier (such as 'session ownership'); valuable semantics to the identifier (such as 'session ownership');
this problem is left to the signaling application, which may be able this problem is left to the signaling application, which may be able
to secure it to use for this purpose. to secure it to use for this purpose.
4.5.3 Signaling Application Identification 4.6.3 Signaling Application Identification
Since the NTLP can be used to support several NSLP types, there is a Since the NTLP can be used to support several NSLP types, there is a
need to identify which type a particular signaling message exchange 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:
*) processing of incoming messages - the NTLP should be able to *) processing of incoming messages - the NTLP should be able to
demultiplex these towards the appropriate signaling applications; demultiplex these towards the appropriate signaling applications;
*) processing of general messages at an NSIS aware intermediate node *) processing of general messages at an NSIS aware intermediate node
- if the node does not handle the specific signaling application, it - if the node does not handle the specific signaling application, it
should be able to make a forwarding decision without having to parse should be able to make a forwarding decision without having to parse
upper layer information. 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
skipping to change at page 25, line 47 skipping to change at page 26, line 18
- if the node does not handle the specific signaling application, it - if the node does not handle the specific signaling application, it
should be able to make a forwarding decision without having to parse should be able to make a forwarding decision without having to parse
upper layer information. 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
NTLP design. NTLP design.
4.6 Security Properties 4.7 Security Properties
It is assumed that the only security service required within NTLP is It is assumed that the only security service required within NTLP is
channel security. Channel security requires a security association to channel security. Channel security requires a security association to
be established between the signaling endpoints, which is carried out be established between the signaling endpoints, which is carried out
via some authentication and key management exchange. This via some authentication and key management exchange. This
functionality could be provided by reusing a standard protocol. 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 26, line 26 skipping to change at page 26, line 45
layer, although most channel security mechanisms support them all. layer, although most channel security mechanisms support them all.
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 may differing granularity, i.e. all or parts of the signaling message may
be protected. For example, if the flow is traversing a NAT, only the 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 parts of the message that do not need to be processed by the NAT
should be protected. It is an open question as to which parts of the should be protected. It is an open question as to which parts of the
NTLP messages need protecting, and what type of protection should be NTLP messages need protecting, and what type of protection should be
applied to each. applied to each.
5. Interactions with Other Protocols 5 Interactions with Other Protocols
5.1 IP Routing Interactions 5.1 IP Routing Interactions
The NSIS Transport Layer (NTLP) is responsible for discovering the The NSIS Transport Layer (NTLP) is responsible for discovering the
next node to be visited by the signaling protocol. For path-coupled next node to be visited by the signaling protocol. For path-coupled
signaling, this next node should be the one that will be visited by signaling, this next node should be one that will be visited by the
the data flow. In practice, this peer discovery will be approximate, data flow. In practice, this peer discovery will be approximate, as
as any node could use any feature of the peer discovery packet to any node could use any feature of the peer discovery packet to route
route it differently than the corresponding data flow packets. it differently than the corresponding data flow packets. Divergence
Divergence between data and signaling path can occur due to load between data and signaling path can occur due to load sharing or load
sharing or load balancing (section 5.1.1). An example specific to the balancing (section 5.1.1). An example specific to the case of QoS is
case of QoS is given in section 6.1.1. Route changes cause a given in section 6.1.1. Route changes cause a temporary divergence
temporary divergence between the data path and the path on which between the data path and the path on which signaling state has been
signaling state has been installed. The occurrence, detection and installed. The occurrence, detection and impact of route changes is
impact of route changes is described in section 5.1.2. A description described in section 5.1.2. A description of this issue in the
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. The significance of load sharing in efficiency or network stability. The significance of load sharing in
the context of NSIS is that, if the load sharing mechanism in use the context of NSIS is that, if the load sharing mechanism in use
will forward packets on any basis other than the destination address, will forward packets on any basis other than the destination address,
routing of messages using end-to-end addressing does not guarantee routing of signaling messages using end-to-end addressing does not
that the messages will follow the data path. Policy-based forwarding guarantee that the messages will follow the data path. Policy-based
for data packets - where the outgoing link is selected based on forwarding for data packets - where the outgoing link is selected
policy information about fields additional to the packet destination based on policy information about fields additional to the packet
address - has the same impact. destination address - has the same impact.
Signaling and data flow packets may diverge because of these Signaling and data flow packets may diverge because of these
techniques. In OSPF, load balancing can be used between equal cost techniques. In OSPF, load balancing can be used between equal cost
paths [15] or unequal cost paths. An example of the latter approach paths [15] or unequal cost paths. An example of the latter approach
is Optimized Multi Path (OMP). OMP discovers multiple paths, not is Optimized Multi Path (OMP). OMP discovers multiple paths, not
necessarily equal cost paths, to any destinations in the network, but necessarily equal cost paths, to any destinations in the network, but
based on the load reported from a particular path, it determines based on the load reported from a particular path, it determines
which fraction of the data to direct to the given path. Incoming which fraction of the data to direct to the given path. Incoming
packets are subject to a (source, destination address) hash packets are subject to a (source, destination address) hash
computation, and effective load sharing is accomplished by means of computation, and effective load sharing is accomplished by means of
adjusting the hash thresholds. BGP [16][17] advertises the routes adjusting the hash thresholds. BGP [16][17] advertises the routes
chosen by the BGP decision process to other BGP speakers. In the chosen by the BGP decision process to other BGP speakers. In the
basic specification, routes with the same Network Layer reachability basic specification, routes with the same Network Layer reachability
information (NLRI) as previously advertised routes implicitly replace information (NLRI) as previously advertised routes implicitly replace
the original advertisement, which means that multiple paths for the the original advertisement, which means that multiple paths for the
same prefix cannot exist. Recently, however, a new mechanism was same prefix cannot exist. This restriction could be removed by
defined that will allow the advertisement of multiple paths for the suitable extensions to BGP.
same prefix without the new paths implicitly replacing any previous
ones [18]. The essence of the mechanism is that each path is
identified by an arbitrary identifier in addition to its prefix.
If the routing decision is based on both source and destination If the routing decision is based on both source and destination
address, signaling and data flow packets may still diverge because of address, signaling and data flow packets may still diverge because of
layer 4 load-balancing (based on TCP/UDP or port-based). Such layer 4 load-balancing (based on protocol or port number). Such
techniques would, however, constrain the use of proxies. Proxies techniques would, however, constrain the use of proxies. Proxies
would cause ICMP errors to be misdirected to the source of the data would cause ICMP errors to be misdirected to the source of the data
because of source address spoofing. because of source address spoofing.
If the routing decision is based on the complete five-tuple, If the routing decision is based on the complete five-tuple,
divergence may still occur because of the presence of router alert divergence may still occur because of the presence of router alert
options. In this case, the same constraint on proxy use applies as options. In this case, the same constraint on proxy use applies as
above. Additionally, it becomes difficult for the end systems to above. Additionally, it becomes difficult for the end systems to
distinguish between data and signaling packets. Finally, QoS routing distinguish between data and signaling packets. Finally, QoS routing
techniques (section 6.1.3) may base the routing decision on any field techniques (section 6.1.3) may base the routing decision on any field
skipping to change at page 28, line 19 skipping to change at page 28, line 32
becomes available, this route is installed in the forwarding table becomes available, this route is installed in the forwarding table
and will be used for all subsequent (data and signaling) packets. and will be used for all subsequent (data and signaling) packets.
This can cause a divergence between the path along which state has This can cause a divergence between the path along which state has
been installed and the path along which forwarding will actually take been installed and the path along which forwarding will actually take
place. place.
The possibility of route changes requires the presence of three The possibility of route changes requires the presence of three
processes in the signaling protocol processes in 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. teardown of state on the old path 3. removal of state on the old path
Many route change detections methods can be used, some of which need Many route change detections methods can be used, some of which need
explicit protocol support and some of which are implementation- explicit protocol support and some of which are implementation-
internal. They differ in their speed of reaction and the types of internal. They differ in their speed of reaction and the types of
change they can detect. In rough order of increasing applicability, change they can detect. In rough order of increasing applicability,
they can be summarized as: they can be summarized as:
a) monitoring changes in local interface state a) monitoring changes in local interface state
b) monitoring network-wide topology changes in a link-state routing b) monitoring network-wide topology changes in a link-state routing
protocol protocol
c) inference from changes in data packet TTL c) inference from changes in data packet TTL
d) inference from loss of packet stream in a downstream flow-aware d) inference from loss of packet stream in a downstream flow-aware
router router
e) inference from changes in signalling packet TTL e) inference from changes in signaling packet TTL
f) changed route of a PATH-like (end-to-end addressed) signaling f) changed route of a PATH-like (end-to-end addressed) signaling
packet packet
g) changed route of a specific end-to-end addressed probe packet g) changed route of a specific end-to-end addressed probe packet
There are essentially three ways in which detection can happen: based There are essentially three ways in which detection can happen: based
on network monitoring (method a-b), based on data packet monitoring on network monitoring (method a-b), based on data packet monitoring
(method c-d) and based on monitoring signaling protocol messages (method c-d) and based on monitoring signaling protocol messages
(method e-g). Methods contingent on monitoring signaling messages (method e-g). Methods contingent on monitoring signaling messages
become less effective as refresh reduction techniques are used. become less effective as refresh reduction techniques are used.
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. In order to be
able to avoid duplicate state installation or, worse, rejection of able to avoid duplicate state installation or, worse, rejection of
the signaling message because of previously installed state, it is the signaling message because of previously installed state, it is
important to be able to recognize the new signaling message as important to be able to recognize the new signaling message as
belonging to an existing session. In this respect, we distinguish belonging to an existing session. In this respect, we distinguish
between route changes with associated change of the flow between route changes with associated change of the flow
specification (e.g. in case of a mobility event when the IP source identification (e.g. in case of a mobility event when the IP source
might change) and route changes without change of the flow might change) and route changes without change of the flow
specification (e.g. in case of a link failure along the path). The identification (e.g. in case of a link failure along the path). The
former case requires an identifier independent from the flow former case requires an identifier independent from the flow
specification. identification, i.e. the session identifier (section 4.6.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 required messages. Depending on the refresh timer, however, it may be required
to tear down this state much faster (e.g. because it is tied to an to tear down this state much faster (e.g. because it is tied to an
accounting record). In that case, the teardown message needs to be accounting record). In that case, the teardown message needs to be
able to distinguish between the new path and the old path. able to distinguish between the new path and the old path.
The problem of route changes would not occur if there was a way to do The problem of route changes would not occur if there was a way to do
route pinning. Route pinning refers to the independence of the path route pinning. Route pinning refers to the independence of the path
taken by certain data packets from reachability changes caused by taken by certain data packets from reachability changes caused by
routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an
Exterior Gateway Protocol (BGP). Exterior Gateway Protocol (BGP).
5.1.3 Router Redundancy 5.1.3 Router Redundancy
In some environments, it is desired to provide connectivity and per In some environments, it is desired to provide connectivity and per
flow or per class flow management with high-availability flow or per class flow 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 involve interactions with the presence of route changes. This may need interactions with protocols
basic protocols which are used to manage the routing in this case, which are used to manage the routing in this case, such as VRRP [18].
such as VRRP [19]. A future version of this document may consider A future version of this document might consider interactions between
interactions between NSIS and such protocols in support of high NSIS and such protocols to support high availability functionality.
availability functionality.
5.2 Mobility Interactions 5.2 Mobility Interactions
Mobility, in most cases, causes changes to the data path that packets Mobility, in most cases, causes changes to the data path that packets
take. Assuming that signaling has taken place prior to any mobility take. Assuming that signaling has already taken place to establish
to establish some state along the data path, new signaling may be some state along the data path, new signaling may be needed in order
needed in order to (re)establish state along the changed data path. to (re)establish state along the changed data path.
The interactions between mobility and signaling protocols have been The interactions between mobility and signaling protocols have been
extensively analyzed in recent years, primarily in the context of extensively analyzed in recent years, primarily in the context of
RSVP and Mobile IP interaction (e.g. [20]), but also in the context RSVP and Mobile IP interaction (e.g. the mobility discussion of [7]),
of other types of network (e.g. [21]). This analysis work has shown but also in the context of other types of network (e.g. [19]); a
that some difficulties in the interactions are quite deeply rooted in general review of the fundamental interactions is given in [20],
the detailed design of these protocols; however, the problems and which provides further details on many of the subjects considered in
their possible solutions fall under five broad headings. The main these sections. This analysis work has shown that some difficulties
issues for a resource signaling application are limiting the period in the interactions are quite deeply rooted in the detailed design of
after handovers during for which the resource states are not these protocols; however, the problems and their possible solutions
available along the path; and avoiding double reservations - fall under five broad headings. The main issues for a resource
reservations on both the old path and new path. Similar issues may signaling application are limiting the period after handovers during
apply to other types of signaling application. which the resources are not available along the path; and avoiding
double reservations (reservations on both the old and new path).
Similar issues may apply to other types of signaling application.
5.2.1 Addressing and Encapsulation 5.2.1 Addressing and Encapsulation
A mobility solution typically involves address reallocation on A mobility solution typically involves address reallocation on
handover (unless a network supports per host routing) and may involve handover (unless a network supports per host routing) and may involve
special packet formats (e.g. the routing header and Home Address special packet formats (e.g. the routing header and Home Address
option of MIPv6). Since NSIS may depend on end system addresses for option of MIPv6). Since signaling may depend on end system addresses
forwarding signaling messages and defining flows (section 4.5.1), the for forwarding signaling messages and defining flows (section 4.6.1),
special implications of mobility for addressing need to be the special implications of mobility for addressing need to be
considered. Examples of possible approaches that could be used to considered. The two possible approaches are as follows:
solve the addressing and encapsulation problem are as follows:
* Use a flow identification based on low level IP addresses (e.g. the *) Use a flow identification based on low level IP addresses (e.g.
Care of Address) and other 'standard' fields in the IP header. This the Care of Address) and other 'standard' fields in the IP header.
makes least demands on the packet classification engines within the This makes least demands on the packet classification engines within
network. However, it means that even on a part of the flow path that the network. However, it means that even on a part of the flow path
is unchanged, the session will need to be modified to reflect the that is unchanged, the session will need to be modified to reflect
changed flow identification (see section 5.2.3). the changed flow identification (see section 5.2.3).
* Use a flow identification that does not change (e.g. based on Home *) Use a flow identification that does not change (e.g. based on Home
Address); this is the approach assumed in [22]. This simplifies the Address). This simplifies the problem of session update, at the
problem of session update, at the likely cost of considerably likely cost of considerably complicating the flow identification
complicating the flow identification requirements. requirements and making stronger demands on packet classification.
In the first approach, to prevent double reservation, NSIS entities In the first approach, to prevent double reservation, NSIS entities
need to be able to recognize that a session with the new flow need to be able to recognize that a session with the new flow
identifier is to be correlated with an existing one. A session identifier is to be correlated with an existing one. A session
identifier could be used for this purpose. This is why the session identifier (section 4.6.2) could be used for this purpose, but it
identifier as described in section 4.5.2 has to have end-to-end needs to have global semantics.
semantics.
While the feasibility and performance of this first approach needs to While the feasibility of the first approach needs to be proven, given
be assessed, given the high impact of requiring more sophisticated the impact of requiring more sophisticated packet classifiers, it
packet classifiers, it still seems more plausible than the second still seems more plausible than the second. This means that signaling
approach. This implies that signaling applications should define applications should define flows in terms of real, routable (care of)
flows in terms of real, routable (care of) addresses rather than addresses rather than virtual (home) addresses.
virtual (home) addresses.
5.2.2 Localized Path Repair 5.2.2 Localized Path Repair
In any mobility approach, a handover will cause at least some changes In any mobility approach, a handover will cause at least some changes
in the path of upstream and downstream packets. At some point along in the path of upstream and downstream packets. At some point along
the joined path, an NSIS entity should be able to recognize this the joined path, an NSIS entity should be able to recognize this
situation, based upon session identification. New state needs to be situation, based upon session identification. State needs to be
installed on the new path, and removed from the old. Who triggers the installed on the new path, and removed from the old. Who triggers the
new state may be constrained by which entities are allowed to carry new state may be constrained by which entities are authorised to
out which state manipulations, which is then a signaling application carry out which state manipulations, which is then a signaling
question. application question.
A critical point here is the signaling that is used to discover the A critical point here is the signaling that is used to discover the
crossover node. This is a generalization of the problem of finding crossover node. This is a generalization of the problem of finding
next-NSIS peer: it requires extending the new path over several hops next-NSIS peer: it requires extending the new path until it
until it intersects the old one. This is easy for the uplink intersects the old one. This is easy for the uplink direction (where
direction (where the mobile is the sender), but much harder for the mobile is the sender), but much harder for downlink without
downlink without signaling via the correspondent. There is no reason signaling via the correspondent. There is no reason for the crossover
for the crossover node for uplink and downlink flows to be the same, node to be the same for uplink and downlink flows, even for the same
even for the same correspondent. The problem is discussed further in correspondent. The problem is discussed further in [21].
[23].
5.2.3 Update on the Unchanged Path 5.2.3 Update on the Unchanged Path
On the path between the crossover node(s) and the correspondent, it On the path between the crossover node(s) and the correspondent, it
is necessary to avoid, if possible, double reservations, but rather is necessary to avoid, if possible, double reservations, but also to
to update the network control state to reflect new flow update the network control state to reflect new flow identification
identification (this is needed, by the default assumption of section (this is needed, by the default assumption of section 5.2.1).
5.2.1). Examples of approaches that could be used to solve this Examples of approaches that could be used to solve this problem are
problem are the following: the following:
*) Use a session state identification that does not change even if *) Use a session state identification that does not change even if
the flow definition changes (see Section 4.5.2). Signaling is still the flow definition changes (see Section 4.6.2). Signaling is still
needed to update a changed flow identification, but it should be needed to update a changed flow identification, but it should be
possible to avoid AAA and admission control processing. possible to avoid AAA and admission control processing.
*) Use an NSIS-capable crossover router that manages this update *) Use an NSIS-capable crossover router that manages this update
autonomously (more efficiently than the end nodes could), with autonomously (more efficiently than the end nodes could), with
similar considerations to the local path repair case. similar considerations to the local path repair case.
Note that in the case of an address change, end to end message Note that in the case of an address change, end to end message
exchanges will be required at the application layer anyway, so exchanges will be required at the application layer anyway, so
signaling to update the flow identifier does not necessarily add to signaling to update the flow identifier does not necessarily add to
the handover latency. the handover latency.
5.2.4 Interaction with Mobility Signaling 5.2.4 Interaction with Mobility Signaling
In existing work on mobility protocol and signaling protocol In existing work on mobility protocol and signaling protocol
interactions, several framework proposals describing the protocol interactions, several framework proposals describing the protocol
interactions have been made. Usually they have taken existing interactions have been made. Usually they have taken existing
protocols (Mobile IP and RSVP respectively) as the starting point; it protocols (Mobile IP and RSVP respectively) as the starting point; it
should be noted that an NSIS protocol might operate in quite a should be noted that an NSIS protocol might operate in quite a
different way. In this section, we provide an overview of how these different way. In this section, we provide an overview of how these
proposals would be reflected in framework of NSIS. The mobility proposals fit within the rest of this framework. The mobility aspects
aspects are described using Mobile IP terminology, but are generally are described using MIP terminology, but are generally applicable to
applicable to other network layer mobility solutions. The purpose of other network layer mobility solutions. The purpose of this overview
this overview is not to select or prioritise any particular approach, is not to select any particular approach, but simply to point out how
but simply to point out how they would fit into our framework and any they would fit into our framework and any major issues with them.
major issues with them.
We can consider that two signaling processes are active: mobility We can consider that two signaling processes are active: mobility
signaling and NSIS signaling. The discussion so far considered how signaling and NSIS signaling. The discussion so far considered how
NSIS signaling should operate. There is still a question of how the NSIS signaling should operate. There is still a question of how the
interactions between the NSIS and mobility signaling should be interactions between the NSIS and mobility signaling should be
considered. considered.
The basic case of totally independent specification and The basic case of totally independent specification and
implementation seems likely to lead to ambiguities and even implementation can lead to ambiguities and even interoperability
interoperability problems (see [22]). At least, the addressing and problems. At least, the addressing and encapsulation issues for
encapsulation issues for mobility solutions that use virtual links or mobility solutions that use virtual links or their equivalents need
their equivalents need to be specified in an implementation-neutral to be specified in an implementation-neutral way.
way.
A type of 'loose' integration is to have independent protocol A type of 'loose' integration is to have independent protocols, but
definitions, but to define how they trigger each other - in to define how they trigger each other - in particular, how the
particular, how the mobility protocol triggers sending of mobility protocol triggers sending of refresh/modify/tear messages. A
refresh/modify/tear messages. A pair of implementations could use pair of implementations could use these triggers to improve
these triggers to improve performance, primarily reducing latency. performance, primarily reducing latency. (Existing RSVP modifications
(Existing RSVP modifications consider the closer interaction of consider the closer interaction of making the RSVP implementation
making the RSVP implementation mobility routing aware, e.g. so it is mobility routing aware, e.g. so it is able to localize refresh
able to localize refresh signaling; this would be a self contained signaling; this would be a self contained aspect of NSIS.)
aspect of NSIS.) This information could be developed by analyzing
message flows for various mobility signaling scenarios as was done in
[20].
An even tighter level of integration is to consider a single protocol An even tighter level of integration is to consider a single protocol
carrying both mobility and network control state information. carrying both mobility and network control state information.
Logically, there are two cases: Logically, there are two cases:
1. Carry mobility routing information (a 'mobility object') in the 1. Carry mobility routing information (a 'mobility object') in the
signaling messages, as is done in [22]. (The prime purpose in this signaling messages. (The prime purpose in this approach is to enable
approach is to enable crossover router discovery.) crossover router discovery.)
2. Carry signaling in the mobility messages, typically as a new 2. Carry signaling in the mobility messages, typically as a new
extension header. This was proposed in [24] and followed up in [25]; extension header. In our framework, we could consider this a special
[26] also anticipates this approach. In our framework, we could case of NSIS layering, with the mobility protocol playing the role of
consider this a special case of NSIS layering, with the mobility the signaling transport.
protocol playing the role of the signaling transport.
Other modes of interaction might also be possible. The critical point Other modes of interaction might also be possible. The critical point
with all these models is that the general solutions developed by NSIS with all these models is that the general solutions developed by NSIS
should be independent of mobility protocols. Tight integration would should be independent of choice of mobility protocols. Tight
have major deployment issues especially in interdomain cases. integration would have major deployment issues especially in
Therefore, any tightly integrated solution is considered out of scope interdomain cases. Therefore, any tightly integrated solution is
of initial NSIS development. considered out of scope of initial development.
5.2.5 Interaction with Context Transfer 5.2.5 Interaction with Seamless Handover Protocols
In the context of mobility between different access routers, it is In the context of mobility between different access routers, it is
common to consider performance optimizations in two areas: selection common to consider performance optimizations in two areas: selection
of the optimal access router to handover to, and transfer of state of the optimal access router to handover to, and transfer of state
information between the access routers to avoid having to regenerate information between the access routers to avoid having to regenerate
it in the new access router after handover. The Seamoby Working Group it in the new access router after handover. The Seamoby Working Group
is developing solutions for these protocols (CARD [27] and Context is developing solutions for these protocols (CARD [22] and Context
Transfer [28] respectively); alternative approaches with similar Transfer [23] respectively); alternative approaches with similar
characteristics are also possible. characteristics are also possible.
As these solutions are still underdevelopment, it is premature to As these solutions are still underdevelopment, it is premature to
specify details on the interaction. It is thought that Context specify details on the interaction. It is thought that Context
Transfer transfers state between access routers based upon changes Transfer transfers state between access routers based upon changes
caused by mobility. NSIS protocol state may be a candidate for caused by mobility. NSIS protocol state may be a candidate for
context transfer. Such work, should it be undertaken, will be done context transfer. Such work, should it be undertaken, will be done
in the Seamoby working group. in the Seamoby working group.
5.3 Interactions with NATs 5.3 Interactions with NATs
Because at least some messages will almost inevitably contain address Because at least some messages will almost inevitably contain address
and possibly higher layer information as payload, we must consider and possibly higher layer information as payload, we must consider
the interaction with address translation devices (NATs). As well as the interaction with address translation devices (NATs). As well as
'traditional' NATs of various types (as defined in [29]) very similar 'traditional' NATs of various types (as defined in [24]) very similar
considerations would apply to some IPv4/v6 transition mechanisms such considerations would apply to some IPv4/v6 transition mechanisms such
as SIIT [30]. as SIIT [25].
In the simplest case of an NSIS unaware NAT in the signaling path, In the simplest case of an NSIS unaware NAT in the path, payloads
payloads will be uncorrected and the signaling will be for the will be uncorrected and signaling will refer to the flow incorrectly.
incorrect flow. Applications could attempt to use STUN [31] or Applications could attempt to use STUN [26] or similar techniques to
similar techniques to detect and recover from the presence of the detect and recover from the presence of the NAT. Even then, NSIS
NAT. Even then, NSIS protocols would have to use a well known protocols would have to use a well known encapsulation (TCP/UDP/ICMP)
encapsulation (TCP/UDP/ICMP) to avoid being dropped by the more to avoid being dropped by more cautious low-end NAT devices.
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 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 being part of message processing itself, in which case the
translating node can take part natively in any NSIS protocol security translating node can take part natively in any NSIS protocol security
mechanisms. Depending on NSIS protocol layering, it would be possible mechanisms. Depending on NSIS protocol layering, it would be possible
for this processing to be done in an NSIS entity which was otherwise for this processing to be done in an NSIS entity which was otherwise
ignorant of any particular signaling applications. This is the ignorant of any particular signaling applications. This is the
motivation for including basic flow identification information in the motivation for including basic flow identification information in the
NTLP (section 4.5.1). NTLP (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). This is
considered in section 6.2. considered in section 6.2.
6. Signaling Applications 6 Signaling Applications
This section describes NSLPs for particular signaling applications. This section describes NSLPs for particular signaling applications.
The assumption is that the NSLP uses the generic functionality of the The assumption is that the NSLP uses the generic functionality of the
NTLP given earlier; this section describes specific aspects of NSLP NTLP given earlier; this section describes specific aspects of NSLP
operation. operation.
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 of section 3.1 apply. In addition, there is an assumed directionality of
the signaling process, in that one end of the signaling flow takes 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:
*) NSIS Initiator (NI): the signaling entity which makes the resource *) NSIS Initiator (NI): the signaling entity which makes the resource
request, usually as a result of user application request. request, usually as a result of user application request.
*) NSIS Responder (NR): the signaling entity that acts as the *) NSIS Responder (NR): the signaling entity that acts as the
endpoint for the signaling and can optionally interact with endpoint for the signaling and can optionally interact with
applications as well. applications as well.
*) NSIS Forwarder (NF): the signaling entity an NI and NR which *) NSIS Forwarder (NF): the signaling entity between an NI and NR
propagates NSIS signaling further through the network. which 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) which 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 NSIS Initiator role: with respect to the data flow should take the NSIS Initiator role: with respect to the data flow
direction it could be at the sending or receiving end. direction it could be at the sending or receiving end.
6.1.1 Protocol Messages 6.1.1 Protocol Messages
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 message set for the QoS NSLP reservations along the signaling path. A message set for the QoS NSLP
is shown below (a very similar set of messages was generated in is shown below (a very similar set of messages was generated in
[32]). Note that the 'direction' column in the table below only [27]). Note that the 'direction' column in the table below only
indicates the 'orientation' of the message. The messages can be indicates the 'orientation' of the message. The messages can be
originated and absorbed at NF nodes as well as the NI or NR; an originated and absorbed at NF nodes as well as the NI or NR; an
example might be NFs at the edge of a domain exchanging messages to example might be NFs at the edge of a domain exchanging messages to
set up resources for a flow across a it. set up resources for a flow across a it.
Note the working assumption that responder as well as the initiator Note the working assumption that responder as well as the initiator
can release a reservation (comparable to rejecting it in the first can release a reservation (comparable to rejecting it in the first
place). It is left open if the responder can modify a reservation, place). It is left open if the responder can modify a reservation,
during or after setup. This seems mainly a matter of assumptions during or after setup. This seems mainly a matter of assumptions
about authorization, and the possibilities might depend on resource about authorization, and the possibilities might depend on resource
skipping to change at page 35, line 46 skipping to change at page 35, line 44
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:
*) The protocol must be scalable. It should allow minimization of the *) The protocol must be scalable. It should allow minimization of the
resource reservation state storage demands that it implies for resource reservation state storage demands that it implies for
intermediate nodes; in particular, storage of state per 'micro' flow intermediate nodes; in particular, storage of state per 'micro' flow
is likely to be impossible except at the very edge of the network. A is likely to be impossible except at the very edge of the network. A
QoS signaling application might require per flow or lower granularity QoS signaling application might require per flow or lower granularity
state; examples of each for the case of QoS would be IntServ [33] or state; examples of each for the case of QoS would be IntServ [28] or
RMD [34] (per 'class' state) respectively. RMD [29] (per 'class' state) respectively.
*) The protocol must be robust against failure and other conditions, *) The protocol must be robust against failure and other conditions,
which imply that the stored resource reservation state has to be which imply that the stored resource reservation state has to be
moved or removed. moved or removed.
For resource reservations, typically soft state management is For resource reservations, soft state management is typically used as
considered for robustness reasons. It is currently open whether the a general robustness mechanism. According to the discussion of
soft state protocol aspects should be built into the NSLP for section 3.2.4, the soft state protocol mechanisms are built into the
specific signaling applications, or provided as a generic service by NSLP for the specific signaling application that needs them; the NTLP
the NTLP; this issue is discussed in section 3.4.2. sees this simply as a sequence of (presumably identical) messages.
6.1.3 QoS Forwarding 6.1.3 QoS Forwarding
The assumption is that the NTLP works with standard (i.e. best- The assumption is that the NTLP works with standard (i.e. best-
effort) layer 3 routing. There are, however, several proposals for effort) layer 3 routing. There are, however, several proposals for
the introduction of QoS awareness in the routing protocols. All of the introduction of QoS awareness in the routing protocols. All of
these essentially lead to the existence of multiple paths (with these essentially lead to the existence of multiple paths (with
different QoS) towards the same destination. As such, they also different QoS) towards the same destination. As such, they also
contain an inherent risk for a divergence between control plane and contain an inherent risk for a divergence between control plane and
data plane, similar to the load sharing case. Clearly, any QoS NSLP data plane, similar to the load sharing case. Clearly, any QoS NSLP
skipping to change at page 37, line 38 skipping to change at page 37, line 29
|| +----+ || +----+
============================ ============================
data path data path
Figure 8: Route Change Figure 8: Route Change
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. To minimize this time interval reserved on (part of) the data path. To minimize this time interval
several techniques could be considered. As an example, RSVP [4] has several techniques could be considered. As an example, RSVP [2] has
the concept of local repair, where the router may be triggered by a the concept of local repair, where the router may be triggered by a
route change. In that case the RSVP node can start sending PATH route change. In that case the RSVP node can start sending PATH
messages directly after the route has been changed. Note that this messages directly after the route has been changed. Note that this
option may not be available if no per-flow state is kept in the NF. option may not be available if no per-flow state is kept in the NF.
It is not guaranteed that the new path will be able to provide the It is not guaranteed that the new path will be able to provide the
same guarantees that were available on the old path. Therefore, in a same guarantees that were available on the old path. Therefore, in a
more desirable scenario, the NF should wait until resources have been more desirable scenario, the NF should wait until resources have been
reserved on the new path before installing the route change (unless reserved on the new path before installing the route change (unless
of course the old path no longer exists). The route change procedure of course the old path no longer exists). The route change procedure
then consists of the following steps: then consists of the following steps:
1. NF receives a route announcement, 1. NF receives a route announcement,
2. Refresh messages are forwarded along the current path, 2. Refresh messages are forwarded along the current path,
3. A copy of the refresh message is re-marked as a request and send 3. A copy of the refresh message is re-marked as a request and sent
along the new path that was announced, along the new path that was announced,
4. When the NF has been acknowledged about the reservations on the 4. When the NF has been acknowledged about the reservations on the
new path the route will be installed and the data will flow along the new path, the route will be installed and data will flow along it.
new path.
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 [34]. This solution adapts to a route congestion and is explained in [29]. This solution adapts to a route
change, when a route change creates a congestion on the new routed change, when a route change creates a congestion on the new routed
path. path.
6.1.5 Resource Management Interactions 6.1.5 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 signaling notion of admission control. For a QoS NSLP, the measure of signaling
success will be the ability to reserve resources from the total success will be the ability to reserve resources from the total
skipping to change at page 38, line 39 skipping to change at page 38, line 29
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). It is noted, however, that the RMF
may in turn use another NSLP instance to do the actual resource may in turn use another NSLP instance to do the actual resource
provisioning in the network. In this case, the RMF acts as the provisioning in the network. In this case, the RMF acts as the
initiator (client) of an NSLP. initiator (client) 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
specialised intradomain QoS signaling, running between just the edges specialised intradomain QoS signaling, running between just the edges
of the network (see [35], [36], and [37] for a discussion of similar of the network (see [30], [31], and [32] for a discussion of similar
architectures). Given that NSIS signaling is already supposed to be architectures). Given that NSIS signaling is already supposed to be
able to support multiple instances of NSLPs for a given flow, and able to support multiple instances of NSLPs for a given flow, and
limited scope (e.g. edge-to-edge) operation, it is not currently limited scope (e.g. edge-to-edge) operation, it is not currently
clear that supporting the multi-level model leads to any new protocol clear that supporting the multi-level model leads to any new protocol
requirements for the QoS NSLP. requirements for the QoS NSLP.
The RMF may or may not be co-located with an NF (note that co- The RMF may or may not be co-located with an NF (note that co-
location with an NI/NR can be handled logically as a combination location with an NI/NR can be handled logically as a combination
between NF and NI/NR). To cater for both cases, we define a (possibly between NF and NI/NR). To cater for both cases, we define a (possibly
logical) NF-RMF interface. Over this interface, information may be logical) NF-RMF interface. Over this interface, information may be
skipping to change at page 39, line 27 skipping to change at page 39, line 16
rapid response to data path changes. 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 use develop NSLPs for other signaling applications which possible to use develop NSLPs for other signaling applications which
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
[6], and initial discussions of NSIS-like solutions are contained in [6], and initial discussions of NSIS-like solutions are contained in
[38], [39] and [40]. Other examples include network monitoring and [33] and [34]. Other examples include network monitoring and testing,
testing, and tunnel endpoint discovery. and tunnel endpoint discovery.
A future version of this document may contain more details on how to A future version of this document may contain more details on how to
build NSLPs for these types of signaling application. build NSLPs for these types of signaling application.
7. Security Considerations 7 Security Considerations
This document describes a framework for signaling protocols which This document describes a framework for signaling protocols which
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.6. We have assumed Security for the NTLP is discussed in section 4.7. We have assumed
that the role of the NTLP will be to provide message protection over that the role of the NTLP will be to provide message protection over
the scope of a single peer relationship (between adjacent signaling the scope of a single peer relationship (between adjacent signaling
entities), and that this can most likely be provided by some kind of entities), and that this can most likely be provided by some kind of
channel security mechanism using an external key management mechanism channel security mechanism using an external key management mechanism
based on mutual authentication. In addition, the NTLP should be based on mutual authentication. In addition, the NTLP should be
resilient against denial of service attacks on the protocol itself. resilient against denial of service attacks on the protocol itself.
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 required requirements. In some cases, no additional protection may be required
compared to what is provided by the NTLP. In other cases, more compared to what is provided by the NTLP. In other cases, more
sophisticated object-level protection and the use of public key based sophisticated object-level protection and the use of public key based
solutions may be required. In addition, the NSLP needs to consider solutions may be required. In addition, the NSLP needs to consider
the authorisation requirements of the signaling application. the authorisation requirements of the signaling application.
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 authorisation
aspects; this complicates the analysis of basing signaling aspects; this complicates the analysis of basing signaling
application security on NTLP protection. Further work on this and application security on NTLP protection. Further work on this and
other security design will depend on a refinement of the NSIS threats other security design will depend on a refinement of the NSIS threats
work begun in [12]. work begun in [4].
8. Change History 8 Change History
8.1 Changes from draft-ietf-nsis-fw-01.txt 8.1 Changes from draft-ietf-nsis-fw-02.txt
1. Re-instated 'long' definition of path-coupled from -01 version
(section 3.1.2).
2. Moved NTLP open issues (transport and state management
functionality) to section 3.2.4 and 4.3, and closed several of
them: NTLP does bundling and fragmentation, but is ignorant of
NSLP state and vice versa. However, added a new open issue on
message summarization.
3. Updated section 5.2 and elsewhere to refer to the WG draft on
mobility/RSVP analysis and an external review paper. Updated
section 6.2 with references to more recent work on path-coupled
signaling to middleboxes. General tidying of other references.
8.2 Changes from draft-ietf-nsis-fw-01.txt
This -02 version has been very significantly restructured compared to This -02 version has been very significantly restructured compared to
the previous version, and a section by section change history is the previous version, and a section by section change history is
probably neither possible or useful. Instead, this section lists the probably neither possible or useful. Instead, this section lists the
major technical and structural changes. major technical and structural changes.
1. The concept of splitting the protocol suite into two layers is 1. The concept of splitting the protocol suite into two layers is
now introduced much earlier, and the rest of the framework now introduced much earlier, and the rest of the framework
restructured around it. In general, the content is supposed to be restructured around it. In general, the content is supposed to be
signaling application independent: possibilities for application signaling application independent: possibilities for application
skipping to change at page 40, line 41 skipping to change at page 40, line 45
case of QoS/resource management is restricted to section 6.1. case of QoS/resource management is restricted to section 6.1.
2. Sender and receiver orientation is now assumed to be a signaling 2. Sender and receiver orientation is now assumed to be a signaling
application protocol property (section 3.3.1), with the NTLP by application protocol property (section 3.3.1), with the NTLP by
default operating bidirectionally (section 3.2.3). As a default operating bidirectionally (section 3.2.3). As a
consequence, the initiator, forwarder, and responder concepts consequence, the initiator, forwarder, and responder concepts
only appear in the later sections. only appear in the later sections.
3. In general, the NTLP is now a 'thinner' layer than previously 3. In general, the NTLP is now a 'thinner' layer than previously
envisaged (e.g. without specific reserve/tear messages), and so envisaged (e.g. without specific reserve/tear messages), and so
the possible inter-layer coupling with the NSLP is much reduced. the possible inter-layer coupling with the NSLP is much reduced.
However, the option of the NTLP providing some kind of generic However, the option of the NTLP providing some kind of generic
state management service is still an open issue (section 3.4.2). state management service is still an open issue.
4. In general, authorisation issues are still handled by the NSLP, 4. In general, authorisation issues are still handled by the NSLP,
including the question of which network entities are allowed to including the question of which network entities are allowed to
modify network state. In particular, the issue of 'session' modify network state. In particular, the issue of 'session'
(previously 'reservation') ownership (section 3.1.4) is assumed (previously 'reservation') ownership (section 3.1.5) is assumed
to be handled by the NSLP level, although session identification to be handled by the NSLP level, although session identification
is still visible to the NTLP (section 4.5.2). The implication is is still visible to the NTLP (section 4.6.2). The implication is
that most key aspects of mobility support (section 5.2) are now that most key aspects of mobility support (section 5.2) are now
NSLP responsibilities. NSLP responsibilities.
5. Both peer-peer and end-to-end addressing modes are assumed to be 5. Both peer-peer and end-to-end addressing modes are assumed to be
needed for the NTLP, and any choice between them is a protocol needed for the NTLP, and any choice between them is a protocol
design issue (not visible externally). design issue (not visible externally).
References References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP [Editor's note: in a future version, these will be split as Normative
9, RFC 2026, October 1996. and Informative.]
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
3 Brunner, M., "Requirements for QoS Signaling Protocols", draft- 2 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ietf-nsis-req-05.txt (work in progress), November 2002
4 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997 Specification", RFC 2205, September 1997
3 Brunner, M., "Requirements for Signaling Protocols", draft-ietf-
nsis-req-08.txt (work in progress), June 2003
4 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-01.txt (work in progress), January 2003
5 Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile 5 Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile
IP", draft-ietf-mobileip-qos-requirements-03.txt (work in IP", draft-ietf-nsis-qos-requirements-01.txt (work in progress),
progress), July 2002 June 2003
6 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 6 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
Communications (midcom) Protocol Requirements", RFC 3304, August Communications (midcom) Protocol Requirements", RFC 3304, August
2002 2002
7 Manner, J. and X. Fu, "Analysis of Existing Quality of Service 7 Manner, J. and X. Fu, "Analysis of Existing Quality of Service
Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txt Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txt
(work in progress), February 2003 (work in progress), February 2003
8 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 8 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp-
thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002 sec-properties-01.txt (work in progress), March, 2003
9 Braden, R., and B. Lindell, "A Two-Level Architecture for Internet
Signaling", draft-braden-2level-signaling-01.txt (work in
progress), November 2002
10 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security 9 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security
Considerations", draft-iab-sec-cons-03.txt (work in progress), Considerations", draft-iab-sec-cons-03.txt (work in progress),
January 2003 January 2003
11 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, 10 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne,
"NSIS Authentication, Authorization and Accounting Issues", draft- "NSIS Authentication, Authorization and Accounting Issues", draft-
tschofenig-nsis-aaa-issues-00.txt (work in progress), February tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003
2003 11 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
12 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001
draft-ietf-nsis-threats-01.txt (work in progress), January 2003
12 Hancock, R., E. Hepworth, A. McDonald, "Handling Overload
Conditions in the NSIS Protocol Suite", draft-hancock-nsis-
overload-00.txt (work in progress), June 2003
13 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 13 Katz, D., "IP Router Alert Option", RFC 2113, February 1997
14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,
October 1999 October 1999
15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda,
T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC
2676, August 1999 2676, August 1999
16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995 1771, March 1995
17 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 17 Rekhter, Y. T. Li, S.Hares, "A Border Gateway Protocol 4 (BGP-4)",
draft-ietf-idr-bgp4-17.txt (work in progress), January 2002 draft-ietf-idr-bgp4-20.txt (work in progress), April 2003
(expired)
18 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of
Multiple Paths in BGP", draft-walton-bgp-add-paths-01.txt (work in
progress), November 2002
19 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, 18 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,
P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy
Protocol", RFC2338, April 1998 Protocol", RFC2338, April 1998
20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 19 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ
thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002 Resource Management in IP-based Radio Access Networks",
Proceedings of 4th International Symposium on Wireless Personal
21 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource Multimedia Communications-WPMC'01, September 9 - 12, 2001
Reservation Issues in Cellular Radio Access Networks", draft-
westberg-rmd-cellular-issues-01.txt (work in progress), June 2002
22 Shen, C. et al., "An Interoperation Framework for Using RSVP in 20 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y.
Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt Khouaja, "Evaluation of Mobility and QoS Interaction", Computer
(work in progress), July 2001 (expired) Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163
23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt 21 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt
(work in progress), January 2003 (work in progress), January 2003
24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 22 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in
IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March
2001 (expired)
25 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile
IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress),
January 2002 (expired)
26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6
Networks", draft-kan-qos-framework-01.txt (work in progress), July
2002
27 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in
candidate access router discovery for seamless IP-level handoffs", candidate access router discovery for seamless IP-level handoffs",
draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress),
October 2002 October 2002
28 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", RFC3374, Transfers Between Nodes in an IP Access Network", RFC3374,
September 2002 September 2002
24 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
29 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999 (NAT) Terminology and Considerations", RFC2663, August 1999
30 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 25 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC2765, February 2000 RFC2765, February 2000
31 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 26 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
Traversal of UDP Through Network Address Translators", draft-ietf- Traversal of User Datagram Protocol (UDP) Through Network Address
midcom-stun-05.txt (work in progress), December 2002 Translators (NATs)", RFC3489, March 2003
32 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework 27 Westberg, L., et al., "Resource Management in Diffserv (RMD)
for Edge-to-Edge NSIS Signaling", draft-westberg-nsis-edge-edge- Framework", draft-westberg-rmd-framework-03.txt (work in
framework-00.txt (work in progress), May 2002 progress), June 2003
33 Braden, R., D. Clark, S. Shenker, "Integrated Services in the 28 Braden, R., D. Clark, S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994 Internet Architecture: an Overview", RFC 1633, June 1994
34 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 29 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Partain, D., Pop, O., Rexhepi, V., Szabó, R., Takács, A., Partain, D., Pop, O., Rexhepi, V., Szabó, R., Takács, A.,
"Resource Management in Diffserv (RMD): A Functionality and "Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop on Performance Behavior Overview", Seventh International Workshop on
Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002
35 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for 30 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
072, November 1992 072, November 1992
36 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated 31 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet", RFC 2638, July 1999 Services Architecture for the Internet", RFC 2638, July 1999
37 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
38 Shore, M., "Towards a Network-friendlier Midcom", draft-shore- 32 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
friendly-midcom-01.txt (work in progress), June 2002 RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
39 Shore, M., "The TIST (Topology-Insensitive Service Traversal) 33 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.
Protocol", draft-shore-tist-prot-00.txt (work in progress), May Schulzrinne, "SIS NAT/FW NSLP: Problem Statement and Framework",
2002 draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003
40 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS 34 Aoun, C., "NSIS Network Address Translator implications", draft-
Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in aoun-nsis-nat-imps-01.txt (work in progress), March 2003
progress), June 2002
Acknowledgments Acknowledgments
The authors would like to thank Anders Bergsten, Bob Braden, Maarten The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
Buchli, Eleanor Hepworth, Melinda Shore and Hannes Tschofenig for Hepworth, Melinda Shore and Hannes Tschofenig for significant
significant contributions in particular areas of this draft. In contributions in particular areas of this draft. In addition, the
addition, the authors would like to acknowledge Cedric Aoun, Marcus authors would like to acknowledge Cedric Aoun, Attila Bader, Anders
Brunner, Danny Goderis, Cornelia Kappler, Mac McTiffin, Hans De Neve, Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu,
David Partain, Vlora Rexhepi, Henning Schulzrinne and Lars Westberg Ruediger Geib, Danny Goderis, Cornelia Kappler, Thanh Tra Luu, Mac
for insights and inputs during this and previous framework McTiffin, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi,
activities. 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.
Authors' Addresses Authors' Addresses
Ilya Freytsis Ilya Freytsis
Cetacean Networks Inc. Cetacean Networks Inc.
100 Arboretum Drive 100 Arboretum Drive
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
email: ifreytsis@cetacean.com email: ifreytsis@cetacean.com
skipping to change at page 45, line 4 skipping to change at page 44, line 30
email: ifreytsis@cetacean.com email: ifreytsis@cetacean.com
Robert Hancock Robert Hancock
Roke Manor Research Roke Manor Research
Old Salisbury Lane Old Salisbury Lane
Romsey Romsey
Hampshire Hampshire
SO51 0ZN SO51 0ZN
United Kingdom United Kingdom
email: robert.hancock@roke.co.uk email: robert.hancock@roke.co.uk
Georgios Karagiannis Georgios Karagiannis
Ericsson EuroLab Netherlands B.V. University of Twente
Institutenweg 25 P.O. BOX 217
P.O.Box 645 7500 AE Enschede
7500 AP Enschede
The Netherlands The Netherlands
email: georgios.karagiannis@eln.ericsson.se email: g.karagiannis@ewi.utwente.nl
John Loughney John Loughney
Nokia Research Center Nokia Research Center
11-13 Italahdenkatu 11-13 Italahdenkatu
00180 Helsinki 00180 Helsinki
Finland Finland
email: john.loughney@nokia.com email: john.loughney@nokia.com
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
skipping to change at page 46, line 30 skipping to change at line 2142
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
Hancock et al. Expires - Septemb
 End of changes. 

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