draft-ietf-nsis-fw-03.txt   draft-ietf-nsis-fw-04.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
University of Twente University of Twente/Ericsson
John Loughney John Loughney
Nokia Nokia
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Document: draft-ietf-nsis-fw-03.txt Document: draft-ietf-nsis-fw-04.txt
Expires: December 2003 June 2003 Expires: March 2004 September 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. 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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, signaling and other network layer functions, specifically routing,
mobility, and address translators. The different 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
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 Path-Coupled and Path-Decoupled Signaling ..............7 3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7
3.1.3 Signaling to Hosts, Networks and Proxies ...............8 3.1.3 Signaling to Hosts, Networks and Proxies ...............8
3.1.4 Signaling Messages and Network Control State ..........10 3.1.4 Signaling Messages and Network Control State ..........10
3.1.5 Data Flows and Sessions ...............................10 3.1.5 Data Flows and Sessions ...............................10
3.2 Layer Model for the Protocol Suite ......................11 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 ...................................13 3.2.2 Layer Split Concept ...................................12
3.2.3 Core NTLP Functionality ...............................14 3.2.3 Bypassing Intermediate Nodes ..........................13
3.2.4 State Management Functionality ........................14 3.2.4 Core NTLP Functionality ...............................15
3.2.5 Path De-Coupled Operation .............................15 3.2.5 State Management Functionality ........................15
3.3 Signaling Application Properties ........................16 3.2.6 Path De-Coupled Operation .............................16
3.3.1 Sender/Receiver Orientation ...........................16 3.3 Signaling Application Properties ........................17
3.3.2 Uni- and Bi-Directional Operation .....................17 3.3.1 Sender/Receiver Orientation ...........................17
3.3.3 Heterogeneous Operation ...............................18 3.3.2 Uni- and Bi-Directional Operation .....................18
3.3.4 Peer-Peer and End-End Relationships ...................18 3.3.3 Heterogeneous Operation ...............................19
3.3.5 Acknowledgements and Notifications ....................19 3.3.4 Aggregation ...........................................19
3.3.6 Security and Other AAA Issues .........................19 3.3.5 Peer-Peer and End-End Relationships ...................20
4 The NSIS Transport Layer Protocol .............................20 3.3.6 Acknowledgements and Notifications ....................20
4.1 Internal Protocol Components ............................20 3.3.7 Security and Other AAA Issues .........................21
4.2 Addressing ..............................................21 4 The NSIS Transport Layer Protocol .............................21
4.3 Classical Transport Functions ...........................22 4.1 Internal Protocol Components ............................22
4.4 Lower Layer Interfaces ..................................23 4.2 Addressing ..............................................22
4.5 Upper Layer Services ....................................24 4.3 Classical Transport Functions ...........................23
4.6 Identity Elements .......................................24 4.4 Lower Layer Interfaces ..................................25
4.6.1 Flow Identification ...................................24 4.5 Upper Layer Services ....................................25
4.6.2 Session Identification ................................25 4.6 Identity Elements .......................................26
4.6.3 Signaling Application Identification ..................25 4.6.1 Flow Identification ...................................26
4.7 Security Properties .....................................26 4.6.2 Session Identification ................................27
5 Interactions with Other Protocols .............................26 4.6.3 Signaling Application Identification ..................27
5.1 IP Routing Interactions .................................26 4.7 Security Properties .....................................28
5.1.1 Load Sharing and Policy-Based Forwarding ..............27 5 Interactions with Other Protocols .............................28
5.1.2 Route Changes .........................................28 5.1 IP Routing Interactions .................................28
5.1.3 Router Redundancy .....................................29 5.1.1 Load Sharing and Policy-Based Forwarding ..............29
5.2 Mobility Interactions ...................................29 5.1.2 Route Changes .........................................29
5.2.1 Addressing and Encapsulation ..........................30 5.2 Mobility and Multihoming Interactions ...................31
5.2.2 Localized Path Repair .................................31
5.2.3 Update on the Unchanged Path ..........................31
5.2.4 Interaction with Mobility Signaling ...................31
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 5.4 Interactions with IP Tunneling ..........................34
6.1 Signaling for Quality of Service ........................34 6 Signaling Applications ........................................35
6.1.1 Protocol Messages .....................................34 6.1 Signaling for Quality of Service ........................35
6.1.2 State Management ......................................35 6.1.1 Protocol Message Semantics ............................36
6.1.3 QoS Forwarding ........................................36 6.1.2 State Management ......................................36
6.1.4 Route Changes and QoS Reservations ....................36 6.1.3 Route Changes and QoS Reservations ....................37
6.1.5 Resource Management Interactions ......................38 6.1.4 Resource Management Interactions ......................38
6.2 Other Signaling Applications ............................39 6.2 Other Signaling Applications ............................40
7 Security Considerations .......................................39 7 Security Considerations .......................................40
8 Change History ................................................40 8 Change History ................................................41
8.1 Changes from draft-ietf-nsis-fw-02.txt ..................40 8.1 Changes from draft-ietf-nsis-fw-03.txt ..................41
8.2 Changes from draft-ietf-nsis-fw-01.txt ..................40 8.2 Changes from draft-ietf-nsis-fw-02.txt ..................42
References.......................................................41 8.3 Changes from draft-ietf-nsis-fw-01.txt ..................42
Acknowledgments..................................................43 References.......................................................43
Authors' Addresses...............................................44 Acknowledgments..................................................45
Intellectual Property Considerations.............................45 Authors' Addresses...............................................46
Full Copyright Statement.........................................45 Intellectual Property Considerations.............................46
Full Copyright Statement.........................................47
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 (i.e. the 'path-coupled' case, see through these nodes themselves (i.e. the 'path-coupled' case, see
section 3.1.2) and that only unicast data flows are considered. section 3.1.2) and that only unicast data flows are considered.
The signaling problem in this sense is very similar to that addressed The signaling problem in this sense is very similar to that addressed
by RSVP [2]. However, there are two generalizations. Firstly, the by RSVP [1]. However, there are two generalizations. Firstly, the
intention is that components of the NSIS protocols suite will be intention is that components of the NSIS protocol suite will be
usable in different parts of the Internet, for different needs, usable in different parts of the Internet, for different needs,
without requiring a complete end-to-end deployment (in particular, without requiring a complete end-to-end deployment (in particular,
the signaling protocol messages may not need to run all the way the signaling protocol messages may not need to run all the way
between the data flow endpoints). between the data flow endpoints).
Secondly, the signaling is intended for more purposes than just QoS 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 work 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 upper layers suitable for QoS
signaling similar to the corresponding functionality in RSVP. Further signaling (similar to the corresponding functionality in RSVP) and
signaling applications, such as middlebox signaling, may be middlebox signaling. Further applications may be considered later.
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] and a separate security threats document [4]; other defined in [2] and a separate security threats document [3]; other
related requirements can be found in [5] and [6]. This framework does related requirements can be found in [4] and [5]. This framework does
not replace or update these requirements. Discussions about lessons not replace or update these requirements. Discussions about lessons
to be learned from existing signaling and resource protocols are to be learned from existing signaling and resource management
contained in separate analysis documents [7], [8]. protocols are contained in separate analysis documents [6], [7].
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 to describe the
protocols should be structured at the overall level. Therefore, it overall structure of the protocol suite itself. Therefore, it
discusses important protocol considerations, such as routing, discusses important protocol considerations, such as routing,
mobility, security, and interactions with network 'resource' mobility, security, and interactions with network 'resource'
management (in the broadest sense). management (in the broadest sense).
The basic context for NSIS protocols is given in section 3. Section The basic context for NSIS protocols is given in section 3. Section
3.1 describes the fundamental elements of NSIS protocol operation in 3.1 describes the fundamental elements of NSIS protocol operation in
comparison to RSVP; in particular, section 3.1.3 describes more comparison to RSVP; in particular, section 3.1.3 describes more
general signaling scenarios, and 3.1.4 defines a broader class of general signaling scenarios, and 3.1.4 defines a broader class of
signaling applications for which the NSIS protocols should be useful. signaling applications for which the NSIS protocols should be useful.
The two-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 detailed design of the protocol or even design options, although some
described as examples. It describes the interfaces between this lower are described as examples. It describes the interfaces between this
layer protocol and the IP layer (below) and signaling application lower layer protocol and the IP layer (below) and signaling
protocols (above), including the identity elements that appear on application protocols (above), including the identifier elements that
these interfaces. Following this, section 5 describes how signaling appear on these interfaces (section 4.6). Following this, section 5
applications that use the NSIS protocols can interact sensibly with describes how signaling applications that use the NSIS protocols can
network layer operations, specifically routing (and re-routing), IP interact sensibly with network layer operations, specifically routing
mobility, and network address translation. (and re-routing), IP 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 given in detail in section 6.1, which describes functionality) is given in detail in section 6.1, which describes
both the signaling application specific protocol and example modes of both the signaling application specific protocol and example modes of
interaction with network resource management and other deployment interaction with network resource management and other deployment
aspects. However, note that these examples are included only as aspects. However, note that these examples are included only as
background and for explanation; it is not intended to define an 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.]
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.6.1). by some flow identifier (see section 4.6.1).
Edge node - a (NSIS-capable) node on the boundary of some Edge node - an (NSIS-capable) node on the boundary of some
administrative domain. administrative domain.
Interior nodes - the set of (NSIS-capable) nodes which form an Interior nodes - the set of (NSIS-capable) nodes 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.
NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS
protocol component that supports a specific signaling application. protocol component that supports a specific signaling application.
See also section 3.2.1. See also section 3.2.1.
NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS
protocol component that will support lower layer (signaling protocol component that will support lower layer (signaling
application independent) functions. See also section 3.2.1. application independent) functions. See also section 3.2.1.
Path-coupled signaling - a mode of signaling where the signaling Path-coupled signaling - a mode of signaling where the signaling
messages follow a path that is tied to the data messages. messages follow a path that is tied to the data messages.
Path-decoupled signaling - signaling - signaling for state Path-decoupled signaling - signaling for state manipulation related
manipulation related to data flows, but only loosely coupled to the to data flows, but only loosely coupled to the data path, e.g. at the
data path, e.g. at the AS level. AS level.
Peer discovery - the act of locating and/or selecting which NSIS peer Peer discovery - the act of locating and/or selecting which NSIS peer
to carry out signaling exchanges with for a specific data flow. to carry out signaling exchanges with for a specific data flow.
Peer relationship - signaling relationship between two adjacent NSIS Peer relationship - signaling relationship between two adjacent NSIS
entities (i.e. NEs with no other NEs between them). entities (i.e. NEs with no other NEs between them).
Receiver - the node in the network which is receiving the data Receiver - the node in the network which is receiving the data
packets in a flow. packets in a flow.
skipping to change at page 7, line 34 skipping to change at page 7, line 24
configuration. A single data flow is running from an application in configuration. A single data flow is running from an application in
the sender to the receiver via routers R1, R2 and R3. Each host and the sender to the receiver via routers R1, R2 and R3. Each host and
two of the routers contain NEs which exchange signaling messages - two of the routers contain NEs which exchange signaling messages -
possibly in both directions - about the flow. This scenario is possibly in both directions - about the flow. This scenario is
essentially the same as that considered by RSVP for QoS signaling; essentially the same as that considered by RSVP for QoS signaling;
the main difference is that we make no assumptions here about the the main difference is that we make no assumptions here about the
particular sequence of signaling messages that will be invoked. particular sequence of signaling messages that will be invoked.
Sender Receiver Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+ +-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 | ---->|Application| |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ | | +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| | | |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ | | +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+ +-----------+ +----+ +----+ +-----------+
+--+ +--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages |NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional) +--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows Figure 1: Simple Signaling and Data Flows
skipping to change at page 8, line 12 skipping to change at page 7, line 48
We can consider two basic paradigms for resource reservation We can consider two basic paradigms for resource reservation
signaling, which we refer to as "path-coupled" and "path-decoupled". signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through In the path-coupled case, signaling messages are routed only through
nodes (NEs) that are in the data path. They do not have to reach all 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 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, distinct from the sender and receiver as described in section 3.1.3,
or intermediate signaling-unaware nodes); and between adjacent NEs, or intermediate signaling-unaware nodes); and between adjacent NEs,
the route taken by signaling and data might diverge. The path-coupled the route taken by signaling and data might diverge. The path-coupled
case can be supported by various addressing styles, with messages case can be supported by various addressing styles, with messages
either explicitly addressed to the neighbor on-path NE, or routed either explicitly addressed to the neighbor on-path NE, or addressed
identically to the data packets and intercepted. These cases are identically to the data packets but also with the router alert option
considered in section 4.2. In the second case, some network (see [8] and [9]) and intercepted. These cases are considered in
configurations may split the signaling and data paths (see section section 4.2. In the second case, some network configurations may
5.1.1); this is considered an error case for path-coupled signaling. 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 In the path-decoupled case, signaling messages are routed to nodes
(NEs) which are not assumed to be on the data path, but which are (NEs) which are not assumed to be on the data path, but which are
(presumably) aware of it. Signaling messages will always be directly (presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the signaling endpoints may have no addressed to the neighbor NE, and the signaling endpoints may have no
relation at all with the ultimate data sender or receiver. The relation at all with the ultimate data sender or receiver. The
implications of path-decoupled operation for the NSIS protocols are implications of path-decoupled operation for the NSIS protocols are
considered briefly in section 3.2.5; however, the initial goal of considered briefly in section 3.2.6; however, the initial goal of
NSIS and this framework is to concentrate mainly on the path-coupled NSIS and this framework is to concentrate mainly on the path-coupled
case. case.
3.1.3 Signaling to Hosts, Networks and Proxies 3.1.3 Signaling to Hosts, Networks and Proxies
There are different possible triggers for the signaling protocols. There are different possible triggers for the signaling protocols.
Amongst them are user applications (that are using NSIS signaling Amongst them are user applications (that are using NSIS signaling
services), other instances of the signaling, network management services), other signaling applications, network management actions,
actions, some network events, and so on. The variety of possible some network events, and so on. The variety of possible triggers
triggers requires that the signaling can be initiated and terminated requires that the signaling can be initiated and terminated in the
in the different parts of the network - hosts, domain boundary nodes different parts of the network - hosts, domain boundary nodes (edge
(edge nodes) or interior domain nodes. nodes) or interior domain nodes.
The NSIS protocol suite extends the RSVP model to consider this wider The NSIS protocol suite extends the RSVP model to consider this wider
variety of possible signaling exchanges. As well as the basic end-to- variety of possible signaling exchanges. As well as the basic end-to-
end model already described, examples such as end-to-edge and edge- end model already described, examples such as end-to-edge and edge-
to-edge can be considered. The edge-to-edge case might involve the to-edge can be considered. The edge-to-edge case might involve the
edge nodes communicating directly, as well as via the interior nodes. edge nodes communicating directly, as well as via the interior nodes.
While the 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 trust relations between domains.
In some cases it is desired to be able to initiate and/or terminate In some cases it is desired to be able to initiate and/or terminate
NSIS signaling not from the end host that sends/receives the data NSIS signaling not from the end host that sends/receives the data
flow, but from the some other entities in the network that can be flow, but from 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 "proxy 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 2 specific challenges for the signaling: This configuration presents 2 specific challenges for the signaling:
*) The proxy that terminates signaling on behalf of the NSIS-unaware *) A proxy that terminates signaling on behalf of the NSIS-unaware
host (or part of the network) should be able to make determination host (or part of the network) should be able to 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
send and receive signaling information to a remote processor. The
NSIS protocols may or may not be suitable for this remote
interaction, but in any case it is not currently part of the NSIS
problem. This configuration is supported by considering the NE as a
proxy at the signaling application level. This is a natural
implementation approach for some policy control and centralized
control architectures, see also section 6.1.5.
+------+ +----+ +----+ +----+ +-----------+ +------+ +----+ +----+ +----+ +-----------+
|Sender|----->| PA |----->| R2 |----->| R3 | ---->| Receiver | |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
Another possible configuration, shown in Figure 3, is where an NE can
send and receive signaling information to a remote processor. The
NSIS protocols may or may not be suitable for this remote
interaction, but in any case it is not currently part of the NSIS
problem. This configuration is supported by considering the NE as a
proxy at the signaling application level. This is a natural
implementation approach for some policy control and centralized
control architectures, see also section 6.1.4.
3.1.4 Signaling Messages and Network Control State 3.1.4 Signaling Messages and Network Control State
The distinguishing features of the signaling supported by the NSIS The distinguishing features of the signaling supported by the NSIS
protocols are that it is related to specific flows (rather than to protocols are that it is related to specific flows (rather than to
network operation in general), and that it involves nodes in the network operation in general), and that it involves nodes in the
network (rather than running transparently between the end hosts). network (rather than running transparently between the end hosts).
Therefore, each signaling application (upper layer) protocol must Therefore, each signaling application (upper layer) protocol must
carry per-flow information for the aspects of network-internal carry per-flow information for the aspects of network-internal
operation interesting to that signaling application. An example for operation interesting to that signaling application. An example for
skipping to change at page 11, line 23 skipping to change at page 11, line 9
The simplest service provided by NSIS signaling protocols is The simplest service provided by NSIS signaling protocols is
management of network control state at the level of a specific flow, management of network control state at the level of a specific flow,
as described in the previous subsection. In particular, it should be as described in the previous subsection. In particular, it should be
possible to monitor routing updates as they change the path taken by possible to monitor routing updates as they change the path taken by
a flow and, for example, update network state appropriately. This is a flow and, for example, update network state appropriately. This is
no different from the case for RSVP (local path repair). Where there no different from the case for RSVP (local path repair). Where there
is a 1:1 flow:session relationship, this is all that is required. is a 1:1 flow:session relationship, this is all that is required.
However, for some more complex scenarios (especially mobility and However, for some more complex scenarios (especially mobility and
multihoming related ones, see [3] and the mobility discussion of [7]) multihoming related ones, see [2] and the mobility discussion of [6])
it is desirable to update the flow:session mapping during the session it is desirable to update the flow:session mapping during the session
lifetime. For example, a new flow can be added, and the old one lifetime. For example, a new flow can be added, and the old one
deleted (and maybe in that order, for a 'make-before-break' deleted (and maybe in that order, for a 'make-before-break'
handover), effectively transferring the network control state between handover), effectively transferring the network control state between
data flows to keep it associated with the same session. Such updates data flows to keep it associated with the same session. Such updates
are best managed by the end systems (generally, systems which are best managed by the end systems (generally, systems which
understand the flow:session mapping and are aware of the packet understand the flow:session mapping and are aware of the packet
classifier change). To enable this, it must be possible to relate classifier change). To enable this, it must be possible to relate
signaling messages to sessions as well as data flows. A session signaling messages to sessions as well as data flows. A session
identifier (section 4.6.2) is one component of the solution. identifier (section 4.6.2) is one component of the solution.
skipping to change at page 12, line 36 skipping to change at page 12, line 31
. . . .
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.
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
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 underlying the This section describes the basic concepts underlying the
functionality of the NTLP. Firstly, we make a working assumption that functionality of the NTLP. Firstly, we make a working assumption that
the protocol mechanisms of the NTLP operate only between adjacent NEs the protocol mechanisms of the NTLP operate only between adjacent NEs
(informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger
scope issues (including e2e aspects) are left to the upper layers. scope issues (including e2e aspects) are left to the upper layers.
The way in which the NTLP works can be described as follows: When a 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
skipping to change at page 13, line 46 skipping to change at page 13, line 20
NE in the middle or end of the signaling path could send a message NE in the middle or end of the signaling path could send a message
directly to the other end as a notification of or acknowledgement for directly to the other end as a notification of or acknowledgement for
some signaling application event. However, the issues in sending such some signaling application event. However, the issues in sending such
messages (endpoint discovery, security, NAT traversal and so on) are messages (endpoint discovery, security, NAT traversal and so on) are
so different from the direct peer-peer case that there is no benefit so different from the direct peer-peer case that there is no benefit
in extending the NTLP to include such non-local functionality; in extending the NTLP to include such non-local functionality;
instead, an NSLP which requires such messages and wants to avoid instead, an NSLP which requires such messages and wants to avoid
traversing the path of NEs should use some other existing transport traversing the path of NEs should use some other existing transport
protocol - for example, UDP or DCCP would be a good match for many of protocol - for example, UDP or DCCP would be a good match for many of
the scenarios that have been proposed. Acknowledgements and the scenarios that have been proposed. Acknowledgements and
notifications of this type are considered further in section 3.3.5. notifications of this type are considered further in section 3.3.6.
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 Internet. potentially the whole Internet.
3.2.3 Core NTLP Functionality 3.2.3 Bypassing Intermediate Nodes
Because the NSIS problem includes multiple signaling applications, it
is very likely that a particular NSLP will only be implemented on a
subset of the NSIS-aware nodes on a path, as shown in Figure 5. In
addition, a node inside an aggregation region will still wish to
ignore signaling messages which are per-flow, even if they are for a
signaling application which the node is able to process in general.
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs
Where signaling messages traverse such NSIS-aware intermediate nodes,
it is desirable to process them at the lowest level possible (in
particular, on the fastest path). In order to offer a non-trivial
message transfer service (in terms of security, reliability and so
on) to the peer NSLP nodes, it is important that NTLP at intermediate
nodes is as transparent as possible, that is, it carries out minimal
processing. In addition, if intermediate nodes have to do slow-path
processing of all NSIS messages, this eliminates many of the scaling
benefits of aggregation, unless tunneling is used.
Considering first the case of messages sent with the router alert
option, there are two complementary methods to achieve this bypassing
of intermediate NEs:
*) At the IP layer, a set of protocol numbers can be used, or a range
of values in the router alert option. In this way, messages can be
marked with an implied granularity, and routers can choose to apply
further slow-path processing only to configured subsets of messages.
This is the method used in [10] to distinguish per-flow and per-
aggregate signaling.
*) The NTLP could process the message but determine that there was no
local signaling application it was relevant to. At this stage, the
message can be returned unchanged to the IP layer for normal
forwarding; the intermediate NE has effectively chosen to be
transparent to the message in question.
In both cases, the existence of the intermediate NE is totally hidden
from the NSLP nodes. If later stages of the signaling use directly
addressed messages (e.g. for reverse routing), they will not involved
the intermediate NE at all, except perhaps as a normal router.
There may be cases where the intermediate NE would like to do some
restricted protocol processing, for example:
*) Translating addresses in message payloads (compare section 4.6.1);
note this would have to be done to messages passing both directions
through a node.
*) Updating signaling application payloads with local status
information (e.g. path property measurement inside a domain).
If this can be done without fully terminating the NSIS protocols,
this would allow a more lightweight implementation of the
intermediate NE, and a more direct 'end-to-end' NTLP association
between the peer NSLPs where the signaling application is fully
processed. On the other hand, this is only possible with a limited
class of possible NTLP designs, and makes it harder for the NTLP to
offer a security service (since messages have to be partially
protected). The feasibility of this approach will be evaluated during
the NTLP design.
3.2.4 Core 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 overall signaling solution will always be the NTLP. Note that the overall signaling solution will always be the
result of joint NSLP and NTLP operation; for example, we can always result of joint NSLP and NTLP operation; for example, we can always
assume that an NSLP is operating above the NTLP and taking care of assume that an NSLP is operating above the NTLP and taking care of
end-to-end issues (e.g. recovery of messages after restarts). 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 many 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. Further details about NTLP functionality are in the first place. Further details about NTLP functionality are
contained in sections 3.2.4 and 4.3. contained in sections 3.2.5 and 4.3.
3.2.4 State Management Functionality 3.2.5 State Management Functionality
Internet signaling requires the existence and management of state Internet signaling requires the existence and management of state
within the network for several reasons. This section describes how within the network for several reasons. This section describes how
state management functionality is split across the NSIS layers. state management functionality is split across the NSIS layers. (Note
that how the NTLP internal state is managed is a matter for its
0. How the NTLP internal state is managed is a matter for its design design and indeed implementation.)
and indeed implementation.
1. Conceptually, the NTLP provides a uniform message delivery 1. Conceptually, the NTLP provides a uniform message delivery
service. It is unaware of the difference in state semantics between service. It is unaware of the difference in state semantics between
different types of signaling application message (e.g. whether a different types of signaling application message (e.g. whether a
message changes or just refreshes signaling application state, or message changes or just refreshes signaling application state, or
even has nothing to with signaling application state at all). even has nothing to with signaling application state at all).
2. An NTLP instance processes and if necessary forwards all signaling 2. An NTLP instance processes and if necessary forwards all signaling
application messages "immediately". (It might offer different service application messages "immediately". (It might offer different service
classes, but these would be distinguished e.g. by reliability or classes, but these would be distinguished e.g. by reliability or
priority, not state aspects.) This means that the NTLP does not know priority, not state aspects.) This means that the NTLP does not know
explicit timer or message sequence information for the signaling explicit timer or message sequence information for the signaling
application; and that signaling application messages pass immediately application; and that signaling application messages pass immediately
through an NSLP-unaware node (they can't be jittered there, or re- through an NSLP-unaware node (their timing cannot be jittered there,
sent onto alternative paths if re-routing takes place later). nor can messages be stored up to be re-sent on a new paths in case of
a later re-routing event).
3. Within any node, it's an implementation decision whether to 3. Within any node, it is an implementation decision whether to
generate/jitter/filter refreshes either separately within each generate/jitter/filter refreshes either separately within each
signaling application that needs this functionality, or as part of signaling application that needs this functionality, or to integrate
generic/shared code (a "soft-state management toolbox") more closely it with the NTLP implementation as a generic "soft-state management
associated with the NTLP. The choice doesn't affect the NTLP toolbox"; the choice doesn't affect the NTLP specification at all.
specification at all. Implementations might piggy-back NTLP soft- Implementations might piggy-back NTLP soft-state refresh information
state refresh information (if the NTLP works this way) on signaling (if the NTLP works this way) on signaling application messages, or
application messages, or even combine soft-state management between even combine soft-state management between layers. The state machines
layers. The state machines of the NTLP and NSLPs remain logically of the NTLP and NSLPs remain logically independent, but an
independent, but an implementation is free to allow them to interact implementation is free to allow them to interact to reduce the load
to reduce the load on the network to the same level as would be on the network to the same level as would be achieved by a monolithic
achieved by a monolithic model. model.
4. It may be helpful for signaling applications to receive state- 4. It may be helpful for signaling applications to receive state-
management related 'triggers' from the NTLP, that a peer has failed management related 'triggers' from the NTLP, that a peer has failed
or become available ("down/up notifications"). These triggers would or become available ("down/up notifications"). These triggers would
be about adjacent NTLP peers, rather than signaling application be about adjacent NTLP peers, rather than signaling application
peers. We can consider this as another case of route change peers. We can consider this as another case of route change
detection/notification (which the NTLP is also allowed to do anyway). detection/notification (which the NTLP is also allowed to do anyway).
However, apart from generating such triggers, the NTLP takes no However, apart from generating such triggers, the NTLP takes no
action itself on such events, other than to ensure that subsequent action itself on such events, other than to ensure that subsequent
signaling messages are correctly routed. signaling messages are correctly routed.
5. The existence of these triggers doesn't replace NSLP refreshes as 5. The existence of these triggers doesn't replace NSLP refreshes as
the mechanism for maintaining liveness at the signaling application the mechanism for maintaining liveness at the signaling application
level. In this sense, up/down notifications are advisories which level. In this sense, up/down notifications are advisories which
allow faster reaction to events in the network, but shouldn't be allow faster reaction to events in the network, but shouldn't be
built into NSLP semantics. (This is essentially the same distinction built into NSLP semantics. (This is essentially the same distinction
- with the same rationale - as SNMP makes between traps and normal - with the same rationale - as SNMP makes between traps and normal
message exchanges.) message exchanges.)
3.2.5 Path De-Coupled Operation 3.2.6 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 that are located on the data path. Signaling only through nodes that are located on the data path. Signaling
messages can be routed to nodes off the data path, but which are messages can be routed to nodes off the data path, but which are
(presumably) aware of it. This allows a looser coupling between (presumably) aware of it. This allows a looser coupling between
signaling and data plane nodes, e.g. at the autonomous system level. signaling and data plane nodes, e.g. at the autonomous system 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
skipping to change at page 16, line 22 skipping to change at page 17, line 17
scenarios need to be analyzed differently because fate-sharing scenarios need to be analyzed differently because fate-sharing
between data and control plane can no longer be assumed. Furthermore, between data and control plane can no longer be assumed. Furthermore,
the interpretation of sender/receiver orientation becomes less the interpretation of sender/receiver orientation becomes less
natural. With the local operation of NTLP, the impact of path- natural. With the local operation of NTLP, the impact of path-
decoupled signaling on the routing of signaling messages is decoupled signaling on the routing of signaling messages is
presumably restricted to the problem of peer determination. The presumably restricted to the problem of peer determination. The
assumption that the off-path NSIS nodes are loosely tied to the data assumption that the off-path NSIS nodes are loosely tied to the data
path suggests, however, that peer determination can still be based on path suggests, however, that peer determination can still be based on
L3 routing information. This means that a path-decoupled signaling L3 routing information. This means that a path-decoupled signaling
solution could be implemented using a lower layer protocol presenting solution could be implemented using a lower layer protocol presenting
the same service interface to NSLPs as the path-coupled NTLP. the same service interface to NSLPs as the path-coupled NTLP. A new
message transport protocol (possibly derived from the path-coupled
NTLP) would be needed, but NSLP specifications and the inter-layer
interaction would be unchanged from the path-coupled case.
3.3 Signaling Application Properties 3.3 Signaling Application Properties
It is clear that many signaling applications will require specific It is clear that many signaling applications will require specific
protocol behavior in their NSLP. This section outlines some of the protocol behavior in their NSLP. This section outlines some of the
options for NSLP behavior; further work on selecting from these options for NSLP behavior; further work on selecting from these
options would depend on detailed analysis of the signaling options would depend on detailed analysis of the signaling
application in question. application in question.
3.3.1 Sender/Receiver Orientation 3.3.1 Sender/Receiver Orientation
skipping to change at page 17, line 22 skipping to change at page 18, line 19
receiver. In a sender-initiated approach, provided acknowledgements receiver. In a sender-initiated approach, provided acknowledgements
and notifications can be securely delivered to the sending node, and notifications can be securely delivered to the sending node,
backward routing is not necessary, and nodes do not have to maintain backward routing is not necessary, and nodes do not have to maintain
backward routing state. backward routing state.
*) 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, thus allowing the has to inform the receiver about its handover, thus allowing the
receiver to initiate a reservation for these flows. For incoming receiver to initiate a reservation for these flows. For incoming
flows, the reverse argument applies. flows, the reverse argument applies.
*) A sender- (receiver-) initiated approach will allow faster setup *) In general, setup and modification will be fastest if the node
and modification if the sender (receiver) is also authorized to carry responsible for authorizing these actions can initiate them directly
out the operation. A mismatch between authorizing and initiating NEs within the NSLP. 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. Depending on how the
complicate modifications of network control state for existing flows. authorization for a particular signaling application is done, this
may favor either sender or receiver initiated signaling. Note that
this may 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 a unidirectional data flow. However, in other cases, considered for a unidirectional data flow. However, in other cases,
skipping to change at page 18, line 33 skipping to change at page 19, line 33
the protocol but are inserted, used and removed by one single domain. the protocol but are 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 the objects defining the objects carried by the NSLP such that only the objects
applicable in a particular setting are used. One approach for applicable in a particular setting are used. One approach for
reflecting the distinction is that local objects could be put into reflecting the distinction is that local objects could be put into
separate local messages that are initiated and terminated within one separate local messages that are initiated and terminated within one
single domain; an alternative is that they could be "stacked" within single domain; an alternative is that they could be "stacked" within
the NSLP messages that are used anyway for inter-domain signaling. the NSLP messages that are used anyway for inter-domain signaling.
3.3.4 Peer-Peer and End-End Relationships 3.3.4 Aggregation
It is a well known problem that per-flow signaling in large-scale
networks present scaling challenges because of the large number of
flows that may traverse individual nodes.
The possibilities for aggregation at the level of the NTLP are quite
limited; the primary scaling approach for path-coupled signaling is
for a signaling application to group flows together and perform
signaling for the aggregate, rather than for the flows individually.
The aggregate may be created in a number of ways: for example, the
individual flows may be sent down a tunnel, or given a common DSCP
marking. The aggregation and deaggregation points perform per flow
signaling, but nodes within the aggregation region should only be
forced to process signaling messages for the aggregate, somehow
ignoring the per-flow signaling (see section 3.2.3).
Individual NSLPs will need to specify what aggregation means in their
context, and how it should be performed. For example, in the QoS
context it is possible to add together the resources specified in a
number of separate reservations. In the case of other applications,
such as signaling to NATs and firewalls, the feasibility (and even
the meaning) of aggregation is less clear.
3.3.5 Peer-Peer and End-End Relationships
The assumption in this framework is that the NTLP will operate The assumption in this framework is that the NTLP will operate
'locally', that is, just over the scope of a single peer 'locally', that is, just over the scope of a single peer
relationship. End-to-end operation is built up by concatenating these relationship. End-to-end operation is built up by concatenating these
relationships. Non-local operation (if any) will take place in NSLPs. relationships. Non-local operation (if any) will take place in 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 NSLP peers are not always NTLP peers (section 3.2.1). This 3.3.6 Acknowledgements and Notifications
has a number of implications for the relationship between the
signaling layers, in that NSLP peers may depend on the service
provided by a concatenation of NTLP peer relationships rather than a
single one, which makes it harder to depend strongly on some NTLP
properties (e.g. channel security, reliability).
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
NTLP peer relationship). NTLP peer relationship).
However, we expect that some signaling applications will requires However, we expect that some signaling applications will require
acknowledgements regarding the failure/success of state installation acknowledgements regarding the failure/success of state installation
along the data path, and this will be an NSLP function. along the data path, and this will be an NSLP function.
Acknowledgements can be sent along the sequence of NTLP peer Acknowledgements can be sent along the sequence of NTLP peer
relationships towards the signaling initiator, which relieves the relationships towards the signaling initiator, which relieves the
requirements on the security associations that need to be maintained requirements on the security associations that need to be maintained
by NEs and can allow NAT traversal in both directions. (If this by NEs and can allow NAT traversal in both directions. (If this
direction is towards the sender, it implies maintaining reverse direction is towards the sender, it implies maintaining reverse
routing state in the NTLP). In certain circumstances (e.g. trusted routing state in the NTLP). In certain circumstances (e.g. trusted
domains), an optimization can be to send acknowledgements directly to domains), an optimization can be to send acknowledgements directly to
skipping to change at page 19, line 43 skipping to change at page 21, line 12
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.7 Security and Other AAA Issues
In some cases it will be possible to achieve the necessary level of In some cases it will be possible to achieve the necessary level of
signaling security by using basic 'channel security' mechanisms [9] signaling security by using basic 'channel security' mechanisms [11]
at the level of the NTLP, and the possibilities are described in at the level of the NTLP, and the possibilities are described in
section 4.7. In other cases, signaling applications may have 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, the authorisation (to manipulate In addition to authentication, the authorisation (to manipulate
network control state) has to be considered as functionality above network control state) has to be considered as functionality above
the NTLP level, since it will be entirely application specific. the NTLP level, since it will be entirely application specific.
Indeed, authorisation decisions may be handed off to a third party in Indeed, authorisation decisions may be handed off to a third party in
the protocol (e.g. for QoS, the resource management function as the protocol (e.g. for QoS, the resource management function as
described in section 6.1.5). Many different authorisation models are described in section 6.1.4). Many different authorisation models are
possible, 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 [10]. contained in [12].
4 The NSIS Transport Layer Protocol 4 The NSIS Transport Layer Protocol
This section describes the overall functionality required from the This section describes the overall functionality required from the
NTLP. It mentions possible protocol components within the NTLP layer NTLP. It mentions possible protocol components within the NTLP layer
and the different possible addressing modes that can be utilized, as and the different possible addressing modes that can be utilized, as
well as the assumed transport and state management functionality. The well as the assumed transport and state management functionality. The
interfaces between NTLP and the layers above and below it are 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 enumerate design options, although some are included 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 outlined in section 3.2.3, with some more details within the NTLP is outlined in section 3.2.4, with some more details
in sections 3.2.4 and 4.3. in sections 3.2.5 and 4.3.
Some NTLP functionality could be provided via components operating as Some NTLP functionality could be provided via components operating as
sublayers within the NTLP design. For example, if specific transport sublayers within the NTLP design. For example, if specific transport
capabilities are required, such as congestion avoidance, capabilities are required, such as congestion avoidance,
retransmission, security and so on, then existing protocols, such as retransmission, security and so on, then existing protocols, such as
TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP. This TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP. This
possibility is not required or excluded by this framework. possibility is not required or excluded by this framework.
If peer-peer addressing (section 4.2) is used for some messages, then If peer-peer addressing (section 4.2) is used for some messages, then
active next-peer discovery functionality will be required within the active next-peer discovery functionality will be required within the
skipping to change at page 21, line 48 skipping to change at page 23, line 19
using some local routing table or through participation in active using some local routing table or through participation in active
peer discovery message exchanges. Peer-peer addressing inherently peer discovery message exchanges. Peer-peer addressing inherently
supports tunneling of messages between NEs, and is equally applicable supports tunneling of messages between NEs, and is equally applicable
to the path-coupled and path-decoupled cases. to the path-coupled and path-decoupled cases.
In the case of end-to-end addressing, the message is addressed to the In the case of end-to-end addressing, the message is addressed to the
data flow receiver, and (some of) the NEs along the data path data flow receiver, and (some of) the NEs along the data path
intercept the messages. The routing of the messages should follow intercept the messages. The routing of the messages should follow
exactly the same path as the associated data flow (but see section exactly the same path as the associated data flow (but see 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 [4]). raises some interesting security issues (these are discussed in [3]).
It is not possible at this stage to mandate one addressing mode or It is not possible at this stage to mandate one addressing mode or
the other. Indeed, each is necessary for some aspects of NTLP the other. Indeed, each is necessary for some aspects of NTLP
operation: in particular, initial discovery of the next downstream operation: in particular, initial discovery of the next downstream
peer will usually require end-to-end addressing, whereas reverse peer will usually require end-to-end addressing, whereas reverse
routing will always require peer-peer addressing. For other message routing will always require peer-peer addressing. For other message
types, the choice is a matter of protocol design. The mode used is types, the choice is a matter of protocol design. The mode used is
not visible to the NSLP, and the information needed in each case is not visible to the NSLP, and the information needed in each case is
available from the flow identifier (section 4.6.1) or locally stored available from the flow identifier (section 4.6.1) or locally stored
NTLP state. NTLP state.
skipping to change at page 22, line 27 skipping to change at page 23, line 43
The NSIS signaling protocols are responsible for transporting The NSIS signaling protocols are responsible for transporting
(signaling) data around the network; in general, this requires (signaling) data around the network; in general, this requires
functionality such as congestion management, reliability, and so on. functionality such as congestion management, reliability, and so on.
This section discusses how much of this functionality should be This section discusses how much of this functionality should be
provided within the NTLP. It appears that this doesn't affect the provided within the NTLP. It appears that this doesn't affect the
basic way in which the NSLP/NTLP layers relate to each other (e.g. in 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 terms of the semantics of the inter-layer interaction); it is much
more a question of the overall performance/complexity tradeoff more a question of the overall performance/complexity tradeoff
implied by placing certain functions within each layer. implied by placing certain functions within each layer.
Note that, following the discussion at the end of section 3.2.3,
there may be cases where intermediate nodes wish to modify messages
in transit even though they do not perform full signaling application
processing. In this case, not all of the following functionality
would be invoked at every intermediate node.
The following functionality is assumed to lie within the NTLP: The following functionality is assumed to lie within the NTLP:
1. Bundling together of small messages (comparable to [11]) can be 1. Bundling together of small messages (comparable to [13]) can be
provided locally by the NTLP as an option if desired; it doesn't provided locally by the NTLP as an option if desired; it doesn't
affect the operation of the network elsewhere. The NTLP should affect the operation of the network elsewhere. The NTLP should
always support unbundling, to avoid the cost of negotiating the always support unbundling, to avoid the cost of negotiating the
feature as an option. Note that end-to-end addressed messages for feature as an option. (The related function of refresh
different flows cannot be bundled safely unless the next node on summarization - where objects in a refresh message are replaced
the outgoing interface is known to be NSIS-aware. with a reference to a previous message identifier - is left to
NSLPs which can then do this in a way tuned to the state
management requirements of the signaling application. Additional
transparent compression functionality could be added to the NTLP
design later as a local option.) Note that end-to-end addressed
messages for different flows cannot be bundled safely unless the
next node on the outgoing interface is known to be NSIS-aware.
2. Message fragmentation should be provided by the NTLP when needed. 2. Message fragmentation should be provided by the NTLP when needed.
For NSLPs that generate large messages, it will be necessary to For NSLPs that generate large messages, it will be necessary to
fragment them efficiently within the network, where the use of IP fragment them efficiently within the network, where the use of IP
fragmentation may lead to reduced reliability and be incompatible fragmentation may lead to reduced reliability and be incompatible
with some addressing schemes. To avoid imposing the cost of with some addressing schemes. To avoid imposing the cost of
reassembly on intermediate nodes, the fragmentation scheme used reassembly on intermediate nodes, the fragmentation scheme used
should allow for the independent forwarding of individual should allow for the independent forwarding of individual
fragments towards a node hosting an interested NSLP. fragments towards a node hosting an interested NSLP.
3. There can be significant benefits for signaling applications if
The placement of the following functionality is still open: state-changing messages are delivered reliably (as introduced in
1. Overload detection and control. Here, the question is whether the [13] for RSVP; see also the more general analysis of [14]). This
NTLP should include common mechanisms to handle overload at the does not change any assumption about the use of soft-state by
IP layer ("congestion control") and NTLP/NSLP layers (loosely NSLPs to manage signaling application state, and leaves the
"flow control"). The arguments here are complex and somewhat responsibility for detecting and recovering from application
interrelated; a temporary summary can be found in [12]. layer error conditions in the NSLP. However, it means that such
2. Local retransmission to improve reliability. The argument in functionality does not need to be tuned to handle fast recovery
favor is that the NTLP can recover from congestive loss or from message loss due to congestion or corruption in the lower
corruption much more rapidly than end-to-end (NSLP) mechanisms; layers, and also means that the NTLP can prevent the
the argument against is that the additional complexity in the amplification of message loss rates caused by fragmentation.
NTLP is not needed for all signaling applications. (It's assumed Reliable delivery functionality is invoked by the NSLP on a
that the NTLP is not actually providing perfect message delivery message-by-message basis and is always optional to use.
guarantees or notifications, for example because NSLP peers may 4. The NTLP should not allow signaling messages to cause congestion
be separated by more than one NTLP peer relationship. A signaling in the network (i.e. at the IP layer). Congestion could be caused
application that needs peer-peer acknowledgements of this nature by retransmission of lost signaling packets or by upper layer
should define them within the NSLP.) In-order message delivery actions (e.g. a flood of signaling updates to recover from a
and duplicate detection are related functions. route change). In some cases it may be possible to engineer the
3. Message summarization. Benefits have been found (see [11]) in network to ensure that signaling cannot overload it; in other
having the signaling protocol transport only 'tags' for refresh cases, the NTLP would have to detect congestion and adapt the
signaling messages rather than the full messages themselves. In rate at which it allows signaling messages to be transmitted.
the more flexible NSIS signaling environment, it is not clear if Principles of congestion control in Internet protocols are given
this functionality can be provided correctly by the NTLP, or in [15]. The NTLP may or may not be able to detect overload in
whether it has to be done (less efficiently) by each NSLP. the control plane itself (e.g. an NSLP-aware node several NTLP-
These open issues will be resolved in a future version of this hops away which cannot keep up with the incoming message rate)
document. and indicate this as a flow-control condition to local signaling
applications. However, for both the congestion and overload
cases, it is up to the signaling applications themselves to adapt
their behavior accordingly.
4.4 Lower Layer Interfaces 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).
*) 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.
In general, it needs to know how to select the outgoing interface for In general, it needs to know how to select the outgoing interface for
a signaling message, where this must match the interface that will be a signaling message, where this must match the interface that will be
used by the corresponding flow. This might be as simple as just used by the corresponding flow. This might be as simple as just
allowing the IP layer to handle the message using its own routing allowing the IP layer to handle the message using its own routing
table. There is no intention to do something different from IP table. There is no intention to do something different from IP
skipping to change at page 24, line 52 skipping to change at page 26, line 37
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:
*) source IP address; *) source IP address;
*) destination IP address; *) destination IP address;
*) protocol identifier and higher layer (port) addressing; *) protocol identifier and higher layer (port) addressing;
*) flow label (typical for IPv6); *) flow label (typical for IPv6);
*) SPI field for IPSec encapsulated data; *) SPI field for IPsec encapsulated data;
*) DSCP/TOS field *) DSCP/TOS field
It is assumed that wildcarding on these identifiers is not needed It is assumed that wildcarding on these identifiers is not needed
(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.3): 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.6.2 Session Identification 4.6.2 Session Identification
There are circumstances where it is important to be able to refer to There are circumstances 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.
skipping to change at page 26, line 41 skipping to change at page 28, line 28
Channel security can provide many different types of protection to Channel security can provide many different types of protection to
signaling exchanges, including integrity and replay protection and signaling exchanges, including integrity and replay protection and
encryption. It is not clear which of these is required at the NTLP encryption. It is not clear which of these is required at the NTLP
layer, although most channel security mechanisms support them all. layer, although most channel security mechanisms support them all.
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 (alternatively, if the NAT takes part in NTLP
NTLP messages need protecting, and what type of protection should be security procedures, it only needs to be given access to the message
applied to each. fields containing addresses, often just the flow id). It is an open
question as to which parts of the NTLP messages need protecting, and
what type of protection should be applied to each.
5 Interactions with Other Protocols 5 Interactions with Other Protocols
5.1 IP Routing Interactions 5.1 IP Routing Interactions
The NSIS Transport Layer (NTLP) is responsible for discovering the The NTLP is responsible for determining the next node to be visited
next node to be visited by the signaling protocol. For path-coupled by the signaling protocol. For path-coupled signaling, this next node
signaling, this next node should be one that will be visited by the should be one that will be visited by the data flow. In practice,
data flow. In practice, this peer discovery will be approximate, as this peer discovery will be approximate, as any node could use any
any node could use any feature of the peer discovery packet to route feature of the peer discovery packet to route it differently from the
it differently than the corresponding data flow packets. Divergence corresponding data flow packets. Divergence between data and
between data and signaling path can occur due to load sharing or load signaling path can occur due to load sharing or load balancing
balancing (section 5.1.1). An example specific to the case of QoS is (section 5.1.1). An example specific to the case of QoS is given in
given in section 6.1.1. Route changes cause a temporary divergence section 6.1.1. Route changes cause a temporary divergence between the
between the data path and the path on which signaling state has been data path and the path on which signaling state has been installed.
installed. The occurrence, detection and impact of route changes is The occurrence, detection and impact of route changes is described in
described in section 5.1.2. A description of this issue in the section 5.1.2. A description of this issue in the context of QoS is
context of QoS is given in section 6.1.2. 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 signaling messages using end-to-end addressing does not routing of signaling messages using end-to-end addressing does not
guarantee that the messages will follow the data path. Policy-based guarantee that the messages will follow the data path. Policy-based
forwarding for data packets - where the outgoing link is selected forwarding for data packets - where the outgoing link is selected
based on policy information about fields additional to the packet based on policy information about fields additional to the packet
destination address - has the same impact. destination address - has the same impact. Signaling and data packets
may diverge because of both of these techniques.
Signaling and data flow packets may diverge because of these Load balancing techniques have been proposed for a number of routing
techniques. In OSPF, load balancing can be used between equal cost protocols, such as OSPF equal cost paths [16] and others. Typically,
paths [15] or unequal cost paths. An example of the latter approach based on the load reported from a particular path, load balancing
is Optimized Multi Path (OMP). OMP discovers multiple paths, not determines which fraction of the data to direct to that path.
necessarily equal cost paths, to any destinations in the network, but Incoming packets are subject to a (source, destination address) hash
based on the load reported from a particular path, it determines
which fraction of the data to direct to the given path. Incoming
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.
chosen by the BGP decision process to other BGP speakers. In the
basic specification, routes with the same Network Layer reachability
information (NLRI) as previously advertised routes implicitly replace
the original advertisement, which means that multiple paths for the
same prefix cannot exist. This restriction could be removed by
suitable extensions to BGP.
If the routing decision is based on both source and destination
address, signaling and data flow packets may still diverge because of
layer 4 load-balancing (based on protocol or port number). Such
techniques would, however, constrain the use of proxies. Proxies
would cause ICMP errors to be misdirected to the source of the data
because of source address spoofing.
If the routing decision is based on the complete five-tuple, If signaling packets are given source and destination addresses
divergence may still occur because of the presence of router alert identical to data packets, signaling and data packets may still
options. In this case, the same constraint on proxy use applies as diverge because of layer 4 load-balancing (based on protocol or port
above. Additionally, it becomes difficult for the end systems to number). Such techniques would also cause ICMP errors to be
misdirected to the source of the data because of the source address
spoofing. If signaling packets are made identical in the complete
five-tuple, divergence may still occur because of the presence of
router alert options. In this case, the same ICMP misdirection
applies. 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 may base the routing decision on any field in the packet
in the packet header (e.g. DSCP, ...). header (e.g. DSCP, ...).
Most load-balancing techniques use the first n bytes of the packet Many load-balancing implementations use the first n bytes of the
header (including SA, DA and protocol field) in the hashing function. packet header (including SA, DA and protocol) in the hash function.
In this case, the above considerations regarding source/destination In this case, the general considerations above regarding SA/DA or
address or five-tuple based forwarding apply. five-tuple based forwarding continue to apply.
5.1.2 Route Changes 5.1.2 Route Changes
In a routed network, each packet is independently routed based on its In a connectionless network, each packet is independently routed
header information. Whenever a better route towards the destination based on its header information. Whenever a better route towards the
becomes available, this route is installed in the forwarding table destination becomes available, this route is installed in the
and will be used for all subsequent (data and signaling) packets. forwarding table and will be used for all subsequent (data and
This can cause a divergence between the path along which state has signaling) packets. This can cause a divergence between the path
been installed and the path along which forwarding will actually take along which state has been installed and the path along which
place. forwarding will actually take place. (The problem of route changes is
reduced if route pinning is performed. Route pinning refers to the
independence of the path taken by certain data packets from
reachability changes caused by routing updates from an Interior
Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).
Nothing about NSIS signaling prevents route pinning being used as a
network engineering technique, provided it is done in a way which
preserves the common routing of signaling and data. However, even if
route pinning is used, it cannot be depended on to prevent all route
changes (for example in the case of link failures).
The possibility of route changes requires the presence of three Handling route changes requires the presence of three processes in
processes in the signaling protocol the signaling protocol:
1. route change detection 1. route change detection
2. installation of state on the new path 2. installation of state on the new path
3. removal of state on the old path 3. removal of state on the old path
Many route change detections methods can be used, some of which need Many route change detection methods can be used, some needing
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 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 flow-aware router
router
e) inference from changes in signaling 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 an 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 These methods can be categorized as being based on network monitoring
on network monitoring (method a-b), based on data packet monitoring (method a-b), based on data packet monitoring (method c-d) and based
(method c-d) and based on monitoring signaling protocol messages on monitoring signaling protocol messages (method e-g); method f is
(method e-g). Methods contingent on monitoring signaling messages the baseline method of RSVP. Methods contingent on monitoring
become less effective as refresh reduction techniques are used. signaling messages become less effective as soft state refresh rates
are reduced.
When a route change has been detected, it is important that state is 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
identification (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
identification (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
identification, i.e. the session identifier (section 4.6.2). identification, i.e. the session identifier (section 4.6.2). Mobility
issues are discussed in more detail in section 5.2.
When state has been installed along the new path, the existing state 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
route pinning. Route pinning refers to the independence of the path
taken by certain data packets from reachability changes caused by
routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an
Exterior Gateway Protocol (BGP).
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 state management with high-availability
characteristics, i.e. with rapid transparent recovery even in the characteristics, i.e. with rapid transparent recovery even in the
presence of route changes. This may need interactions with protocols presence of route changes. This may need interactions with protocols
which are used to manage the routing in this case, such as VRRP [18]. which are used to manage the routing in this case, such as VRRP [17].
A future version of this document might consider interactions between
NSIS and such protocols to support high availability functionality.
5.2 Mobility Interactions
Mobility, in most cases, causes changes to the data path that packets
take. Assuming that signaling has already taken place to establish
some state along the data path, new signaling may be needed in order
to (re)establish state along the changed data path.
The interactions between mobility and signaling protocols have been
extensively analyzed in recent years, primarily in the context of
RSVP and Mobile IP interaction (e.g. the mobility discussion of [7]),
but also in the context of other types of network (e.g. [19]); a
general review of the fundamental interactions is given in [20],
which provides further details on many of the subjects considered in
these sections. This analysis work has shown that some difficulties
in the interactions are quite deeply rooted in the detailed design of
these protocols; however, the problems and their possible solutions
fall under five broad headings. The main issues for a resource
signaling application are limiting the period after handovers during
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
A mobility solution typically involves address reallocation on
handover (unless a network supports per host routing) and may involve
special packet formats (e.g. the routing header and Home Address
option of MIPv6). Since signaling may depend on end system addresses
for forwarding signaling messages and defining flows (section 4.6.1),
the special implications of mobility for addressing need to be
considered. The two possible approaches are as follows:
*) Use a flow identification based on low level IP addresses (e.g.
the Care of Address) and other 'standard' fields in the IP header.
This makes least demands on the packet classification engines within
the network. However, it means that even on a part of the flow path
that is unchanged, the session will need to be modified to reflect
the changed flow identification (see section 5.2.3).
*) Use a flow identification that does not change (e.g. based on Home
Address). This simplifies the problem of session update, at the
likely cost of considerably complicating the flow identification
requirements and making stronger demands on packet classification.
In the first approach, to prevent double reservation, NSIS entities
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 (section 4.6.2) could be used for this purpose, but it
needs to have global semantics.
While the feasibility of the first approach needs to be proven, given
the impact of requiring more sophisticated packet classifiers, it
still seems more plausible than the second. This means that signaling
applications should define flows in terms of real, routable (care of)
addresses rather than virtual (home) addresses.
5.2.2 Localized Path Repair
In any mobility approach, a handover will cause at least some changes
in the path of upstream and downstream packets. At some point along
the joined path, an NSIS entity should be able to recognize this
situation, based upon session identification. State needs to be
installed on the new path, and removed from the old. Who triggers the
new state may be constrained by which entities are authorised to
carry out which state manipulations, which is then a signaling
application question.
A critical point here is the signaling that is used to discover the
crossover node. This is a generalization of the problem of finding
next-NSIS peer: it requires extending the new path until it
intersects the old one. This is easy for the uplink direction (where
the mobile is the sender), but much harder for downlink without
signaling via the correspondent. There is no reason for the crossover
node to be the same for uplink and downlink flows, even for the same
correspondent. The problem is discussed further in [21].
5.2.3 Update on the Unchanged Path
On the path between the crossover node(s) and the correspondent, it
is necessary to avoid, if possible, double reservations, but also to
update the network control state to reflect new flow identification
(this is needed, by the default assumption of section 5.2.1).
Examples of approaches that could be used to solve this problem are
the following:
*) Use a session state identification that does not change even if
the flow definition changes (see Section 4.6.2). Signaling is still
needed to update a changed flow identification, but it should be
possible to avoid AAA and admission control processing.
*) Use an NSIS-capable crossover router that manages this update
autonomously (more efficiently than the end nodes could), with
similar considerations to the local path repair case.
Note that in the case of an address change, end to end message
exchanges will be required at the application layer anyway, so
signaling to update the flow identifier does not necessarily add to
the handover latency.
5.2.4 Interaction with Mobility Signaling
In existing work on mobility protocol and signaling protocol Our basic assumption about such interactions is that the NTLP would
interactions, several framework proposals describing the protocol be responsible for detecting the route change and ensuring that
interactions have been made. Usually they have taken existing signaling messages were re-routed appropriately along with data
protocols (Mobile IP and RSVP respectively) as the starting point; it traffic; but that the further state re-synchronization (including
should be noted that an NSIS protocol might operate in quite a failover between 'main' and 'standby' nodes in the high availability
different way. In this section, we provide an overview of how these case) would be the responsibility of the signaling application and
proposals fit within the rest of this framework. The mobility aspects its NSLP, possibly triggered by the NTLP.
are described using MIP terminology, but are generally applicable to
other network layer mobility solutions. The purpose of this overview
is not to select any particular approach, but simply to point out how
they would fit into our framework and any major issues with them.
We can consider that two signaling processes are active: mobility 5.2 Mobility and Multihoming Interactions
signaling and NSIS signaling. The discussion so far considered how
NSIS signaling should operate. There is still a question of how the
interactions between the NSIS and mobility signaling should be
considered.
The basic case of totally independent specification and The issues associated with mobility and multihoming are a
implementation can lead to ambiguities and even interoperability generalization of the basic route change case of the previous
problems. At least, the addressing and encapsulation issues for section. As well as the fact that packets for a given session are no
mobility solutions that use virtual links or their equivalents need longer traveling over a single topological path, the following extra
to be specified in an implementation-neutral way. considerations arise:
1) The use of IP-layer mobility and multihoming means that more than
one IP source or destination address will be associated with a single
session. The same applies if application layer solutions (e.g. SIP-
based approaches) are used.
2) Mobile IP and associated protocols use some special encapsulations
for some segments of the data path.
3) The double route may persist for some time in the network (e.g. in
the case of a 'make-before-break' handover being done by a multihomed
host).
4) Conversely, the re-routing may be rapid and routine (unlike
network internal route changes), increasing the importance of rapid
state release on old paths.
A type of 'loose' integration is to have independent protocols, but The interactions between mobility and signaling have been extensively
to define how they trigger each other - in particular, how the analyzed in recent years, primarily in the context of RSVP and Mobile
mobility protocol triggers sending of refresh/modify/tear messages. A IP interaction (e.g. the mobility discussion of [6]), but also in the
pair of implementations could use these triggers to improve context of other types of network (e.g. [18]); a general review of
performance, primarily reducing latency. (Existing RSVP modifications the fundamental interactions is given in [19], which provides further
consider the closer interaction of making the RSVP implementation details on many of the subjects considered in this section.
mobility routing aware, e.g. so it is able to localize refresh
signaling; this would be a self contained aspect of NSIS.)
An even tighter level of integration is to consider a single protocol We are assuming that the signaling will refer to 'outer' IP headers
carrying both mobility and network control state information. when defining the flows it is controlling. There two main reasons for
Logically, there are two cases: this. The first is that the data plane will usually be unable to work
in terms of anything else when implementing per-flow treatment (e.g.
we cannot expect a router will analyse inner headers to decide how to
schedule packets). The second reason is that we are implicitly
relying on the security provided by the network infrastructure to
ensure that the correct packets are given the special treatment being
signaled for, and this is built on the relationship between packet
source and destination addresses and network topology (this is
essentially the same approach that is used as the basis of route
optimization security in Mobile IPv6 [20]). The consequence of this
assumption is that we see the packet streams to (or from) different
addresses as different flows, and where a flow is carried inside a
tunnel this is seen as a different flow again. The encapsulation
issues (point (2) above) are therefore to be handled the same way as
other tunneling cases (section 5.4).
1. Carry mobility routing information (a 'mobility object') in the The most critical aspect is therefore the fact that multiple flows
signaling messages. (The prime purpose in this approach is to enable are being used, and the signaling for them needs to be correlated
crossover router discovery.) together. This is the intended role of the session identifier (see
2. Carry signaling in the mobility messages, typically as a new section 4.6.2, which also describes some of the security requirements
extension header. In our framework, we could consider this a special for such an identifier). Although the session identifier is visible
case of NSIS layering, with the mobility protocol playing the role of at the NTLP, it is the signaling application which is responsible for
the signaling transport. performing the correlation (and doing so securely). The NTLP
responsibility is limited to delivering the signaling messages for
each flow between the correct signaling application peers. The
locations at which the correlation takes place are the end system and
the signaling application aware node in the network where the flows
meet (this node is generally referred to as the "crossover router";
it can be anywhere in the network).
Other modes of interaction might also be possible. The critical point Although much work has been done in the past on finding the crossover
with all these models is that the general solutions developed by NSIS router directly from information held in particular mobility
should be independent of choice of mobility protocols. Tight signaling protocols, the initial focus of NSIS work should be to have
integration would have major deployment issues especially in a solution which is not tightly bound to any single mobility
interdomain cases. Therefore, any tightly integrated solution is approach. In other words, it should be possible to determine the
considered out of scope of initial development. crossover router based on NSIS signaling. (This doesn't rule out the
possibility that some implementations may be able to do this
discovery faster, e.g. by being tightly integrated with local
mobility management protocols; this is directly comparable to
spotting route changes in fixed networks by being routing aware.)
5.2.5 Interaction with Seamless Handover Protocols Note that the crossover router discovery may involve end-to-end
signaling exchanges (especially for flows towards the mobile or
multihomed node) which raises a latency concern; on the other hand,
end to end signaling will have been necessary in any case, both at
the application level (to communicate changed addresses) and also to
update packet classifiers along the path. It is a matter for further
analysis to decide how these exchanges could be combined or carried
out in parallel.
In the context of mobility between different access routers, it is On the shared part of the path, signaling is needed at least to
common to consider performance optimizations in two areas: selection update the packet classifiers to include the new flow, although if
of the optimal access router to handover to, and transfer of state correlation with the existing flow is possible it should be possible
information between the access routers to avoid having to regenerate to bypass any policy or admission control processing. State
it in the new access router after handover. The Seamoby Working Group installation on the new path (and possibly release on the old one)
is developing solutions for these protocols (CARD [22] and Context are also required. Which entity (one of the end hosts or the
Transfer [23] respectively); alternative approaches with similar crossover router) controls all these procedures depends on which
characteristics are also possible. entities are authorised to carry out network state manipulations, so
this is therefore a matter of signaling application and NSLP design.
The approach may depend on the sender/receiver orientation of the
original signaling (see section 3.3.1). In addition, in the mobility
case, the old path may no longer be directly accessible to the mobile
node; inter-access-router communication may be required to release
state in these circumstances.
As these solutions are still under development, it is premature to The frequency of handovers in some network types encourages the
specify details on the interaction. It is thought that Context consideration of fast handover support protocols, for selection of
Transfer transfers state between access routers based upon changes the optimal access router to hand over to (for example, [21]), and
caused by mobility. NSIS protocol state may be a candidate for transfer of state information to avoid having to regenerate it in the
context transfer. Such work, should it be undertaken, will be done new access router after handover (for example, [22]). Both these
in the Seamoby working group. procedures could have strong interactions with signaling protocols,
the former because a selection criterion might be what network
control state could be supported on the path through the new access
router, the latter because signaling application state or NTLP/NSLP
protocol state may be a candidate for context transfer.
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
and possibly higher layer information as payload, we must consider addresses and possibly higher layer information as payload, we must
the interaction with address translation devices (NATs). As well as consider the interaction with address translation devices (NATs).
'traditional' NATs of various types (as defined in [24]) very similar These considerations apply both to 'traditional' NATs of various
considerations would apply to some IPv4/v6 transition mechanisms such types (as defined in [23]) as well as some IPv4/v6 transition
as SIIT [25]. mechanisms such as SIIT [24].
In the simplest case of an NSIS unaware NAT in the path, payloads In the simplest case of an NSIS unaware NAT in the path, payloads
will be uncorrected and signaling will refer to the flow incorrectly. will be uncorrected and signaling will refer to the flow incorrectly.
Applications could attempt to use STUN [26] or similar techniques to Applications could attempt to use STUN [25] or similar techniques to
detect and recover from the presence of the NAT. Even then, NSIS detect and recover from the presence of the NAT. Even then, NSIS
protocols would have to use a well known encapsulation (TCP/UDP/ICMP) protocols would have to use a well known encapsulation (TCP/UDP/ICMP)
to avoid being dropped by more cautious low-end NAT devices. to avoid being dropped by more cautious low-end NAT devices.
A simple 'NSIS-aware' NAT would require flow identification A simple 'NSIS-aware' NAT would require flow identification
information to be in the clear and not integrity protected. An information to be in the clear and not 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.6.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.
5.4 Interactions with IP Tunneling
Tunneling is used in the Internet for a number of reasons such as
flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
private networking, and so on. An NSIS solution must continue to work
in the presence of these techniques, i.e. the presence of the tunnel
should not cause problems for end-to-end signaling, and it should
also be possible to use NSIS signaling to control the treatment of
the packets carrying the tunneled data.
It is assumed that the NSIS approach will be similar to that of [26],
where the signaling for the end-to-end data flow is tunneled along
with that data flow, and is invisible to nodes along the path of the
tunnel (other than the endpoints). This provides backwards
compatibility with networks where the tunnel endpoints do not support
the NSIS protocols. We assume that NEs will not unwrap tunnel
encapsulations to find and process tunneled signaling messages.
To signal for the packets carrying the tunneled data, the tunnel is
considered as a new data flow in its own right, and NSIS signaling is
applied recursively to it. This requires signaling support in at
least one tunnel endpoint. In some cases (where the signaling
initiator is at the opposite end of the data flow from the tunnel
initiator - i.e. in the case of receiver initiated signaling), there
needs to be the ability to provide a binding between the original
flow identification and that for the tunneled flow. It is left open
here whether this should be an NTLP or an NSLP function.
6 Signaling Applications 6 Signaling Applications
This section describes NSLPs for particular signaling applications. This section gives an overview of NSLPs for particular signaling
The assumption is that the NSLP uses the generic functionality of the applications. The assumption is that the NSLP uses the generic
NTLP given earlier; this section describes specific aspects of NSLP functionality of the NTLP given earlier; this section describes
operation. specific aspects of NSLP operation. It is intended to clarify by
example how NSLPs fit into the framework; formal NSLP protocol
designs will be contained in separate documents.
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 *) QoS NSIS Initiator (QNI): the signaling entity which makes the
request, usually as a result of user application request. resource request, usually as a result of user application request.
*) NSIS Responder (NR): the signaling entity that acts as the *) QoS NSIS Responder (QNR): the signaling entity that acts as the
endpoint for the signaling and can optionally interact with endpoint for the signaling and can optionally interact with
applications as well. applications as well.
*) NSIS Forwarder (NF): the signaling entity between an NI and NR *) QoS NSIS Forwarder (QNF): the signaling entity between a QNI and
which propagates NSIS signaling further through the network. QNR 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 QNI role: with respect to the data flow direction it
direction it could be at the sending or receiving end. could be at the sending or receiving end.
6.1.1 Protocol Messages Note the continued assumption is that the NTLP works with standard
(i.e. best-effort) layer 3 routing. There are, however, several
proposals for the introduction of QoS awareness in routing protocols.
All of these essentially lead to the existence of multiple paths
(with different QoS) towards the same destination. As such, they also
contain an inherent risk for a divergence between control plane and
data plane, similar to the load sharing case. Clearly, any QoS NSLP
needs to be able to handle this type of routing, although, provided
the NTLP continues to deliver signaling messages correctly, the
impact on the QoS NSLP protocol design itself should be limited.
6.1.1 Protocol Message Semantics
The QoS NSLP will include a set of messages to carry out resource The QoS NSLP will include a set of messages to carry out resource
reservations along the signaling path. A message set for the QoS NSLP reservations along the signaling path. A possible set of message
is shown below (a very similar set of messages was generated in semantics for the QoS NSLP is shown below. Note that the 'direction'
[27]). Note that the 'direction' column in the table below only column in the table below only indicates the 'orientation' of the
indicates the 'orientation' of the message. The messages can be message. Messages can be originated and absorbed at QNF nodes as well
originated and absorbed at NF nodes as well as the NI or NR; an as the QNI or QNR; an example might be QNFs at the edge of a domain
example might be NFs at the edge of a domain exchanging messages to exchanging messages to set up resources for a flow across a it. Note
set up resources for a flow across a it. that it is left open if the responder can release or modify a
reservation, during or after setup. This seems mainly a matter of
assumptions about authorization, and the possibilities might depend
on resource type specifics.
Note the working assumption that responder as well as the initiator The table also explicitly includes a refresh operation. This does
can release a reservation (comparable to rejecting it in the first nothing to a reservation except extend its lifetime, and is one
place). It is left open if the responder can modify a reservation, possible state management mechanism (see next section).
during or after setup. This seems mainly a matter of assumptions
about authorization, and the possibilities might depend on resource
type specifics.
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
| Name |Direction| Semantics | | Operation |Direction| Semantics |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Request| I-->R | Create a new reservation for a flow | |Request| I-->R | Create a new reservation for a flow |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Modify | I-->R | Modify an existing reservation | |Modify | I-->R | Modify an existing reservation |
| |(&R-->I?)| | | |(&R-->I?)| |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Release| I-->R & | Delete (tear down) an existing reservation | | Release | I-->R | Delete (tear down) an existing reservation |
| | R-->I | | | |(&R-->I?)| |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Accept/| R-->I | Confirm (possibly modified?) or reject a | |Accept/| R-->I | Confirm (possibly modified?) or reject a |
| Reject| | reservation request | | Reject| | reservation request |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Notify | I-->R & | Report an event detected within the | |Notify | I-->R & | Report an event detected within the |
| | R-->I | network | | | R-->I | network |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
|Refresh| I-->R | State management (see section 4.4) | | Refresh | I-->R | State management (see section 6.1.2) |
+-------+---------+---------------------------------------------+ +-----------+---------+--------------------------------------------+
The table also explicitly includes a refresh message. This does
nothing to a reservation except extend its lifetime, and is one
possible state management mechanism (see next section).
6.1.2 State Management 6.1.2 State Management
The prime purpose of NSIS is to manage state information along the The prime purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in within the NTLP (state related to message transport) are described in
section 4. The QoS NSLP will typically have to handle additional section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made. state related to the desired resource reservation to be made.
There two critical issues to be considered in building a robust NSLP There two critical issues to be considered in building a robust NSLP
skipping to change at page 35, line 39 skipping to change at page 37, line 4
6.1.2 State Management 6.1.2 State Management
The prime purpose of NSIS is to manage state information along the The prime purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in within the NTLP (state related to message transport) are described in
section 4. The QoS NSLP will typically have to handle additional section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made. state related to the desired resource reservation to be made.
There two critical issues to be considered in building a robust NSLP There two critical issues to be considered in building a robust NSLP
to handle this problem: to handle this problem:
*) 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 [28] or state; examples of each for the case of QoS would be IntServ [27] or
RMD [29] (per 'class' state) respectively. RMD [28] (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, soft state management is typically used as For resource reservations, soft state management is typically used as
a general robustness mechanism. According to the discussion of a general robustness mechanism. According to the discussion of
section 3.2.4, the soft state protocol mechanisms are built into the section 3.2.5, the soft state protocol mechanisms are built into the
NSLP for the specific signaling application that needs them; the NTLP NSLP for the specific signaling application that needs them; the NTLP
sees this simply as a sequence of (presumably identical) messages. sees this simply as a sequence of (presumably identical) messages.
6.1.3 QoS Forwarding 6.1.3 Route Changes and QoS Reservations
The assumption is that the NTLP works with standard (i.e. best-
effort) layer 3 routing. There are, however, several proposals for
the introduction of QoS awareness in the routing protocols. All of
these essentially lead to the existence of multiple paths (with
different QoS) towards the same destination. As such, they also
contain an inherent risk for a divergence between control plane and
data plane, similar to the load sharing case. Clearly, any QoS NSLP
needs to be able to handle this type of routing.
For intra-domain data flows, the difference in routing may result
from a QoS-aware traffic engineering scheme, that e.g. maps incoming
flows to LSPs based on multi-field classification. In BGP, several
techniques for including QoS information in the routing decision are
currently proposed. A first proposal is based on a newly defined BGP-
4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute is
an optional transitive attribute that can be used to advertise a QoS
route to a peer or to provide QoS information along with the Network
Layer Reachability Information (NLRI) in a single BGP update. A
second proposal is based on controlled redistribution of AS routes
[17]. It defines a new extended community (the redistribution
extended community) that allows a router to influence how a specific
route should be redistributed towards a specified set of eBGP
speakers. The types of redistribution communities may result in a
specific route not being announced to a specified set of eBGP
speakers, that it should not be exported or that the route should be
prepended n times.
6.1.4 Route Changes and QoS Reservations
In this section, we will explore the expected interworking between a In this section, we will explore the expected interaction between
signaling for resource BGP routing updates, although the same applies resource signaling and routing updates (the precise source of routing
for any source of routing updates. The normal operation of the NSIS updates does not matter). The normal operation of the NSIS protocol
protocol will lead to the situation depicted in Figure 7, where the will lead to the situation depicted in Figure 7, where the reserved
reserved resources match the data path. resources match the data path.
reserved +----+ reserved +----+ reserved +-----+ reserved +-----+
------->| NF |----------->| NF | ------->| QNF |----------->| QNF |
+----+ +----+ +-----+ +-----+
===================================== =======================================
data path data path
Figure 7: Normal NSIS protocol operation Figure 7: Normal NSIS protocol operation
A route change (triggered by a BGP routing update for instance) can
occur while such a reservation is in place. In case of RSVP, the A route change can occur while such a reservation is in place. The
route change will be installed immediately and any data that is sent route change will be installed immediately and any data will be
will be forwarded on the new path. This situation is depicted Figure forwarded on the new path. This situation is depicted Figure 8.
8.
Route update Route update
| |
v v
reserved +----+ reserved +----+ reserved +-----+ reserved +-----+
------->| NF |----------->| NF | ------->| QNF |----------->| QNF |
+----+ +----+ +-----+ +-----+
========== | ========== |
|| | +----+ || | +-----+
|| +---------->| NF | || +---------->| QNF |
|| +----+ || +-----+
============================ ============================
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 [2] has several techniques could be considered. As an example, RSVP [1] 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 QNF should wait until resources have
reserved on the new path before installing the route change (unless been reserved on the new path before installing the route change
of course the old path no longer exists). The route change procedure (unless of course the old path no longer exists). The route change
then consists of the following steps: procedure then consists of the following steps:
1. NF receives a route announcement, 1. QNF 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 sent 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 QNF has been acknowledged about the reservations on the
new path, the route will be installed and data will flow along it. new path, the route will be installed and data will flow along it.
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 [29]. This solution adapts to a route congestion and is explained in [28]. This solution adapts to a route
change, when a route change creates a congestion on the new routed change, when a route change creates congestion on the new routed
path. path.
6.1.5 Resource Management Interactions 6.1.4 Resource Management Interactions
The QoS NSLP itself is not involved in any specific resource The QoS NSLP itself is not involved in any specific resource
allocation or management techniques. The definition of an NSLP for allocation or management techniques. The definition of an NSLP for
resource reservation with Quality-of-Service, however, implies the resource reservation with Quality of Service, however, implies the
notion of admission control. For a QoS NSLP, the measure of 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
resource pool that is provisioned in the network. We define the resource pool that is provisioned in the network. We define the
function responsible for allocating this resource pool as the function responsible for allocating this resource pool as the
Resource Management Function (RMF). The RMF is responsible for all Resource Management Function (RMF). The RMF is responsible for all
resource provisioning, monitoring and assurance functions in the resource provisioning, monitoring and assurance functions in the
network. network.
A QoS NSLP will rely on the RMF to do resource management and to A QoS NSLP will rely on the RMF to do resource management and to
provide inputs for admission control. In this model, the RMF acts as provide inputs for admission control. In this model, the RMF acts as
a server towards client NSLP(s). It is noted, however, that the RMF a server towards client NSLP(s). 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 specialized intradomain QoS signaling, running between just the edges
of the network (see [30], [31], and [32] for a discussion of similar of the network (see [10], [29], and [30] 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 a QNF (note that co-
location with an NI/NR can be handled logically as a combination location with a QNI/QNR can be handled logically as a combination
between NF and NI/NR). To cater for both cases, we define a (possibly between QNF and QNI/QNR). To cater for both cases, we define a
logical) NF-RMF interface. Over this interface, information may be (possibly logical) NF-RMF interface. Over this interface, information
provided from the RMF about monitoring, resource availability, may be provided from the RMF about monitoring, resource availability,
topology, and configuration. In the other direction, the interface topology, and configuration. In the other direction, the interface
may be used to trigger requests for resource provisioning. One way to may be used to trigger requests for resource provisioning. One way to
formalize the interface between the NF and the RMF is via a Service formalize the interface between the QNF and the RMF is via a Service
Level Agreement (SLA). The SLA may be static or it may be dynamically Level Agreement (SLA). The SLA may be static or it may be dynamically
updated by means of a negotiation protocol. Such a protocol is updated by means of a negotiation protocol. Such a protocol is
outside the scope of NSIS. outside the scope of NSIS.
There is no assumed restriction on the placement of the RMF. It may There is no assumed restriction on the placement of the RMF. It may
be a centralized RMF per domain, several off-path distributed RMFs, be a centralized RMF per domain, several off-path distributed RMFs,
or an on-path RMF per router. The advantages and disadvantages of or an on-path RMF per router. The advantages and disadvantages of
both approaches are well-known. Centralization typically allows both approaches are well-known. Centralization typically allows
decisions to be taken on more global information with more efficient decisions to be taken using more global information with more
resource utilization as a result. It also facilitates deployment or efficient resource utilization as a result. It also facilitates
upgrade of policies. Distribution allows local decision processes and deployment or upgrade of policies. Distribution allows local decision
rapid response to data path changes. processes and rapid response to data path changes.
6.2 Other Signaling Applications 6.2 Other Signaling Applications
As well as the use for 'traditional' QoS signaling, it should be As well as the use for 'traditional' QoS signaling, it should be
possible to use develop NSLPs for other signaling applications which possible to 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 [5], and initial discussions of NSIS-like solutions are contained in
[33] and [34]. Other examples include network monitoring and testing, [31] and [32]. Other examples include network monitoring and testing,
and tunnel endpoint discovery. and tunnel endpoint discovery.
A future version of this document may contain more details on how to
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.7. 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 application entities (see section 3.2.3 for a discussion of the case
channel security mechanism using an external key management mechanism where these entities are separated by more than one NTLP hop). These
based on mutual authentication. In addition, the NTLP should be functions can most likely be provided by some kind of channel
resilient against denial of service attacks on the protocol itself. security mechanism using an external key management mechanism based
on mutual authentication. In addition, the NTLP should be 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.
Authorisation is a complex topic, for which a very brief overview is
provided in section 3.3.7.
Another factor is that NTLP security mechanisms operate only locally, Another factor is that NTLP security mechanisms operate only locally,
whereas NSLP mechanisms may also need to operate over larger regions whereas NSLP mechanisms may also need to operate over larger regions
(not just between adjacent peers) especially for authorisation (not just between adjacent peers) especially for 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.
other security design will depend on a refinement of the NSIS threats
work begun in [4]. An additional concern for signaling applications is the session
identifier security issue (sections 4.6.2 and 5.2). The purpose of
this identifier is to decouple session identification (as a handle
for network control state) from session "location" (i.e. the data
flow endpoints). The identifier/locator distinction has been
extensively discussed in the user plane for end to end data flows,
and is known to lead to non-trivial security issues in binding the
two together again; our problem is the analogue in the control plane,
and is at least similarly complex, because of the need to involve
nodes in the interior of the network as well.
Further work on this and other security design will depend on a
refinement of the NSIS threats work begun in [3].
8 Change History 8 Change History
8.1 Changes from draft-ietf-nsis-fw-02.txt [Editor's note: this section to be removed in final published
version.]
8.1 Changes from draft-ietf-nsis-fw-03.txt
1. Added new general section (using part of old content of 3.2.1)
about how to handle intermediate nodes which don't really want to
process some signaling application messages fully (new section
3.2.3).
2. Added a new section outlining where responsibility for
aggregation is placed within the layer split (section 3.3.4).
3. Closed the issue about reliability by saying that the NTLP must
provide the ability to deliver a message reliably but that this
doesn't mean the same thing as hard state or guaranteed execution
at the receiver - essentially the conclusions from draft-hancock-
nsis-reliability-00.txt (section 4.3).
4. Removed the issue about summary refreshes (section 4.3), allowing
the NSLP to do it by choice and leaving open extension of the
NTLP to do more general lower layer compression.
5. Included small notes on route change interactions and layer split
assumption, including merging in of VRRP considerations; also
some general text tidying (section 5.1.2).
6. Radically shortened and updated the mobility discussion (section
5.2), outlining the layer split assumption but removing most of
the analysis and justification, in the hope that a separate
document will eventually cover this area.
7. Included new section on tunnel handling (section 5.4).
8. Removed most of the detailed discussion of QoS routing and BGP
from section 6.1. Updated terminology in line with current QoS-
NSLP design work, and clarified that this is not actually the
official protocol design.
9. Updated references and fixed a number of minor typos.
8.2 Changes from draft-ietf-nsis-fw-02.txt
1. Re-instated 'long' definition of path-coupled from -01 version 1. Re-instated 'long' definition of path-coupled from -01 version
(section 3.1.2). (section 3.1.2).
2. Moved NTLP open issues (transport and state management 2. Moved NTLP open issues (transport and state management
functionality) to section 3.2.4 and 4.3, and closed several of functionality) to section 3.2.5 and 4.3, and closed several of
them: NTLP does bundling and fragmentation, but is ignorant of them: NTLP does bundling and fragmentation, but is ignorant of
NSLP state and vice versa. However, added a new open issue on NSLP state and vice versa. However, added a new open issue on
message summarization. message summarization.
3. Updated section 5.2 and elsewhere to refer to the WG draft on 3. Updated section 5.2 and elsewhere to refer to the WG draft on
mobility/RSVP analysis and an external review paper. Updated mobility/RSVP analysis and an external review paper. Updated
section 6.2 with references to more recent work on path-coupled section 6.2 with references to more recent work on path-coupled
signaling to middleboxes. General tidying of other references. signaling to middleboxes. General tidying of other references.
8.2 Changes from draft-ietf-nsis-fw-01.txt 8.3 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
dependent behavior are described in section 3.3, and the specific dependent behavior are described in section 3.3, and the specific
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.4). 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. 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'
skipping to change at page 41, line 15 skipping to change at page 43, line 10
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
[Editor's note: in a future version, these will be split as Normative [Editor's note: in a future version, these will be split as Normative
and Informative.] and Informative.]
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
Levels", BCP 14, RFC 2119, March 1997
2 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- 2 Brunner, M., "Requirements for Signaling Protocols", draft-ietf-
nsis-req-08.txt (work in progress), June 2003 nsis-req-09.txt (work in progress), August 2003
4 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 3 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-01.txt (work in progress), January 2003 draft-ietf-nsis-threats-02.txt (work in progress), June 2003
5 Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile 4 Chaskar, H. (editor), " Requirements of a Quality of Service (QoS)
IP", draft-ietf-nsis-qos-requirements-01.txt (work in progress), Solution for Mobile IP", RFC 3583, September 2003
June 2003
6 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 5 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 6 Manner, J., X. Fu, P. Pan, "Analysis of Existing Quality of
Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txt Service Signaling Protocols", draft-ietf-nsis-signalling-analysis-
(work in progress), February 2003 02.txt (work in progress), June 2003
8 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp- 7 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp-
sec-properties-01.txt (work in progress), March, 2003 sec-properties-02.txt (work in progress), June 2003
9 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security 8 Katz, D., "IP Router Alert Option", RFC2113, February 1997
Considerations", draft-iab-sec-cons-03.txt (work in progress),
January 2003
10 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, 9 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,
October 1999
10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, July 2003
12 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-01.txt (work in progress), March 2003 tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003
11 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
"RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001
12 Hancock, R., E. Hepworth, A. McDonald, "Handling Overload 13 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
Conditions in the NSIS Protocol Suite", draft-hancock-nsis- "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001
overload-00.txt (work in progress), June 2003 14 Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State
and Soft-State Signaling Protocols", Computer Communication
13 Katz, D., "IP Router Alert Option", RFC2113, February 1997 Review, Volume 33, Number 4, October 2003
14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 15 Floyd, S., "Congestion Control Principles", RFC 2914, September
October 1999 2000
15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 16 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 17 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,
1771, March 1995
17 Rekhter, Y. T. Li, S.Hares, "A Border Gateway Protocol 4 (BGP-4)",
draft-ietf-idr-bgp4-20.txt (work in progress), April 2003
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
19 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ 18 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ
Resource Management in IP-based Radio Access Networks", Resource Management in IP-based Radio Access Networks",
Proceedings of 4th International Symposium on Wireless Personal Proceedings of 4th International Symposium on Wireless Personal
Multimedia Communications-WPMC'01, September 9 - 12, 2001 Multimedia Communications-WPMC'01, September 9 - 12, 2001
20 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y. 19 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y.
Khouaja, "Evaluation of Mobility and QoS Interaction", Computer Khouaja, "Evaluation of Mobility and QoS Interaction", Computer
Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163 Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163
21 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt 20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6",
(work in progress), January 2003 draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003
22 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 21 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
23 Kempf, J., "Problem Description: Reasons For Performing Context 22 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
23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999 (NAT) Terminology and Considerations", RFC2663, August 1999
25 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC2765, February 2000 RFC2765, February 2000
26 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 25 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
Traversal of User Datagram Protocol (UDP) Through Network Address Traversal of User Datagram Protocol (UDP) Through Network Address
Translators (NATs)", RFC3489, March 2003 Translators (NATs)", RFC3489, March 2003
26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation
Over IP Tunnels", RFC 2746, January 2000
27 Westberg, L., et al., "Resource Management in Diffserv (RMD) 27 Braden, R., D. Clark, S. Shenker, "Integrated Services in the
Framework", draft-westberg-rmd-framework-03.txt (work in
progress), June 2003
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
29 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 28 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., Szabo, R., Takacs, 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
30 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for 29 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
31 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated 30 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
32 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 31 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and Framework",
33 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.
Schulzrinne, "SIS NAT/FW NSLP: Problem Statement and Framework",
draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003 draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003
34 Aoun, C., "NSIS Network Address Translator implications", draft- 32 Aoun, C., "NSIS Network Address Translator implications", draft-
aoun-nsis-nat-imps-01.txt (work in progress), March 2003 aoun-nsis-nat-imps-01.txt (work in progress), March 2003
Acknowledgments Acknowledgments
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
Hepworth, Melinda Shore and Hannes Tschofenig for significant Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for
contributions in particular areas of this draft. In addition, the significant contributions in particular areas of this draft. In
authors would like to acknowledge Cedric Aoun, Attila Bader, Anders addition, the authors would like to acknowledge Cedric Aoun, Attila
Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
Ruediger Geib, Danny Goderis, Cornelia Kappler, Thanh Tra Luu, Mac Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung
McTiffin, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve,
Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom
Michael Welzl, Lars Westberg, and Lixia Zhang for insights and inputs Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg,
during this and previous framework activities. and Lixia Zhang for insights and inputs during this and previous
framework activities.
Authors' Addresses Authors' Addresses
Ilya Freytsis Robert Hancock (editor)
Cetacean Networks Inc.
100 Arboretum Drive
Portsmouth, NH 03801
USA
email: ifreytsis@cetacean.com
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
Ilya Freytsis
Cetacean Networks Inc.
100 Arboretum Drive
Portsmouth, NH 03801
USA
email: ifreytsis@cetacean.com
Georgios Karagiannis Georgios Karagiannis
University of Twente University of Twente
P.O. BOX 217 P.O. BOX 217
7500 AE Enschede 7500 AE Enschede
The Netherlands The Netherlands
email: g.karagiannis@ewi.utwente.nl email: g.karagiannis@ewi.utwente.nl
John Loughney John Loughney
Nokia Research Center Nokia Research Center
11-13 Italahdenkatu 11-13 Italahdenkatu
skipping to change at page 45, line 29 skipping to change at page 47, line 19
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved. This Copyright (C) The Internet Society (2003). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
 End of changes. 

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