draft-ietf-nsis-fw-01.txt   draft-ietf-nsis-fw-02.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft Robert Hancock (editor) Internet Draft Robert Hancock (editor)
Siemens/Roke Manor Research Siemens/Roke Manor Research
Ilya Freytsis Ilya Freytsis
Cetacean Networks Cetacean Networks
Georgios Karagiannis Georgios Karagiannis
Ericsson Ericsson
John Loughney John Loughney
Nokia Nokia
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Document: draft-ietf-nsis-fw-01.txt Document: draft-ietf-nsis-fw-02.txt
Expires: May 2003 November 2002 Expires: September 2003 March 2003
Next Steps in Signaling: Framework Next Steps in Signaling: Framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
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 1, line 41 skipping to change at page 1, line 41
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The NSIS working group is considering protocols for signaling for The Next Steps in Signaling working group is considering protocols
resources for a traffic flow along its path in the network. The for signaling information about a data flow along its path in the
requirements for such signaling are being developed in [2]; this network. Based on existing work on signaling requirements, this
Internet Draft will propose a framework for such signaling. document proposes an architectural framework for such signaling
protocols.
This initial version provides a model of the entities that take part
in the signaling. It discusses the considerations that must be taken
into account in developing the framework, particularly the options
for the structure of such a protocol, and the interactions between
NSIS and other protocols and functions, including security issues.
Finally, it includes background material on how NSIS could support This document provides a model for the network entities that take
particular signaling applications. part in such signaling, and the relationship between signaling and
the rest of network operation. We decompose the overall signaling
protocol suite into a generic (lower) layer, with a separate upper
layers for each specific signaling application. An initial proposal
for the split between these layers is given, describing the overall
functionality of the lower layer, and discussing the ways that upper
layer behavior can be adapted to specific signaling application
requirements.
It is expected that future versions of this document will distill This framework also considers the general interactions between
these structural options into a concrete technical framework, and signaling and other network layer functions, specifically routing and
material on particular signaling applications and deployment mobility. The different routing and mobility events that impact
scenarios will be moved into separate NSIS applicability statements. signaling operation are described, along with how their handling
should be divided between the generic and application-specific
layers. Finally, an example signaling application (for Quality of
Service) is described in more detail.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3]. document are to be interpreted as described in RFC-2119 [2].
[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 Scope of the NSIS Framework ................................4 1.1 Definition of the NSIS Signaling Problem ...................3
1.2 Scope and Structure of the NSIS Framework ..................4
2. Terminology....................................................5 2. Terminology....................................................5
3. Overall Framework Structure....................................6 3. Overview of Signaling Scenarios and Protocol Structure.........6
3.1 Basic Signaling Entities and Interfaces ....................6 3.1 Fundamental Signaling Concepts .............................6
3.1.1 NSIS Entities ..........................................6 3.1.1 Simple Network and Signaling Topology ..................6
3.1.2 Placement of NSIS Entities .............................8 3.1.2 Signaling to Hosts, Networks and Proxies ...............7
3.1.3 NSIS Protocol Components ...............................9 3.1.3 Signaling Messages and Network Control State ...........9
3.2 Options for Modes of NSIS Operation .......................10 3.1.4 Data Flows and Sessions ...............................10
3.2.1 Path-Coupled and Path-Decoupled Signaling .............10 3.2 Layer Model for the Protocol Suite ........................11
3.2.2 Inter-domain and Intra-domain Signaling ...............11 3.2.1 Layer Model Overview ..................................11
3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge .............12 3.2.2 Layer Split Concept ...................................12
3.2.4 Global and Local Operation ............................12 3.2.3 Core NTLP Functionality ...............................13
3.2.5 Multicast versus Unicast ..............................13 3.2.4 Path De-Coupled Operation .............................14
3.2.6 Sender versus Receiver Initiated Signaling ............13 3.3 Signaling Application Properties ..........................14
3.2.7 Uni-Directional and Bi-Directional Reservations .......14 3.3.1 Sender/Receiver Orientation ...........................15
3.3 Basic Assumptions and Conceptual Issues ...................15 3.3.2 Uni- and Bi-Directional Operation .....................16
3.3.1 Basic Assumptions .....................................15 3.3.3 Heterogeneous Operation ...............................16
3.3.2 NI, NF, NR functionality ..............................15 3.3.4 Peer-Peer and End-End Relationships ...................17
3.3.3 NI, NF, NR relationship ...............................16 3.3.5 Acknowledgements and Notifications ....................17
3.3.4 NSIS Addressing .......................................16 3.3.6 Security and other AAA Issues .........................18
3.3.5 NSIS Layer Boundaries .................................17 3.4 Open Layer Model Issues ...................................19
3.3.6 NSIS Acknowledgement and Notification Semantics .......17 3.4.1 Classical Transport Functionality .....................19
4. Protocol Components...........................................18 3.4.2 State Management ......................................20
4.1 Lower Layer Interfaces ....................................18 4. The NSIS Transport Layer Protocol.............................21
4.2 Upper Layer Services ......................................18 4.1 Internal Protocol Components ..............................21
4.3 Protocol Structure ........................................20 4.2 Addressing ................................................22
4.3.1 Internal Layering .....................................20 4.3 Lower Layer Interfaces ....................................22
4.3.2 Protocol Messages .....................................21 4.4 Upper Layer Services ......................................23
4.4 State Management ..........................................22
4.5 Identity Elements .........................................24 4.5 Identity Elements .........................................24
4.5.1 Flow Identification ...................................24 4.5.1 Flow Identification ...................................24
4.5.2 Reservation Identification ............................24 4.5.2 Session Identification ................................24
4.5.3 NSLP Identification ...................................25 4.5.3 Signaling Application Identification ..................25
5. NSIS Protocol Interactions....................................25 4.6 Security Properties .......................................25
5.1 Resource Management Interactions ..........................25 5. Interactions with Other Protocols.............................26
5.2 IP Routing Interactions ...................................27 5.1 IP Routing Interactions ...................................26
5.2.1 Load Sharing ..........................................27 5.1.1 Load Sharing and Policy-Based Forwarding ..............26
5.2.2 QoS Routing ...........................................28 5.1.2 Route Changes .........................................28
5.2.3 Route pinning .........................................28 5.1.3 Router Redundancy .....................................29
5.2.4 Route Changes .........................................28 5.2 Mobility Interactions .....................................29
5.2.5 Router Redundancy .....................................30 5.2.1 Addressing and Encapsulation ..........................30
5.3 Mobility Interactions .....................................30 5.2.2 Localized Path Repair .................................30
5.3.1 Addressing and Encapsulation ..........................30 5.2.3 Update on the Unchanged Path ..........................31
5.3.2 Localized Path Repair .................................31 5.2.4 Interaction with Mobility Signaling ...................31
5.3.3 Reservation Update on the Unchanged Path ..............32 5.2.5 Interaction with Context Transfer .....................33
5.3.4 Interaction with Mobility Signaling ...................32 5.3 Interactions with NATs ....................................33
5.3.5 Interaction with Fast Handoff Support Protocols .......34 6. Signaling Applications........................................34
5.4 NSIS Interacting with NATs ................................35 6.1 Signaling for Quality of Service ..........................34
6. Security and AAA Considerations...............................36 6.1.1 Protocol Messages .....................................34
6.1 Authentication ............................................36 6.1.2 State Management ......................................35
6.2 Authorization .............................................37 6.1.3 QoS Forwarding ........................................36
6.3 Accounting ................................................38 6.1.4 Route Changes and QoS Reservations ....................36
6.4 End-to-End vs. Peer Relationship Protection ...............39 6.1.5 Resource Management Interactions ......................38
7. NSIS Application Scenarios....................................40 6.2 Other Signaling Applications ..............................39
7.1 NSIS and Existing Resource Signaling Protocols ............40 7. Security Considerations.......................................39
7.2 NSIS Supporting Centralized QoS Resource Management .......41 8. Change History................................................40
7.3 NSIS Supporting Distributed Resource Management ...........43 8.1 Changes from draft-ietf-nsis-fw-01.txt ....................40
7.4 NSIS for Middlebox Signaling ..............................43 References.......................................................41
7.5 Multi-Level NSIS Signaling ................................44 Acknowledgments..................................................44
8. Open Issues...................................................45 Authors' Addresses...............................................44
9. Change History................................................47 Intellectual Property Considerations.............................45
9.1 Changes from draft-ietf-nsis-fw-00.txt ....................47 Full Copyright Statement.........................................46
9.2 Changes from draft-hancock-nsis-fw-00.txt .................47
Acknowledgments..................................................51
Author's Addresses...............................................51
Full Copyright Statement.........................................52
1. Introduction 1. Introduction
NSIS will work on signaling from an end point that follows a path 1.1 Definition of the NSIS Signaling Problem
through the net that is determined by layer 3 routing and is used to
convey information to the devices the signals pass through - the
signaling can, for example, install soft state in the devices it
passes through. A signaling end point could be a device along the
path, which signals for a data flow that passes through it.
The intention is to allow for the NSIS protocol to be deployed in The NSIS working group is considering protocols for signaling
information about a data flow along its path in the network.
It is assumed that the path taken by the data flow is already
determined by network configuration and routing protocols,
independent of the signaling itself; that is, signaling to set up the
routes themselves is not considered. Instead, the signaling simply
interacts with nodes along the data flow path. Additional
simplifications are that the actual signaling messages pass directly
through these nodes themselves; this is 'path-coupled' signaling in
the sense described in [3], and that only unicast data flows are
considered.
The signaling problem in this sense is very similar to that addressed
by RSVP [4]. However, there are two generalizations. Firstly, the
intention is that NSIS designs protocols that can be used in
different parts of the Internet, for different needs, without different parts of the Internet, for different needs, without
requiring a complete end-to-end deployment. requiring a complete end-to-end deployment (in particular, the
signaling protocol messages may not need to run all the way between
the data flow endpoints).
There is no requirement that the per-flow information be QoS related. Secondly, the signaling is intended for more purposes than just QoS
NSIS should only worry about how to do the signaling - what the (resource reservation). The basic mechanism to achieve this
signaling conveys should be opaque to NSIS. This document discusses flexibility is to divide the signaling protocol stack into two
'where' the signaling takes place, with some discussion on 'how' the layers: a generic (lower) layer, and an upper layer specific to each
signaling can be done. signaling application. The scope of NSIS is to define both the
generic protocol, and initially an upper layer suitable for QoS
signaling similar to the corresponding functionality in RSVP. Further
signaling applications may be considered later.
1.1 Scope of the NSIS Framework 1.2 Scope and Structure of the NSIS Framework
The scope of this document will be to provide a framework for where a The underlying requirements for signaling in the context of NSIS are
NSIS protocol can be used and deployed. It is not intended that NSIS defined in [3]; other related requirements can be found in [5] and
will define an over-arching architecture for carrying out resource [6]. This framework does not replace or update these requirements.
management in the Internet, nor is this intended to be used as a Discussions about lessons to be learned from existing signaling and
detailed protocol design document. resource protocols are contained in a separate analysis document [7].
The framework is not about what NSIS should do but how it should do The role of this framework is to explain how NSIS signaling should
it. It is not intended that this places requirements on a future NSIS work within the broader networking context, and how the signaling
protocol, since requirements are already defined in [2]. The document protocols should be structured at the overall level. Therefore, it
discusses important protocol considerations, such as mobility, discusses important protocol considerations, such as routing,
security, and interworking with resource management (in a broad mobility, security, and interactions with network 'resource'
sense). Discussions about lessons to be learned from existing management (in the broadest sense).
signaling and resource protocols are contained in a separate analysis
document [4].
This initial version provides a model of the entities that take part The basic framework for NSIS is given in section 3. Section 3.1
in the signaling. It discusses the considerations that must be taken describes the fundamental elements of NSIS operation in comparison to
into account in developing the framework, particularly the options RSVP; in particular, section 3.1.2 describes more general signaling
for the structure of such a protocol, and the interactions between scenarios, and 3.1.3 defines a broader class of signaling
NSIS and other protocols and functions, including security issues. applications for which the NSIS protocols should be useful. The two-
Finally, it includes background material on how NSIS could support layer protocol architecture that supports this generality is
particular signaling applications. described in section 3.2, and section 3.3 gives examples of the ways
in which particular signaling application properties can be
accommodated within signaling layer protocol behavior.
It is expected that future versions of this document will distill The overall functionality required from the lower (generic) protocol
these structural options into a concrete technical framework, and layer is described in section 4. This is not intended to define the
material on particular signaling applications and deployment protocol detailed design or even design options, although some are
scenarios will be moved into separate NSIS applicability statements. described as examples. The emphasis is on defining the interfaces
between this lower layer protocol and the IP layer and signaling
application protocols, including the identity elements that appear on
these interfaces. Following this, section 5 describes how signaling
applications that use the NSIS protocols can interact sensibly with
network layer operations, specifically routing (and re-routing), IP
mobility, and network address translation.
The purpose of this document is to develop the realms, domains and Section 6 describes particular signaling applications. The example of
modes of operation where an NSIS protocol can be used; identify the signaling for QoS (comparable to core RSVP QoS signaling
relationship of an NSIS protocol to other protocols; and identify functionality) is described in detail in section 6.1, which describes
areas for future work. both the signaling application specific protocol and example modes of
interaction with network resource management and other deployment
aspects. However, note that these examples are included only as
background and for explanation; it is not intended to define an over-
arching architecture for carrying out resource management in the
Internet. Further possible signaling applications are outlined in
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.
Interdomain traffic - Traffic that passes from one NSIS domain to [Data] flow - a stream of packets from sender to receiver which is a
another. distinguishable subset of a packet stream. Each flow is distinguished
by some flow identifier (see section 4.5.1).
NSIS Domain (ND) - Administrative domain where an NSIS protocol Edge node - a (NSIS-capable) node on the boundary of some
signals for a resource or set of resources. administrative domain.
Interior nodes - the set of (NSIS-capable) nodes which form an
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 Forwarder (NF) - NSIS Entity between a NI and NR which may
interact with local resource management function (RMF). It also
propagates NSIS signaling further through the network.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
network resource.
NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well.
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.1.3. 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.1.3. 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. See also messages follow a path that is tied to the data messages.
section 3.2.1.
Path-decoupled signaling - signaling with independent data and Path-decoupled signaling - signaling - signaling for state
signaling paths. manipulation related to data flows, but only loosely coupled to the
data path, e.g. at the AS level.
Peer determination - the act of locating and/or selecting which NSIS Peer discovery - the act of locating and/or selecting which NSIS peer
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.
Resource - something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth
on an interface.
Resource Management Function (RMF) - an abstract concept,
representing the management of resources in a domain or a node.
Sender - the node in the network which is sending the data packets in Sender - the node in the network which is sending the data packets in
a flow. a flow.
Service Level Agreement (SLA) - a service contract between a customer Session - application layer flow of information for which some
and a service provider that specifies the forwarding service a network control state information is to be manipulated or monitored
customer should receive. (see section 4.5.2).
[NSIS] Signaling application - the purpose of the NSIS signaling: a Signaling application - the purpose of the NSIS signaling: a service
service could be QoS management, firewall control, and so on. Totally could be QoS management, firewall control, and so on. Totally
distinct from any specific user application. distinct from any specific user application.
Traffic characteristic - a description of the temporal behavior or a 3. Overview of Signaling Scenarios and Protocol Structure
description of the attributes of a given traffic flow or traffic
aggregate.
Traffic flow - a stream of packets between two end-points that can be 3.1 Fundamental Signaling Concepts
characterized in a certain way.
3. Overall Framework Structure 3.1.1 Simple Network and Signaling Topology
3.1 Basic Signaling Entities and Interfaces The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state
in the network. This state is related to a data flow and is installed
and maintained on the NSIS Entities (NEs) along the data flow path
through the network; not every node has to contain an NE. The basic
protocol concepts do not depend on the signaling application, but the
details of operation and the information carried do. This section
discusses the basic entities involved with signaling as well as
interfaces between them.
3.1.1 NSIS Entities Two NSIS entities that communicate directly are said to be in a 'peer
relationship'. This concept might loosely be described as an 'NSIS
hop'; however, there is no implication that it corresponds to a
single IP hop. Either or both NEs might store some state information
about the other, but there is no assumption that they necessarily
establish a long-term signaling connection between themselves.
The NSIS protocol is intended to be used as a signaling control plane It is common to consider a network as composed of various domains,
for the variety of network resources required for data traffic across e.g. for administrative or routing purposes, and the operation of
the Internet. The most common NSIS signaling applications are QoS signaling protocols may be influenced by these domain boundaries.
resources, firewalls and NATs resources, etc. The NSIS signaling However, it seems there is no reason to expect that an 'NSIS domain'
itself does not depend on the signaling application it is used for should exactly overlap with an IP domain (AS, area) but it is likely
but the information it carries does. This section discusses the basic that its boundaries would consist of boundaries (segments) of one or
signaling entities of the protocol as well as interfaces between several IP domains.
them.
We can identify three different roles in the NSIS signaling for Figure 1 shows a diagram of nearly the simplest possible signaling
resources: initiator, forwarder and responder. 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
two of the routers contain NEs which exchange signaling messages -
possibly in both directions - about the flow. This scenario is
essentially the same as that considered by RSVP for QoS signaling;
the main difference is that we make no assumptions here about the
particular sequence of signaling messages that will be invoked.
The NSIS Initiator (NI) is an entity that initiates NSIS signaling Sender Receiver
(request) for the network resource. The NSIS initiator can be +-----------+ +----+ +----+ +----+ +-----------+
triggered by the different "sources" - user applications, an instance |Application|----->| R1 |----->| R2 |----->| R3 | ---->|Application|
of NSIS Forwarder, other protocols, network management etc. - that | +--+ | |+--+| |+--+| +----+ | +--+ |
need network resources for a data flow. For the purpose of the NSIS | |NE|====|======||NE||======||NE||==================|===|NE| |
discussion all these sources can be called "applications" (note that | +--+ | |+--+| |+--+| | +--+ |
this is entirely distinct from the specific term "signaling +-----------+ +----+ +----+ +-----------+
application"). The NSIS initiator can provide feedback information to
the triggering application in respect to the requested network
resources. The NSIS initiator uses NSIS signaling to interact with
other NSIS entities (NFs and NRs).
The NSIS Forwarder (NF) is an entity that services NSIS resource +--+
requests from NSIS initiators and other NSIS forwarders. It may |NE| = NSIS ==== = Signaling ---> = Data flow messages
interact with local resource management function (RMF). How and if +--+ Entity Messages (unidirectional)
this interaction takes place depends on the deployed resource
management mechanism and the specific role of the NF. The NSIS
forwarder propagates NSIS signaling further through the network.
The NSIS Responder (NR) is an entity that terminates NSIS signaling Figure 1: Simple Signaling and Data Flows
and can optionally interact with local applications as well e.g. for
the purpose of notification when network resources get allocated etc.
The signaling relationship between two NSIS entities (with no other 3.1.2 Signaling to Hosts, Networks and Proxies
NSIS entities between them) is called simply a 'peer relationship'.
This concept might loosely be described as an 'NSIS hop'; however,
there is no implication that it corresponds to a single IP hop.
Either or both NEs might store some state information about the
other, but there is no assumption that they establish a long-term
signaling session between themselves.
Figure 1 depicts simplified interactions/interfaces between NI, NFs There are different possible triggers for the NSIS signaling. Amongst
and NR as well as local applications and RMFs. Note that the NI and them are signaling applications (that are using NSIS signaling
NR could also interact with an RMF; additionally, this could be services), other instances of the signaling, network management
modeled as co-location of NI&NF and NR&NF. This distinction should actions, some network events, and so on. The variety of possible
have no impact on the operation of the protocol. Also, there is no triggers requires that the signaling can be initiated and terminated
bar on placing an NI or NR in the interior of the network, to in the different parts of the network - hosts, domain boundary nodes
initiate and terminate NSIS signaling independently of the ultimate (edge nodes) or interior domain nodes.
endpoints of the end to end flow, and NI and NR do not have to talk
via intervening NFs. An example of NSIS being used in this way is
given in section 7.5.
+-----------+ +-----------+ NSIS extends the RSVP model to consider this wider variety of
|Application| |Application| possible signaling exchanges. As well as the basic end-to-end model
+-----------+ +-----------+ already described, examples such as end-to-edge and edge-to-edge can
^ ^ be considered. The edge-to-edge case might involve the edge nodes
| | communicating directly, as well as via the interior nodes.
| |____________| |____________| |
V | | | | V While end-to-edge (host-to-network) scenario requires only intra-
+----+ +----+ +----+ +----+ domain signaling, the other cases might need inter-domain NSIS
| NI |==========| NF |=====....=====| NF |==========| NR | signaling as well if the signaling endpoints (hosts or network edges)
are connected to different domains. Depending on the trust relation
between concatenated NSIS domains the edge-to-edge scenario might
cover single domain or multiple concatenated NSIS domains. The latter
case assumes the existence of the trust relation between domains.
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
flow, but from the some other entities on the network that can be
called signaling proxies. There could be various reasons for this:
signaling on behalf of the end hosts that are not NSIS-aware,
consolidation of the customer accounting (authentication,
authorization) in respect to consumed application and transport
resources, security considerations, limitation of the physical
connection between host and network and so on. This configuration can
be considered as a kind of "on the data path", see Figure 2.
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|---->| R |-.->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| +----+ | |
+------+ ||NE||=====||NE||=.==||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
^ ^
| |
V V
+----+ +----+
|RMF | | RMF|
+----+ +----+
=========== = NSIS signaling messages +--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
|_________| = Scope of single NSIS Appl = signaling application
| | "peer relationship"
Figure 1: Basic NI/NF/NR Relationships Figure 2: "On path" NSIS proxy
3.1.2 Placement of NSIS Entities This configuration presents a set of specific challenges to the NSIS
signaling:
The NI, NF and NR definitions do not make any assumptions about *) The proxy that terminates signaling on behalf of the NSIS-unaware
placements of NSIS signaling entities in respect to the particular host (or part of the network) should be able to make determination
part of the network or data-forwarding path. that it is a last NSIS aware node along the path.
*) Where a proxy initiates NSIS signaling on behalf of the NSIS
unaware host, interworking with some other "local" technology might
be required, for example to provide QoS reservation from proxy to the
end host in the case of QoS signaling application.
They can be located along the data path (hosts generating and Another possible configuration, shown in Figure 3 is where an NE can
receiving data flows, edge routers, intermediate routers etc.) but it send and receive signaling information off path for and from remote
may not be the only one desirable location. processing. The NSIS protocols may or may not be suitable for this
remote processing 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.
In some cases it is desired to be able to initiate and/or terminate Receiver
NSIS signaling not from the end host that generates/receives the data +------+ +----+ +----+ +----+ +-----------+
flow, but from the some other entities on the network that can be |Sender|----->| PA |----->| R2 |----->| R3 | ---->|Application|
called NSIS signaling application proxies. There could be various | | |+--+| |+--+| +----+ | +--+ |
reasons for this: signaling on behalf of the end hosts that are not +------+ ||NE||======||NE||==================|===|NE| |
enabled with NSIS, consolidation of the customer accounting |+--+| |+--+| | +--+ |
(authentication, authorization) in respect to consumed application +-..-+ +----+ +-----------+
and transport resources, security considerations, limitation of the ..
physical connection between host and network etc. The proxy can ..
communicate the relevant information to the host in the application ..
specific, maybe compressed, form. ..
+-..-+
|Appl|
+----+
Support for NSIS proxies affects the protocol in the following way: Appl = signaling PA = Proxy for signaling
*) The protocol should accommodate signaling with the scope of a application application
single NSIS peer relationship; the signaling could be propagated over
multiple peer relationships all the way toward the destination (end-
to-end).
*) In the particular case where the proxy is not on the data path,
NSIS might have to be extended to allow separated data and signaling
paths, although this analysis is not initially in scope.
Further discussion of these issues is given in sections 3.2.1 and Figure 3: "Off path" NSIS proxy
3.3.3.
As it can be seen from the usage cases presented in the NSIS 3.1.3 Signaling Messages and Network Control State
requirements draft [2] the NSIS signaling procedures may depend on
the part/type of the network where NSIS is used. In fact to satisfy
sometimes-conflicting requirements in [2], different procedures and
possibly different kinds of the NSIS protocol can be used on
different parts/types of the network. Sections 3.2 and 7.5 provide
more details on this topic.
3.1.3 NSIS Protocol Components The distinguishing features of the signaling supported by the NSIS
protocols are that it is related to specific flows (rather than to
network operation in general), and that it involves nodes in the
network (rather than running transparently between the end hosts).
Therefore, each signaling application (upper layer) protocol must
carry per-flow information for the aspects of network-internal
operation corresponding to that signaling application. An example for
the case of an RSVP-like QoS signaling application would be state
data representing resource reservations. However, more generally, the
per-flow information might be related to some other control function
in routers and middleboxes along the path. Indeed, the signaling
might simply be used to gather per-flow information, without
modifying network operation at all.
We call this information generically 'network control state'.
Signaling messages may install, modify, refresh, or simply read this
state from network elements for particular data flows. Usually a
network element will also manage this information at the per-flow
level, although coarser-grained state management is also possible.
3.1.4 Data Flows and Sessions
Formally, a data flow is a (unidirectional) sequence of packets
between the same endpoints which follow a unique path through the
network (determined by IP routing and other network layer
configuration). A flow is defined by a packet classifier (in the
simple cases, just the destination address and topological origin are
needed). In general we assume that when discussing only the data flow
path, we only need to consider 'simple' fixed classifiers (e.g. IPv4
5-tuple or equivalent).
A session is an application layer concept for a (unidirectional) flow
of information between two endpoints, for which some network state is
to be allocated or monitored. (Note that this use of the term
'session' is distinct from the usage in RSVP. It is closer to the
session concept of, for example, the Session Initiation Protocol.)
The simplest service provided by NSIS signaling is network control
state management at the flow level, as described in the previous
subsection. In particular, it is possible to monitor routing updates
as they change the path taken by a flow and, for example, update
network state appropriately. This is 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.
However, for some more complex scenarios (especially mobility-related
ones, see [3] and [8]) it is desirable to update the flow:session
relationship during the session lifetime. For example, a new flow can
be added, and the old one deleted (and maybe in that order, for a
'make-before-break' handover), effectively transferring the network
control state between data flows to keep it associated with the same
session. Such updates can only be managed by the end systems (because
of the packet classifier change). To enable this, it must be possible
for end systems to relate signaling messages to sessions as well as
data flows.
3.2 Layer Model for the Protocol Suite
3.2.1 Layer Model Overview
In order to achieve a modular solution for the NSIS requirements, it In order to achieve a modular solution for the NSIS requirements, it
is proposed to structure what we refer to overall as 'the NSIS is proposed to structure the NSIS protocol suite into 2 layers,
protocol' into 2 layers, similarly to the original proposal in [8]: similar to the original proposal in [9]:
*) a 'signaling transport' layer, responsible for moving signaling *) a 'signaling transport' layer, responsible for moving signaling
messages around, which should be independent of any particular messages around, which should be independent of any particular
signaling application; and signaling application; and
*) a 'signaling application' layer, which contains functionality *) a 'signaling application' layer, which contains functionality
such as message formats and sequences, specific to a particular such as message formats and sequences, specific to a particular
signaling application. signaling application.
For the purpose of this document, we use the term 'NSIS Transport For the purpose of this document, we use the term 'NSIS Transport
Layer Protocol' (NTLP) to refer to the component that will be used in Layer Protocol' (NTLP) to refer to the component that will be used in
the transport layer; it may or may not be based on the use of the transport layer. We also use the term 'NSIS Signaling Layer
existing transport protocols. We also use the term 'NSIS Signaling Protocol' (NSLP) to refer generically to any protocol component
Layer Protocol' (NSLP) to refer generically to any protocol component
within the signaling application layer; in the end, there will be within the signaling application layer; in the end, there will be
several NSLPs. These relationships are illustrated in Figure 2. several NSLPs. These relationships are illustrated in Figure 4. Note
that the NTLP may or may not have an interesting internal structure
(e.g. based on the use of existing transport protocols) but that is
not relevant at this level.
^ +-----------------+ ^ +-----------------+
| | NSIS Signaling | | | NSIS Signaling |
| | Layer Protocol | | | Layer Protocol |
NSIS | +----------------| for middleboxes | NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+ Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling | Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol | | | for QoS | | Layer Protocol |
| | | | for something | | | | | for something |
| +-----------------+ | else | | +-----------------+ | else |
V +-----------------+ V +-----------------+
============================================= =============================================
^ +--------------------------------+ ^ +--------------------------------+
| | NSIS Transport Layer Protocol | NSIS | | |
NSIS | | .................... | Transport | | NSIS Transport Layer Protocol |
Transport | | .Standard transport. | Layer | | |
Layer | | . protocol (maybe) . |
| | .................... |
V +--------------------------------+ V +--------------------------------+
=============================================
+--------------------------------+
| |
. IP and lower layers .
. .
Figure 2: NSIS Protocol Components Figure 4: NSIS Protocol Components
Note that not every generic function has to be located in the NTLP.
The precise boundary between these layers is not defined at this Another option would be to have re-usable components within the
stage; see section 3.3.5 for some initial discussion of this point. signaling application layer. Functionality within the NTLP should be
restricted to that which interacts strongly with other transport and
3.2 Options for Modes of NSIS Operation lower layer operations.
This section discusses several possible modes of NSIS operation. Each
mode of NSIS operation is briefly introduced and where needed
analyzed and compared with the alternatives. It is not assumed that
NSIS will support all the mode variants described in these
subsections; after the tradeoffs described here have been evaluated,
some might be excluded from further consideration.
3.2.1 Path-Coupled and Path-Decoupled Signaling
We can consider two basic paradigms for resource reservation
signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through
nodes (NEs) that are in the data path. They do not have to reach all
the nodes on the data path (for example, there could be proxies
distinct from the sender and receiver as described in section 3.1.2,
or intermediate signaling-unaware nodes); and between adjacent NEs,
the route taken by signaling and data might diverge. The path-coupled
case can be supported by various addressing styles, with messages
either explicitly addressed to the neighbor on-path NE, or routed
identically to the data packets and intercepted. These cases are
considered in section 3.3.4. In the second case, some network
configurations may split the signaling and data paths (see section
5.2); this is considered an error case for path-coupled signaling.
In the path-decoupled case, signaling messages are routed to nodes
(NEs) which are not assumed to be on the data path, but which are
(presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the NI/NR may have no relation at
all with the ultimate data sender or receiver.
There are potentially significant differences in the way that the two Because NSIS problem includes multiple signaling applications, it is
signaling paradigms should be analyzed, for example in terms of very likely that a particular NSLP will only be implemented on a
scaling behavior, failure recovery, security properties, mechanism subset of the NSIS-aware nodes on a path, as shown in Figure 5.
for NSIS peer determination, and so on. These differences might or Messages for unrecognized NSLPs are forwarded at the NTLP level.
might not cause changes in the way that the NSIS protocol operates.
The initial goal of NSIS and this framework is to concentrate mainly +------+ +------+ +------+ +------+
on the path-coupled case. | NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| || | | || || || ||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
3.2.2 Inter-domain and Intra-domain Signaling Figure 5: Signaling with Heterogeneous NSLPs
Inter-domain NSIS signaling is where the NSIS signaling messages are 3.2.2 Layer Split Concept
originated in one NSIS domain and are terminated in another NSIS
domain.
In the path-coupled case, inter-domain NSIS signaling can be used to This section describes the basic concepts which underlie how the
signal NSIS information to the edge nodes of one or more NSIS necessary functionality within the NTLP can be determined. Firstly,
domains. we make a working assumption that the protocol mechanisms of the NTLP
operate only between adjacent NEs (informally, the NTLP is a 'hop-by-
hop' protocol), whereas any larger scope issues (including e2e
aspects) are left to the upper layers.
In the path-decoupled case, inter-domain NSIS signaling can be used The way in which the NTLP works can be described as follows: When a
to signal NSIS information to entities that are not on the data path signaling message is ready to be sent from one NE, it is given to the
(i.e., "out-of-band" NFs), and additionally to signal from off-path NTLP along with information about what flow it is for; it is then up
entities to on-path edge nodes . to the NTLP to get it to the next NE along the path (up- or down-
stream), where it is received and the responsibility of the NTLP
ends. Note that there is no assumption here about how the messages
are actually addressed (this is a protocol design issue, and the
options are outlined in section 4.2). The key point is that the NTLP
for a given NE does not use any knowledge about addresses,
capabilities, or status of any NEs other than its direct peers.
NSIS inter-domain signaling has to fulfill several requirements, such The NTLP in the receiving NE either forwards the message directly,
as: or, if there is an appropriate signaling application locally, passes
*) Basic functionality, such as scalable, simple and fast signaling. it upwards for further processing; the signaling application can then
Because different networks have different resource management generate another message to be sent via the NTLP. In this way, larger
characteristics, such as cost of bandwidth and performance, this scope (including end-to-end) message delivery can be automatically
basic functionality may differ from one NSIS domain to another. achieved.
*) All other requirements specified in [2].
Intra-domain NSIS signaling is where the NSIS signaling messages are This definition relates to NTLP operation. It is not intended to
originated, processed and terminated within the same NSIS domain. restrict the ability of an NSLP to send messages by other means. For
Note that these messages could be handled within a local instance of example, an NE in the middle or end of the signaling path could send
NSIS signaling; another possibility could be to piggyback them on a message directly to the other end as a notification of or
inter-domain NSIS messages. acknowledgement for some signaling application event. However, it
appears that the issues in sending such messages (endpoint discovery,
security, NAT traversal and so on) are so different from the direct
peer-peer case that there is no benefit in extending the scope of the
NTLP to include such non-local functionality; instead, an NSLP which
requires such messages and wants to avoid traversing the path of NEs
should use some other existing transport protocol - for example, UDP
would be a good match for many of the scenarios that have been
proposed. Acknowledgements and notifications of this type are
considered further in section 3.3.5.
Intra-domain signaling can be used to signal NSIS information to the One motivation for restricting the NTLP to only peer-relationship
edge nodes (i.e., routers located at the border of the NSIS domain) scope is that if there are any options or variants in design approach
and to the interior nodes (i.e., routers located within the NSIS - or, worse, in basic functionality - it is easier to manage the
domain that are not edge nodes). resulting complexity if it only impacts direct peers rather than
potentially the whole network.
The NSIS intra-domain signaling approach has to fulfill fewer 3.2.3 Core NTLP Functionality
requirements than inter-domain signaling. These are:
*) Basic functionality, such as scalable, simple and fast signaling.
Due to the fact that different networks have different resource
management characteristics, this basic functionality may differ from
one NSIS domain to another.
*) Provides the necessary functionality to interact between inter-
domain signaling and intra-domain signaling.
3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge This section describes the basic functionality to be supported by the
NTLP. Note that the analysis has to be based on considering NSLP and
NTLP operation jointly; for example, we can always assume that an
NSLP is operating above the NTLP and taking care of end-to-end issues
(e.g. recovery of messages after restarts and so on).
End-to-end: When used end-to-end, the NSIS protocol is initiated by Therefore, NTLP functionality is essentially just efficient upstream
an end host and is terminated by another end host. In this context, and downstream peer-peer message delivery in a wide variety of
NSIS can be applied as needed within all of the NSIS domains between network scenarios. Message delivery includes the act of locating
the end hosts. In the end-to-end path, NSIS may be used both for and/or selecting which NTLP peer to carry out signaling exchanges
intra-domain NSIS signaling, as well as for inter-domain signaling. with for a specific data flow. This discovery might be an active
process (using specific signaling packets) or a passive process (a
side effect of using a particular addressing mode). In addition, it
appears that the NTLP can sensibly carry out most of the functions of
enabling signaling messages to pass through middleboxes, since this
is closely related to the problem of routing the signaling messages
in the first place.
Edge-to-edge: In this scenario the NSIS protocol is initiated by an Two major open issues remain about NTLP functionality, namely what
edge node of a NSIS domain and is terminated by another edge node of classical transport capabilities (congestion avoidance,
the same (or possibly different) NSIS domain. NSIS can be applied retransmission and so on) it should have, or whether these functions
either within one single NSIS domain, which is denoted as edge-to- can be left entirely to the upper layers; and to what extent the NTLP
edge in a single domain, or within a concatenated number of NSIS should provide a common state management service to the signaling
domains, which is denoted as edge-to-edge in a multi-domain. When an applications. These questions are discussed in section 3.4.
appropriate security trust relation exists between two or more
concatenated NSIS domains, these concatenated NSIS domains are
considered, in terms of NSIS, to be a single, larger NSIS domain.
End-to-edge: In this scenario the NSIS protocol is either initiated 3.2.4 Path De-Coupled Operation
by an end host and is terminated by an edge node or is initiated by
an edge node and is terminated by an end host. In the path-coupled
case, the edge node may be a proxy that is located on a boundary node
of a NSIS domain. In the path-decoupled case, the edge node may be a
proxy that is located on an off-path node that controls, or is
associated with, a NSIS domain.
3.2.4 Global and Local Operation Path-decoupled signaling is defined as signaling for state
installation along the data path, without the restriction of passing
only through nodes (NEs) that are located on the data path. Signaling
messages can be routed to NEs off the data path, but which are
(presumably) aware of it. This allows a looser coupling between NEs
and data plane nodes, e.g. at the AS level.
It is likely that the appropriate way to describe the resources NSIS The main advantages of path-decoupled signaling are ease of
is signaling for will vary from one part of the network to another. deployment and support of additional functionality. The ease of
In particular, resource descriptions that are valid for inter-domain deployment comes from a restriction of the number of impacted nodes
links will probably be different from those useful for intra-domain in case of deployment and/or upgrade of an NSLP. It would allow, for
operation (and the latter will differ from one NSIS domain to instance, deploying a solution without upgrading any of the routers
another). in the data plane. Additional functionality that can be supported
includes the use of off-path proxies to support authorization or
accounting architectures.
One way to describe this issue is to consider the resource There are potentially significant differences in the way that the two
description objects carried by NSIS (typically within the signaling signaling paradigms should be analyzed. Using a single centralized
application layer) as divided in globally-understood objects ("global off-path NE may increase the requirements in terms of message
objects") and locally-understood objects ("local objects"). The local handling. This effect, however, is orthogonal to the NSIS charter,
objects are only applicable for intra-domain signaling, while the since path-decoupled signaling is equally applicable to distributed
global objects are mainly used in inter-domain signaling. Note that off-path entities. Failure recovery scenarios need to be analyzed
such local objects are still part of the NSIS protocol, unlike opaque differently because fate-sharing between data and control plane can
data which would be invisible to the protocol; local objects can be no longer be assumed. Furthermore, the interpretation of
inserted, used and removed by one single domain. sender/receiver orientation becomes less obvious. With the local
operation of NTLP, the impact of path-decoupled signaling on the
routing of signaling messages is presumably restricted to the problem
of peer determination. The assumption that the off-path NEs are
loosely tied to the data path suggests, however, that peer
determination can still be based on L3 routing information.
The purpose of this division is to provide additional flexibility in 3.3 Signaling Application Properties
defining the objects carried by the NSIS protocol such that only
those objects that are applicable in a particular setting are used.
An example approach for reflecting the distinction in the signaling
is that local objects could be put into separate local messages that
are initiated and terminated within one single NSIS domain and/or
they could be "stacked" within the NSIS messages that are used for
inter-domain signaling. These possibilities will be considered
further during the protocol design activity.
3.2.5 Multicast versus Unicast It is clear that many signaling applications will require specific
protocol behavior in their NSLP. This section outlines some of the
options for NSLP behavior; further work on selecting from these
options would depend on detailed analysis of the application in
question.
Multicast support, compared to unicast support, would introduce a 3.3.1 Sender/Receiver Orientation
level of complexity into the NSIS protocol mainly related to:
*) complex state maintenance to support dynamic membership changes
in the multicast groups, such as reservation state merging and
maintenance.
*) a state per flow has to be maintained that is used during
backward routing.
3.2.6 Sender versus Receiver Initiated Signaling In some signaling applications, one end of the data flow takes
responsibility for requesting special treatment - such as a resource
reservation - from the network. The appropriate end may depend on the
signaling application, or characteristics of the network deployment.
A sender-initiated approach is when the sender of the data flow A sender-initiated approach is when the sender of the data flow
initiates and maintains the resource reservation used for that flow. requests and maintains the resource reservation used for that flow.
In a receiver-initiated approach the receiver of the data flow In a receiver-initiated approach the receiver of the data flow
initiates and maintains the resource reservation used for the data requests and maintains the resource reservation used for that flow.
flow. The NTLP has no freedom in this area: next peers have to be
discovered in the sender to receiver direction, but after that time
the default assumption is that signaling is possible both upstream
and downstream (unless possibly an application specifically indicates
this is not required). This implies that backward routing state must
be maintained or that backward routing information must be available
in the signaling packet.
In the path-coupled case, and in the absence of NSIS proxies, the The sender and receiver initiated approaches have several differences
following relationships apply: in operational characteristics. The main ones are as follows:
*) in the sender initiated case, the sender of the data is the NSIS
Initiator, while the receiver of the data is the NSIS Responder;
*) in the receiver initiated case, the receiver of the data is the
NSIS Initiator, while the sender of the data is the NSIS Responder.
In the path-decoupled case, the mapping is not necessarily clear cut
(for example, if the NI and NR are not located at the end systems
themselves).
The main differences between the sender-initiated and receiver- *) In a receiver-initiated approach, the signaling messages traveling
initiated approaches are the following: from the receiver to the sender must be backward routed such that
*) Compared with the receiver-initiated approach, a sender using a they follow exactly the same path as was followed by the signaling
sender-initiated approach can be informed faster when the reservation messages belonging to the same flow traveling from the sender to the
request is rejected. In other words, when using a sender-initiated receiver. This implies that a backward routing state per flow must be
approach, the reservation request response time can be shorter in the maintained. When using a sender-initiated approach, provided
case of an unsuccessful reservation than with a receiver-initiated acknowledgements and notifications can be securely delivered to the
approach. sending node, backward routing is not necessary, and nodes do not
*) In a receiver-initiated approach, the signaling messages have to maintain backward routing states.
traveling from the receiver to the sender must be backward routed
such that they follow exactly the same path as was followed by the
signaling messages belonging to the same flow traveling from the
sender to the receiver. This implies that a backward routing state
per flow must be maintained. When using a sender-initiated approach,
provided acknowledgements and notifications can be securely delivered
to the sending node, backward routing is not necessary, and nodes do
not have to maintain backward routing states.
*) In a sender-initiated approach, a mobile node can initiate a *) In a sender-initiated approach, a mobile node can initiate a
reservation for its outgoing flows as soon as it has moved to another reservation for its outgoing flows as soon as it has moved to another
roaming subnetwork. In a receiver-initiated approach, a mobile node roaming subnetwork. In a receiver-initiated approach, a mobile node
has to inform the receiver about its handover procedure, thus has to inform the receiver about its handover procedure, thus
allowing the receiver to initiate a reservation for these flows. allowing the receiver to initiate a reservation for these flows. For
incoming flows, the reverse argument applies.
*) A sender- (receiver-) initiated approach will allow faster setup
and modification if the sender (receiver) is also authorized to carry
out the operation. A mismatch between authorizing and initiating NEs
will cause additional message exchanges either in the NSLP or in a
protocol executed prior to NSIS invocation. 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
about reservation failures than the remote end.
3.2.7 Uni-Directional and Bi-Directional Reservations 3.3.2 Uni- and Bi-Directional Operation
It is possible that a resource will only be required for one
direction of traffic, for example for a media stream with no feedback
channel. Reservations for both directions of traffic may be required
for other applications, for example a voice call. Therefore, the NSIS
signaling protocol must allow for both uni- and bi-directional
resource reservations.
The most basic method for bi-directional reservations is based on
combining two uni-directional reservations. This allows that the
signaling messages for one direction of the bi-directional
reservation are able to follow a different path from messages
traveling in the opposite direction, which is necessary for path-
coupled signaling in the presence of asymmetric routing. (Other more
integrated approaches may be possible in constrained network
topologies where parts of the route are symmetric.) The bi-
directional reservations can, for example, be used to make the NSIS
signaling procedure required after a handover procedure more
efficient.
3.3 Basic Assumptions and Conceptual Issues
3.3.1 Basic Assumptions
The following assumptions have been made during prior NSIS
requirements work and initial framework discussions. They are
summarized here for completeness. The subsequent subsections describe
more generic conceptual assumptions and issues. Note that a complete
overview of current open issues is contained in section 8.
*) The solution developed by NSIS must be sufficiently flexible and
modular that it can be efficiently deployed and used with
functionality appropriate to the part/type of the network. (Sections
3.2.2 and 3.2.3.)
*) The protocol developed by the NSIS working group will be path-
coupled. Considerations related to a potential path-decoupled
solution are part of this framework, because they are also needed in
order to co-exist with existing solutions; however, the NSIS working
group currently has no plans to develop path-decoupled signaling
protocol. (Section 3.2.1.)
*) End-to-end message routing will be achieved by each NE
determining the next appropriate NSIS peer, based on the flow in
question and information within the NTLP layer, not requiring any
node or the upper layers to acquire end-to-end topology information.
(Section 3.2.4.)
*) Multicast support introduces a level of complexity into the NSIS
protocol that is not needed in support of unicast applications.
Therefore, a working assumption is be that the NSIS protocol should
be optimized for unicast. (Section 3.2.5.)
*) The NSIS protocol can be used for setup of both uni-directional For some signaling applications and scenarios, signaling may only be
and bi-directional reservations. (Section 3.2.7.) considered for one direction of the data flow. However, in other
cases, there may be interesting relationships between the signaling
for the two directions; an example is QoS for a voice call. In the
basic case, bi-directional signaling can simply use a separate
instance of the same signaling mechanism in each direction. Note that
the path in the two directions may differ due to asymmetric routing.
3.3.2 NI, NF, NR functionality In constrained topologies where parts of the route are symmetric, it
may be possible to use a more unified approach to bi-directional
signaling, e.g. carrying the two signaling directions in common
messages. This optimization might be used for example to make mobile
QoS signaling more efficient.
The basic functions that can be fulfilled by an NSIS entity are In either case, the correlation of the signaling for the two flow
request, accept, notify, modify and release of a reservation. At this directions is carried out in the NSLP. The NTLP would simply be
point, it is not clear which responsibilities can be assumed by each enabled to bundle the messages together.
of the NSIS entities. More in particular, it is not clear whether:
*) an NF can request, modify or release a reservation. If it cannot,
it needs to notify the NI in order to perform these functions.
*) an NR can modify and release a reservation. Even if the NR can
reject or accept the reservation with modification, it might still be
required to notify the NI to signal the release or modification.
3.3.3 NI, NF, NR relationship 3.3.3 Heterogeneous Operation
An important open issue is related to the way in which NSIS entities It is likely that the appropriate way to describe the state NSIS is
maintain relations between each other. These relations could be signaling for will vary from one part of the network to another
purely local, where an NSIS entity only maintains relations with its (depending on signaling application). For example in the QoS case,
direct neighbors (peers). In that case, messages will be sent to and resource descriptions that are valid for inter-domain links will
accepted from these neighbors only. Alternatively, the relations probably be different from those useful for intra-domain operation
between NSIS entities could have a more global scope. (and the latter will differ from one NSIS domain to another).
The type of NSIS peering relations may have an impact on the One way to address this issue is to consider the state description
complexity involved with protocol security. In case of inter-domain carried within the NSLP as divided in globally-understood objects
signaling, the security relations are likely to be built between ("global objects") and locally-understood objects ("local objects").
neighboring NSIS entities only for scalability reasons. In that case, The local objects are only applicable for intra-domain signaling,
each NSIS entity will establish and maintain a security relation with while the global objects are mainly used in inter-domain signaling.
each of its peers and accept only messages from these peers. Note that such local objects are still part of the NSIS protocol and
can be inserted, used and removed by one single domain.
Conversely, there may exist larger domains of NSIS entities that have The purpose of this division is to provide additional flexibility in
a trust relationship (trusted domains). This may be the case for defining the objects carried by the NSLP such that only those objects
intra-domain signaling. In this case, an NE may accept messages from that are applicable in a particular setting are used. An example
all other NSIS entities in the domain. Both alternatives need not be approach for reflecting the distinction in the signaling is that
mutually exclusive. It is conceivable that different instances of the local objects could be put into separate local messages that are
NSIS protocol (or different NSIS protocols) use the NSIS security initiated and terminated within one single NSIS domain and/or they
model to a larger or lesser extent, provided that overall security is could be "stacked" within the NSLP messages that are used for inter-
not impacted. An analysis of NSIS threats is available from [5]. domain signaling.
The NSIS peering relations may also have an impact on the required 3.3.4 Peer-Peer and End-End Relationships
amount of state at each NSIS entity. When direct interaction with
remote NSIS peers is not allowed, it may be required to keep track of
the path that an NSIS message has followed through the network. This
can be achieved by keeping per-flow state at the NSIS entities or by
maintaining a record route object in the NSIS messages.
An initial working assumption is that the NTLP will operate The assumption taken in this framework is that the NTLP will operate
'locally', that is, just over the scope of a single peer 'locally', that is, just over the scope of a single peer
relationship. End-to-end operation is built up by simply relationship. End-to-end operation is built up by simply
concatenating these relationships. Any non-local operation (if any) concatenating these relationships. Any non-local operation (if any)
will take place only in particular NSLPs. will take place only in particular NSLPs.
3.3.4 NSIS Addressing The peering relations may also have an impact on the required amount
of state at each NSIS entity. When direct interaction with remote
peers is not allowed, it may be required to keep track of the path
that a message has followed through the network. This can be achieved
by keeping per-flow state at the NSIS entities or by maintaining a
record route object in the messages.
The are potentially two ways to establish a signaling connection by Note that, for the reasons discussed in section 3.2.1, NSLP peers are
means of the NSIS protocol. On the one hand, the NSIS message could not inevitably NTLP peers. This has a number of implications for the
be addressed to a neighboring NSIS entity (NE) that is known to be relationship between the signaling layers, in that NSLP peers may
closer to the destination NE. On the other hand, the NSIS message depend on the service provided by a concatenation of NTLP peer
could be addressed to the destination directly, and intercepted by an relationships rather than a single one, which makes it harder to
intervening NE. We denote the latter approach as end-to-end exploit fully some NTLP properties (e.g. channel security,
addressing and the former as peer-peer addressing. reliability).
With peer-peer addressing, an NE will determine the address of the 3.3.5 Acknowledgements and Notifications
next NE based on the payload of the NSIS message (and potentially
also on the previous NE). This requires the address of the
destination NE to be derivable from information present in the
payload. This can be achieved through the availability of a local
routing table or through participation in the routing protocol. Peer-
peer addressing inherently supports tunneling of NSIS signaling
messages between NEs, and is equally applicable to the path-coupled
and path-decoupled cases.
In case of end-to-end addressing, the NSIS message will be sent with We are assuming that the NTLP provides a simple message transfer
the address of the NR, which then necessarily needs to be on the data service, and any acknowledgements or notifications it generates are
path. This requires (some of) the data-path entities to be upgraded handled purely internally (and apply within the scope of a single
(NSIS-aware) in order to be able to intercept the NSIS messages. The peer relationship).
routing of the NSIS signaling should follow exactly the same path as
the data flow for which the reservation is requested.
3.3.5 NSIS Layer Boundaries However, we expect that some signaling applications will requires
acknowledgements regarding the failure/success of state installation
along the data path, and this will be an NSLP function.
The detailed boundary between the NTLP and NSLPs is an area for Acknowledgements can be sent along the sequence of NTLP peer
(considerable) further analysis. In particular, it is not clear how relationships towards the signaling initiator, which relieves the
the key issues described earlier (such as sender/receiver requirements on the security associations that need to be maintained
orientation) are allocated to the different layers. However, some by NEs and can ensure NAT traversal in both directions. (If this
initial assumptions have been made about the functionality in direction is towards the flow sender, it implies maintaining reverse
different layers. routing state in the NTLP). In certain circumstances (e.g. trusted
domains), an optimization can be made by sending acknowledgements
directly to the signaling initiator (see section 3.2.2).
*) It is assumed that some flow description information is part of The semantics of the acknowledgement messages are of particular
the NTLP (see section 4.3.1 and 4.5.1). This might be needed by importance. An NE sending a message could assume responsibility for
signaling application unaware entities located at address boundaries. the entire downstream chain of NEs, indicating for instance the
It is not clear to which level of complexity the flow description availability of reserved resources for the entire downstream path.
needs to be available at this level. Alternatively, the message could have a more local meaning,
*) It is not assumed that the operation of an NSLP is totally indicating for instance that a certain failure or degradation
independent of the NTLP; for example, the appropriate interpretation occurred at a particular point in the network.
of an NSLP message might depend on the local status of the NTLP.
3.3.6 NSIS Acknowledgement and Notification Semantics Notifications differ from acknowledgements because they are not
(necessarily) generated in response to other signaling messages. This
means that it may not be obvious to determine where the notification
should be sent. Other than that, the same considerations apply as for
acknowledgements. One useful distinction to make would be to
differentiate between notifications that trigger a signaling action
and others that don't. The security requirements for the latter are
less stringent, which means they could be sent directly to the NE
they are destined for (provided this NE can be determined).
The semantics of the acknowledgement and notification messages are of 3.3.6 Security and other AAA Issues
particular importance. An NE sending a message can assume
responsibility for the entire downstream chain of NEs, indicating for
instance the availability of reserved resources for the entire
downstream path. Alternatively, the message could have a more local
meaning, indicating for instance that a certain failure or
degradation occurred at a particular NSIS entity.
4. Protocol Components In some cases it will be possible to achieve the necessary level of
signaling security by using basic 'channel security' mechanisms [10]
at the level of the NTLP, and the possibilities are described in
section 4.6. In other cases, signaling applications may have specific
security requirements, in which case they are free to invoke their
own authentication and key exchange mechanisms and apply 'object
security' to specific fields within the NSLP messages.
4.1 Lower Layer Interfaces In addition to authentication, authorisation (to manipulate network
control state) has to be considered as functionality above the NTLP
level, since it will be entirely application specific. Indeed,
authorisation decisions may be handed off to a third party in the
protocol (e.g. for QoS, the resource management function as described
in section 6.1.5). Many different authorisation models are possible,
and the variations impact
*) what message flows take place - for example, whether authorisation
information is carried along with a control state modification
request, or is sent in the reverse direction in response to it;
*) what administrative relationships are required - for example,
whether authorisation takes place only between peer signaling
applications, or over longer distances.
Within a signaling entity, NSIS interacts with the 'lower layers' of Because the NTLP operates only between adjacent peers, and places no
the protocol stack for two nearly independent purposes: sending and constraints on the direction or order in which signaling applications
receiving signaling messages; and configuring the operation of the can send messages, these authorisation aspects are left open to be
lower layers themselves. defined by each NSLP. Further background discussion of this issue is
contained in [11].
For sending and receiving messages, this framework places the lower 3.4 Open Layer Model Issues
boundary of the NTLP at the IP layer. (It is possible that NSIS could
use a standard transport protocol above the IP layer to provide some
of its functionality; this is discussed in section 4.3.1.) The
interface with the lower layers is therefore very simple:
*) The NTLP sends raw IP packets
*) The NTLP receives raw IP packets. In the case of peer-peer
addressing, they have been addressed directly to it. In the case of
end-to-end addressing, this will be by intercepting packets that have
been marked in some special way (by special protocol number or by
some option interpreted within the IP layer, such as the Router Alert
option [6] and [7].)
For correct message routing, the NTLP needs to have some information 3.4.1 Classical Transport Functionality
about the link and IP layer configuration of the local networking
stack. For example, it needs to know:
*) [in general] how to select the outgoing interface for a signaling
message, in case this needs to match the interface that will be used
by the corresponding flow. This might be as simple as just allowing
the IP layer to handle the message using its own routing table.
*) [in the case of IPv6] what address scopes are associated with the
interfaces that messages are sent and received on (to interpret
scoped addresses in flow identification, if these are to be allowed).
The way in which the lower layers are actually configured to handle The first major issue is the extent to which the NTLP should include
the flow depends on the particular NSIS signaling application; for 'traditional' transport like functions, or whether these should be
example, if NSIS is being used for QoS signaling, this might involve seen as either fundamentally unnecessary or automatically handled by
configuration of traffic classification and conditioning parameters, the upper layers. The following functions have been identified as
for example local packet queues, type of filters, type of scheduling, candidates:
and so on. However, none of this is directly related to the NTLP or
indeed any NSLP; therefore, this interaction is handled indirectly
via a resource management function, as described in section 5.1.
4.2 Upper Layer Services 1. Local retransmission to improve reliability. The argument in favor
is that the NTLP can recover from congestive loss or corruption much
more rapidly than end-to-end (NSLP) mechanisms; the argument against
is that the additional complexity in the NTLP is not needed for all
signaling applications. (It's assumed that the NTLP is not actually
providing perfect message delivery guarantees or notifications, for
example because NSLP peers may be separated by more than one NTLP
peer relationship. A signaling application that needs peer-peer
acknowledgements of this nature should define them within the NSLP.)
In-order message delivery and duplicate detection are related
functions.
The combination of the NTLP and an NSLP provides a signaling service, 2. Congestion control. Here, the question is whether the NTLP should
appropriate for a particular signaling application. We can describe include a common mechanism which protects the local portion of the
such a signaling service as an abstract set of capabilities, provided network from overload, or whether this can be derived from the
at a service interface, defined from three perspectives: behavior of each signaling application.
*) What basic control primitives are available at the interface; 3. Message fragmentation. For NSLPs that generate large messages, it
*) What information is exchanged within these primitives; will be necessary to fragment and re-assemble them efficiently within
*) What assumptions are made about operations carried out above the the network, where the use IP fragmentation may lead to reduced
interface. reliability and be incompatible with some addressing schemes. (It's
assumed that the counterpart functionality, of bundling small
messages together, can be provided locally by the NTLP as an option
if desired; it doesn't affect the operation of the network
elsewhere.)
The set of control primitives required is quite small. 4. Flow control. Here, the question is how a receiving NSLP should be
At the initiating (NI) end: protected from overload - whether the NTLP should provide a flow
*) Signaling application requests signaling for a new resource; controlled channel, or whether this should be managed using
*) Signaling application requests modification or removal of an application layer acknowledgements, for example.
existing resource.
*) Signaling application receives progress indications (minimally,
success or failure).
At the responding (NR) end:
*) Notification to signaling application that a resource has been
set up.
At either end:
*) Notification to signaling application that something has changed
about the available resource and other error conditions.
This description is in terms of a 'hard state' interface, without It appears that all these issues don't affect the basic way in which
explicit refresh messages between the signaling application and NSIS, the NSLP/NTLP layers relate to each other (e.g. in terms of the
although this is an implementation issue. In any case, semantics of the inter-layer interaction); it is much more a question
implementations will need to be able to detect conditions when of the overall performance/complexity tradeoff implied by placing
instances of signaling applications fail without issuing explicit certain functions within each layer.
resource removal requests.
The information in the control primitives consists essentially of two 3.4.2 State Management
parts. The first is the definition of the data flow for which the
resource is being signaled. The format (e.g. socket id or packet
fields or whatever) is an implementation issue; it has to be
interpreted into a 'wire format' (as in section 4.5). Since NSIS
could support both sender and receiver initiation, the flow
definition must also state whether it is incoming or outgoing over a
particular interface (this can be inferred when the initiator is
colocated with the flow endpoint). The second part of the information
exchanged is the service definition (e.g. QoS description in the case
of a QoS request). This will be opaque at least to the NTLP, which
only knows the specific NSLP being used.
We have a basic design goal not to duplicate functionality that is It is clear that the NTLP may have to manage some per-flow state to
already present in (or most naturally part of) existing signaling carry out its message delivery functions (for example, state about
protocols which could be used by the upper layers. Therefore NSIS the reverse route for signaling messages, or state needed for route
(implicitly) assumes that certain procedures are carried out change detection). How this state is stored and managed is an
'externally'. The main aspects of this are: internal matter for the NTLP (see section 4), and the details (in
*) Negotiation of service configuration (e.g. discovering what particular, any connection model it might use) is in any case
services are available to be requested); entirely invisible to the signaling applications.
*) Agreement to use NSIS for signaling, and coordination of which
end will be the initiator.
In addition, as well as NSIS (presumably the NTLP) providing a However, signaling applications are frequently managing network
'native' capability to determine the peer to carry out signaling control state for their own purposes, and it is an open issue how
with, it is possible that this information could be provided from much the NTLP should provide a common service to do this for them.
some external source (which might be helpful in some access
scenarios, or in the path-decoupled case). See also the security
discussion in section 6.
Actually providing these functions might require enhancements to The simplest case is that the NTLP simply delivers messages, and any
these other protocols. These are still to be identified. state-related aspects (lifetimes, message semantics and so on) are
entirely invisible to it, being part of the signaling application
data. This provides the simplest interface between NTLP and NSLP.
4.3 Protocol Structure The other extreme is where the NTLP provides a complete state
management service, including explicit commands for creation,
modification and deletion of state with known lifetimes in remote
nodes. This service could make it easy to write new signaling
applications, at the cost of increasing the complexity of the
NTLP/NSLP interface; in particular, there would be many more events
and error conditions to generate within the NTLP, and there may be
several different types of state management semantics required by
different signaling applications. The commonality with other parts of
NTLP functionality is not clear.
4.3.1 Internal Layering An intermediate case is where there is particular support for the
refresh messages used for soft-state maintenance. The characteristics
of these messages are that they can be sent and processed without
invoking signaling application specific logic, and that their timing
can be manipulated to fit in with other NTLP requirements (e.g.
jittering to avoid network synchronization, or to allow bundling with
other messages). Therefore, provided this functionality can be
defined simply and universally, there may be benefits in supporting
it within the NTLP itself. The implication would be that some NTLP
messages contain timing and other control information (to allow the
refresh to be handled correctly at intermediate NSLP-unaware nodes).
In addition, the automatic generation and reception of refreshes
could be handled above or below the NSLP/NTLP boundary (this seems to
be mainly an API issue).
We can model NSIS in two layers, as shown in Figure 3. This is 4. The NSIS Transport Layer Protocol
initially just a way of grouping associated functionality, and does
not mean that all these layers could necessarily operate or even be
implemented independently.
.................................. This section describes the overall functionality required from the
. Signaling Application . NTLP. It mentions possible protocol components within the NTLP layer
. (section 4.2) . and the different possible addressing modes that can be utilized.
. . The interfaces between NTLP and the layers above and below it are
+--------------------------------+ identified, with a description of the identity elements that appear
| NSIS Signaling Layer Protocol | on these interfaces.
| (for some specific signaling |
| application) |
| |
+--------------------------------+
| NSIS Transport Layer Protocol |
| .................... |
| .Standard transport. |
| . protocol (maybe) . |
| .................... |
+--------------------------------+
. Interface to IP layer .
. (section 4.1) .
. .
..................................
Figure 3: NSIS Layer Structure It is not the intention of this discussion to design the NTLP or even
to discuss design options, although some are described as examples.
The goal is to provide a general discussion of required functionality
and to highlight some of the issues associated with this.
The lower layer interface (to IP) has been described in section 4.1. 4.1 Internal Protocol Components
The support of the signaling application is as described in section
4.2. The degree of independence between the NTLP and NSLP is unclear
and might depend on the particular signaling application. To make the
NTLP independent of the signaling application, we must allow that
NSLPs could be explicitly dependent on the layer below. This is
similar to the ALSP/CSTP coupling described in [8].
The distinction between the NTLP and any 'Standard Transport The NTLP includes all functionality below the signaling application
Protocol' is not functionally clear cut, but one of convenience. In layer and above the IP layer. The functionality that is required
outline: within the NTLP is described in section 3.2.
*) The 'standard' protocol could provide (at most) functionality
which might be available from existing protocols, such as SCTP [9] or
IPSec [10]. An extreme case could be the binding update messages of
mobility signaling (section 5.3.4).
*) The NTLP provides (at least) functionality which is somehow
specific to path-coupled signaling.
Functionality reasonable to re-use from existing protocols might Some NTLP functionality could be provided via components existing as
include reliability and re-ordering protection, dead peer detection sublayers within the NTLP design. For example, if specific transport
(keepalive), multihoming support, payload multiplexing capabilities are required, such as congestion avoidance,
(piggybacking), and security services, such as establishment of retransmission, security and so on, then existing protocols, such as
security contexts and carrying out key exchange. TCP or TLS, could be incorporated into the NTLP. This possibility is
not required or excluded by this framework.
Functionality which would probably have to be in the NTLP would ==================== ===========================
include flow and reservation identification, some error handling, ^ +------------------+ +-------------------------+
demultiplexing between different NSLPs, as well as possibly the basic | | | | NSIS Specific Functions |
NSIS messages. More details on the messages are in section 4.3.2 and | | | | .............|
the identifier aspects in section 4.5. NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
The choice of using functionality from an existing protocol or re- Figure 6: Options for NTLP Structure
specifying it as part of the NTLP is for further analysis. It
probably depends on the function in question, and in the end might be
left flexible to allow optimization to local circumstances. (For
example, Diameter allows the use of IPSec for security services, but
also includes its own CMS application as an alternative.) Whichever
approach is taken, the combination of NTLP and supporting transport
protocol must provide a uniform protocol capability to the NSLPs
which support the actual signaling applications.
4.3.2 Protocol Messages If peer-peer addressing (section 4.2) is used for some messages, then
active next-peer discovery functionality will be required within the
NTLP to support the explicit addressing of these messages. (This
could use message exchanges for dynamic peer discovery as a sublayer
within the NTLP; there could also be an interface to external
mechanisms to carry out this function.)
The NSIS protocols will include a set of messages to carry out 4.2 Addressing
particular operations along the signaling path. Initial work for RSVP
concentrated on the particular case of QoS signaling, although the
implication of the analysis in [8] is that this message set
generalizes to a wide variety of signaling applications and so we use
it as a starting point. (A very similar set of messages was generated
in [11].) However, in principle, the necessary basic messages could
depend on the signaling application that NSIS is being used for,
which means that we are not specific here about whether these
messages are visible within the NTLP or only NSLP.
Note that the 'direction' column in the table below only indicates There are two ways to address a signaling message being transmitted
the 'orientation' of the message. The messages can be originated and between NSIS peers:
absorbed at NF nodes as well as the NI or NR; an example might be NFs *) peer-peer, where the message is addressed to a neighboring NSIS
at the edge of a domain exchanging NSIS messages to set up resources entity that is known to be closer to the destination NE.
for a flow across a it. *) end-to-end, where the message is addressed to the destination
directly, and intercepted by an intervening NE.
Note the working assumption that responder as well as the initiator With peer-peer addressing, an NE will determine that address of the
can release a reservation (comparable to rejecting it in the first next NE based on the payload of the message (and potentially on the
place). It is left open if the responder can modify a reservation, previous NE). This requires the address of the destination NE to be
during or after setup. This seems mainly a matter of assumptions derivable from the information present in the payload. This can be
about authorization, and the possibilities might depend on resource achieved through the availability of a local routing table or through
type specifics. participation in active peer discovery message exchanges. Peer-peer
addressing inherently supports tunneling of messages between NEs, and
is equally applicable to the path-coupled and path-decoupled cases.
+-------+---------+---------------------------------------------+ In the case of end-to-end addressing, the message is addressed to the
| Name |Direction| Semantics | data flow receiver, and (some of) the NEs along the data path
+-------+---------+---------------------------------------------+ intercept the messages. The routing of the messages should follow
|Request| I-->R | Create a new reservation for a flow | 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
|Modify | I-->R | Modify an existing reservation | raises some interesting security issues (these are discussed in
| |(&R-->I?)| | [12]).
+-------+---------+---------------------------------------------+
|Release| I-->R & | Delete (tear down) an existing reservation |
| | R-->I | |
+-------+---------+---------------------------------------------+
|Accept/| R-->I | Confirm (possibly modified?) or reject a |
| Reject| | reservation request |
+-------+---------+---------------------------------------------+
|Notify | I-->R & | Report an event detected within the |
| | R-->I | network (e.g. congestion condition or end |
| | | of condition) |
+-------+---------+---------------------------------------------+
|Refresh| I-->R | State management (see section 4.4) |
+-------+---------+---------------------------------------------+
The table also explicitly includes a refresh message. This does It is not possible at this stage to mandate one addressing mode or
nothing to a reservation except extend its lifetime, and is one the other. Indeed, each is necessary for some aspects of NTLP
possible state management mechanism for NSIS. This is considered in operation: in particular, initial discovery of the next downstream
more detail in section 4.4. peer will usually require end-to-end addressing, whereas reverse
routing will always require peer-peer addressing. For other message
types, the choice is a matter of protocol design. The mode used is
not visible to the NSLP, and the information needed in each case is
available from the flow identifier (section 4.5.1) or locally stored
NTLP state.
4.4 State Management 4.3 Lower Layer Interfaces
The prime purpose of NSIS is to manage state information along the The NTLP interacts with 'lower layers' of the protocol stack for the
path taken by a data flow. There two critical issues to be considered purposes of sending and receiving signaling messages. This framework
in building a robust protocol to handle this problem: places the lower boundary of the NTLP at the IP layer. The interface
*) The protocol must be scalable. It should minimize the state to the lower layer is therefore very simple:
storage demands that it makes on intermediate nodes; in particular, *) The NTLP sends raw IP packets
storage of state per 'micro' flow is likely to be impossible except *) The NTLP receives raw IP packets. In the case of peer-peer
at the very edge of the network. addressing, they have been addressed directly to it. In the case of
end-to-end addressing, this will be achieved by intercepting packets
that have been marked in some special way (by special protocol number
or by some option interpreted within the IP layer, such as the Router
Alert option [13] and [14]).
*) The NTLP receives indications from the IP layer regarding route
changes and similar events (see section 5.1).
*) The protocol must be robust against failure and other conditions, For correct message routing, the NTLP needs to have some information
which imply that the stored state has to be moved or removed. about link and IP layer configuration of the local networking stack.
For example, it needs to know:
*) [in general] how to select the outgoing interface for a signaling
message, in case this needs to match the interface that will be used
by the corresponding flow. This might be as simple as just allowing
the IP layer to handle the message using its own routing table. There
is no intention to do something different from IP routing (for end-
to-end addressed messages); however, some hosts allow applications to
bypass routing for their data flows, and the NTLP processing must
account for this.
*) [in the case of IPv6] what address scopes are associated with the
interface that messages are sent and received on (to interpret scoped
addresses in flow identification, if these are to be allowed).
The total amount of state that has to be stored depends both on NSIS Configuration of lower layer operation to handle flows in particular
and on the specific signaling application in use. The signaling ways is handled by the signaling application.
application might require per flow or lower granularity state;
examples of each for the case of QoS would be IntServ or RMD (per
'class' state) respectively. The NSIS protocol should not overburden
an application that was otherwise lightweight in state requirement.
However, depending on design details, it might require storage of
per-flow state including reverse path peer addressing, simply for
sending NSIS messages themselves.
There are several robustness problems, which roughly align with the 4.4 Upper Layer Services
'layers' of the NSIS protocols of Figure 3, that can be handled by
the soft state principle. (Independence of these layers therefore
implies the danger of duplication of functionality.) This relies on
periodic refresh of the state information with the current context,
relying on invalid state being timed out. Soft state can be used
either as the primary mechanism to handle the problem, or sometimes
as a backup to some other approach.
*) At the lowest level, soft state can be used to detect dead NSIS The NTLP offers transport layer services to higher layer signaling
peers - loss of several periodic messages implies termination of the applications for two purposes: sending and receiving signaling
signaling. (The same inference can be made e.g. if failure is messages, and exchanging control and feedback information.
detected at the link layer.) The assumption is then that the
corresponding reservation should be automatically deleted, and the
deletion propagated along the remainder of the path.
*) At the next level, in the event of a routing change (for example For sending and receiving messages, two basic control primitives are
caused by network changes or end host mobility), reservation state required:
should be removed from the old path and added to the new one. This *) Send Message, to allow the signaling application to pass data to
will be handled automatically by periodic messaging, provided that the NTLP for transport.
the entities on the new path accept a Refresh message to install a *) Receive Message, to allow the NTLP to pass received data to the
new reservation. (A partial alternative is to have a routing-aware signaling application.
NSIS implementation, if the route change takes place at an NSIS-aware
node.)
*) At the highest level, a particular signaling application might The NTLP and signaling application may also want to exchange other
have timing limits associated with a particular reservation (e.g. control information, such as:
credit limited network access). Periodic re-authorized requests can *) Signaling application registration/de-registration, so that
be used as part of the time control. particular signaling application instances can register their
presence with the transport layer. This may also require some
identifier to be agreed between the NTLP and signaling application to
allow support the exchange of further control information and to
allow the de-multiplexing of incoming data.
*) NTLP configuration, allowing signaling applications to indicate
what optional NTLP features they want to use, and to configure NTLP
operation, such as controlling what transport layer state should be
maintained.
All of these can be handled with a single soft state mechanism, *) Error messages, to allow the NTLP to indicate error conditions to
although it may be hard to choose a single refresh interval and the signaling application and vice versa.
message loss threshold appropriate for all of them. Even where *) Feedback information, such as route change indications so that
alternative approaches are possible, for example using knowledge of the signaling application can decide what action to take.
the fact that a routing change has occurred to trigger an explicit
release message, it seems that a soft state mechanism is always
necessary as a backup.
4.5 Identity Elements The exact form of the primitives used across this interface and the
information exchanged by them depends on a decision about what the
responsibility of the layers is either side of the interface, and
where state is managed (see section 3.4.2).
NSIS will carry certain identifiers within the NTLP. The most 4.5 Identity Elements
significant identifier needs seem to be the following.
4.5.1 Flow Identification 4.5.1 Flow Identification
The flow identification is a method of identifying a flow in a unique The flow identification is a method of identifying a flow in a unique
way. All packets and/or messages that are associated with the same way. All packets associated with the same flow will be identified by
flow will be identified by the same flow identifier. In principle, it the same flow identifier. The key aspect of the flow identifier is
could be a combination of the following information (note that this to provide enough information such that the signaling flow receives
is not an exclusive list of information that could be used for flow the same treatment along the data path as that actual data itself,
identification): i.e. consistent behavior is applied to the signaling and data flows
by a NAT or policy-based forwarding engine.
Information that could be used in flow identification may include:
*) 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 traffic; *) SPI field for IPSec encapsulated data;
*) DSCP/TOS field *) DSCP/TOS field
It is assumed that wildcarding on these identifiers is not needed
(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; this would be a case of an NSIS forwarder with no application (see section 3.2.1): an example scenario would be
interface to any resource management function. An example scenario messages passing through an addressing boundary where the flow
would be NSIS messages passing through an addressing boundary where identification had to be re-written.
the flow identification had to be re-written.
The very flexibility possible in flow classification is a possible
source of difficulties: when wildcards or ranges are included, it is
probably unreasonable to assume a standard classification capability
in routers; on the other hand, negotiating this capability would be a
significant protocol complexity.
4.5.2 Reservation Identification
There are several circumstances where it is important to be able to
refer to a reservation independently of whatever other information is
associated with it. The prime example is a mobility-induced address
change (handover) which required the flow identifier associated with
a reservation to be rewritten without installing a totally new
reservation (see section 5.3.1 for some security and scoping
implications of this use). The same capability could also be used to
simplify refresh or release messages in some circumstances, and might
be useful within the protocol to resolve reservation collisions
(where both sender and receiver initiate for the same flow).
A reservation identifier performs these roles. It is open how the
reservation identifier space should be defined and managed, and what
the scope of the identifier should be (only peer-peer, or end-end,
when interpreted in conjunction with some of the addressing
information). Some of the necessary identifier functions, especially
to do with local operation of NSIS, may also be provided by lower
layer signaling transport protocols.
4.5.3 NSLP Identification
Since the NTLP can be used to support several NSLPs, there is a need 4.5.2 Session Identification
to identify which one a particular NSIS message is being used for:
*) processing incoming messages at a responder - the NTLP should be
able to demultiplex these towards the appropriate signaling
application;
*) processing general NSIS messages at an NSIS aware intermediate
node - if the node does not handle the specific signaling
application, it should be able to make a forwarding decision without
having to parse the upper layer information.
Signaling application identifiers would probably require an IANA There are circumstances where it is important to be able to refer to
registry. signaling application state independently of the underlying flow.
For example, if the address of one of the flow endpoints changes due
to a mobility event, it is desirable to be able to change the flow
identifier without having to install a completely new reservation.
5. NSIS Protocol Interactions The session identifier provides a method to correlate the signaling
about the different flows with the same network control state.
So far as possible, the NSIS protocol should be usable in isolation, The session identifier is essentially a signaling application
without explicitly depending on other protocols to operate. However, concept, since it is only used in non-trivial state management
in many cases, NSIS functionality overlaps with the problem spaces of actions that are application specific. However, we assume here that
other protocols. In order to determine the boundaries which minimize it should be visible within the NTLP. This enables it to be used to
any explicit interdependencies, these protocol interactions must be control NTLP behavior, for example, by controlling how the transport
analyzed. layer should forward packets belonging to this session (as opposed to
this signaling application). In addition, the session identifier can
be used by the NTLP to demultiplex received signaling messages
between multiple instances of the same signaling application, if such
an operational scenario is supported (see section 4.5.3 for more
information on signaling application identification).
This is different from considering the use of NSIS protocols to To be useful for mobility support, the session identifier should be
support a particular signaling application, or example configurations globally unique, and it should not be modified end-to-end. It is well
in which NSIS might be deployed. These subjects are discussed in known that it is practically impossible to generate identifiers in a
section 7. way which guarantees this property; however, using a large random
number makes it highly likely. In any case, the NTLP ascribes no
valuable semantics to the identifier (such as 'session ownership');
this problem is left to the signaling application, which may be able
to secure it to use for this purpose.
5.1 Resource Management Interactions 4.5.3 Signaling Application Identification
The NSIS protocol is used for signaling resource requests from an Since the NTLP can be used to support several NSLP types, there is a
NSIS Initiator to an NSIS Responder. The NSIS protocol should be need to identify which type a particular signaling message exchange
useful for many signaling applications, but should not be involved in is being used for. This is to support:
any specific resource allocation or management techniques. As such, *) processing of incoming messages - the NTLP should be able to
we need to define the interaction between an NSIS entity and what we demultiplex these towards the appropriate signaling applications;
will call the Resource Management Function (RMF). The RMF is *) processing of general messages at an NSIS aware intermediate node
responsible for all resource provisioning, monitoring and assurance - if the node does not handle the specific signaling application, it
functions in the network. should be able to make a forwarding decision without having to parse
upper layer information.
The RMF may interact with NSIS entities in two different ways: as a No position is taken on the form of the signaling application
client or as a server. identifier, or even the structure of the signaling application
'space' - free-standing applications, potentially overlapping groups
of capabilities, etc. These details should not influence the rest of
NTLP design.
First, the RMF can act as a client towards the NSIS protocol, as a 4.6 Security Properties
particular application triggering NSIS signaling for resources in the
network. This is a special case of general NSIS triggering and will
not be elaborated here. This case could for instance apply with
multi-level NSIS signaling (section 7.5).
Second, the RMF can act as a server towards the NSIS protocol. In It is assumed that the only security service required within NTLP is
that case, the signaling decision taken by the NF may depend on the channel security. Channel security requires a security association to
content or processing of the NSIS payload. be established between the signaling endpoints, which is carried out
via some authentication and key management exchange. This
functionality could be provided by reusing a standard protocol.
The RMF may or may not be co-located with the NSIS protocol In order to protect a particular signaling exchange, the NSIS entity
processing. To cater for both cases, we define a (possibly logical) needs to select the security association that it has in place with
NF-RMF interface, see Figure 4. (As mentioned in section 3.1.1, the the next NSIS entity that will be receiving the signaling message.
NI and NR could also interact with an RMF. Note that this could also The ease of doing this depends on the addressing model in use by the
be modeled as co-location of the NI&NF and NR&NF. This distinction NTLP (see section 4.2).
should have no impact on the operation of the protocol.) Over this
interface, information may be provided from the RMF about monitoring,
resource availability, topology, configuration, and so on.
Additionally, resource provisioning requests may be issued towards
the RMF. Note that the actual implications for NSIS as a protocol are
the same, regardless of whether the RMF is centralized or
distributed, since NSIS sees the same interface towards the RMF in
each case.
+----+ NSIS +----+ NSIS +----+ NSIS +----+ Channel security can provide many different types of protection to
| NI |==========| NF |====...====| NF |==========| NR | signaling exchanges, including integrity and replay protection and
+----+ +----+ +----+ +----+ encryption. It is not clear which of these is required at the NTLP
^ ^ layer, although most channel security mechanisms support them all.
| |
V V
+----+ +----+
| RMF| | RMF|
+----+ +----+
Figure 4: Basic NSIS-RMF Relationship Channel security can also be applied to the signaling messages with
differing granularity, i.e. all or parts of the signaling message may
be protected. For example, if the flow is traversing a NAT, only the
parts of the message that do not need to be processed by the NAT
should be protected. 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.
One way to formalize the interface between the NF and the RMF is via 5. Interactions with Other Protocols
a Service Level Agreement (SLA). The SLA may be static or it may be
dynamically updated by means of a negotiation protocol. Such a
protocol is outside the scope of NSIS.
5.2 IP Routing Interactions 5.1 IP Routing Interactions
Several situations may occur when routing diverges from standard The NSIS Transport Layer (NTLP) is responsible for discovering the
layer 3 routing. These are summarized in the sections below. next node to be visited by the signaling protocol. For path-coupled
signaling, this next node should be the one that will be visited by
the data flow. In practice, this peer discovery will be approximate,
as any node could use any feature of the peer discovery packet to
route it differently than the corresponding data flow packets.
Divergence between data and signaling path can occur due to load
sharing or load balancing (section 5.1.1). An example specific to the
case of QoS is given in section 6.1.1. Route changes cause a
temporary divergence between the data path and the path on which
signaling state has been installed. The occurrence, detection and
impact of route changes is described in section 5.1.2. A description
of this issue in the context of QoS is given in section 6.1.2.
5.2.1 Load Sharing 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 source and destination will forward packets on any basis other than the destination address,
address, routing of NSIS messages using end-to-end addressing does routing of messages using end-to-end addressing does not guarantee
not guarantee that the messages will follow the data path. In this that the messages will follow the data path. Policy-based forwarding
section, we briefly survey what standard methods have been used for for data packets - where the outgoing link is selected based on
load sharing within standard routing protocols. policy information about fields additional to the packet destination
address - has the same impact.
In OSPF, load balancing can be used between equal cost paths [12] or
unequal cost paths. An example of the latter approach is Optimized
Multi Path (OMP). OMP discovers multiple paths, not necessarily equal
cost paths, to any destinations in the network, but based on the load
reported from a particular path, it determines which fraction of the
traffic 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 adjusting the hash thresholds.
BGP [13][14] advertises the routes 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.
Recently, however, a new mechanism was defined that will allow the
advertisement of multiple paths for the same prefix without the new
paths implicitly replacing any previous ones [15]. The essence of the
mechanism is that each path is identified by an arbitrary identifier
in addition to its prefix.
The distribution of traffic over the available path may be done per
destination, per message in a round-robin fashion or with a
predefined hashing function. The determination of the hashing image
may take into account the source/destination IP address, QoS
information such as the DSCP or protocol ID. When the routing
decision is no longer based on the destination address only, however,
there is a risk that data plane messages and control plane messages
will not follow the same route.
5.2.2 QoS Routing
The are 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.
For intra-domain traffic, the difference in routing may result from a
QoS-aware traffic engineering scheme, that e.g. maps incoming traffic
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 in 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.
5.2.3 Route pinning Signaling and data flow packets may diverge because of these
techniques. In OSPF, load balancing can be used between equal cost
paths [15] or unequal cost paths. An example of the latter approach
is Optimized Multi Path (OMP). OMP discovers multiple paths, not
necessarily equal cost paths, to any destinations in the network, but
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
adjusting the hash thresholds. BGP [16][17] advertises the routes
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. Recently, however, a new mechanism was
defined that will allow the advertisement of multiple paths for the
same prefix without the new paths implicitly replacing any previous
ones [18]. The essence of the mechanism is that each path is
identified by an arbitrary identifier in addition to its prefix.
Route pinning refers to the independence of the path taken by certain If the routing decision is based on both source and destination
data packets from reachability changes caused by routing updates from address, signaling and data flow packets may still diverge because of
an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway layer 4 load-balancing (based on TCP/UDP or port-based). Such
Protocol (BGP). This independence may for instance be caused by the techniques would, however, constrain the use of proxies. Proxies
configuration of static LSPs or by the establishment of explicitly would cause ICMP errors to be misdirected to the source of the data
routed LSPs by means of a signaling protocol (RSVP-TE or CR-LDP). If because of source address spoofing.
the NSIS signaling messages follow standard Layer 3 routing, this may
cause a divergence between control plane and data plane. If
reservations are made on the control plane, this may result in
sending data along an unreserved path while maintaining a reservation
on a path that is not used.
5.2.4 Route Changes If the routing decision is based on the complete five-tuple,
divergence may still occur because of the presence of router alert
options. In this case, the same constraint on proxy use applies as
above. Additionally, it becomes difficult for the end systems to
distinguish between data and signaling packets. Finally, QoS routing
techniques (section 6.1.3) may base the routing decision on any field
in the packet header (e.g. DSCP, ...).
In this section, we will explore the expected interworking between a Most load-balancing techniques use the first n bytes of the packet
signaling for resource BGP routing updates, although the same applies header (including SA, DA and protocol field) in the hashing function.
for any source of routing updates. The normal operation of the NSIS In this case, the above considerations regarding source/destination
protocol will lead to the situation depicted in Figure 5, where the address or five-tuple based forwarding apply.
reserved resources match the data path.
reserved +----+ reserved +----+ 5.1.2 Route Changes
------->| NF |----------->| NF |
+----+ +----+
=====================================
data path
Figure 5: Normal NSIS protocol operation In a routed network, each packet is independently routed based on its
header information. Whenever a better route towards the destination
becomes available, this route is installed in the forwarding table
and will be used for all subsequent (data and signaling) packets.
This can cause a divergence between the path along which state has
been installed and the path along which forwarding will actually take
place.
A route change (triggered by a BGP routing update for instance) can The possibility of route changes requires the presence of three
occur while such a reservation is in place. In case of RSVP, the processes in the signaling protocol
route change will be installed immediately and any data that is sent 1. route change detection
will be forwarded on the new path. This situation is depicted 2. installation of state on the new path
Figure 6. 3. teardown of state on the old path
Route update Many route change detections methods can be used, some of which need
| explicit protocol support and some of which are implementation-
v internal. They differ in their speed of reaction and the types of
reserved +----+ reserved +----+ change they can detect. In rough order of increasing applicability,
------->| NF |----------->| NF | they can be summarized as:
+----+ +----+ a) monitoring changes in local interface state
========== | b) monitoring network-wide topology changes in a link-state routing
|| | +----+ protocol
|| +---------->| NF | c) inference from changes in data packet TTL
|| +----+ d) inference from loss of packet stream in a downstream flow-aware
============================ router
data path e) inference from changes in signalling packet TTL
f) changed route of a PATH-like (end-to-end addressed) signaling
packet
g) changed route of a specific end-to-end addressed probe packet
Figure 6: Route Change There are essentially three ways in which detection can happen: based
on network monitoring (method a-b), based on data packet monitoring
(method c-d) and based on monitoring signaling protocol messages
(method e-g). Methods contingent on monitoring signaling messages
become less effective as refresh reduction techniques are used.
Resource reservation on the new path will only be started once the When a route change has been detected, it is important that state is
next control message is routed along the new path. This means that installed as quickly as possible along the new path. It is not
there is a certain time interval during which resources are not guaranteed that the new path will be able to provide the same
reserved on (part of) the data path. To minimize this time interval characteristics that were available on the old path. In order to be
several techniques could be considered. As an example, RSVP [18] has able to avoid duplicate state installation or, worse, rejection of
the concept of local repair, where the router may be triggered by a the signaling message because of previously installed state, it is
route change. In that case the RSVP node can start sending PATH important to be able to recognize the new signaling message as
messages directly after the route has been changed. Note that this belonging to an existing session. In this respect, we distinguish
option may not be available for NSIS if no per-flow state is kept in between route changes with associated change of the flow
the NF. specification (e.g. in case of a mobility event when the IP source
might change) and route changes without change of the flow
specification (e.g. in case of a link failure along the path). The
former case requires an identifier independent from the flow
specification.
It is not guaranteed that the new path will be able to provide the When state has been installed along the new path, the existing state
same guarantees that were available on the old path. Therefore, in a on the old path needs to be removed. With the soft-state principle,
more desirable scenario, the NF should wait until resources have been this will happen automatically because of the lack of refresh
reserved on the new path before installing the route change. The messages. Depending on the refresh timer, however, it may be required
route change procedure then consists of the following steps: to tear down this state much faster (e.g. because it is tied to an
1. NF receives a route announcement, accounting record). In that case, the teardown message needs to be
2. Refresh messages are forwarded along the current path, able to distinguish between the new path and the old path.
3. A copy of the refresh message is remarked as request and send
along the new path that was announced,
4. When the NF has been acknowledged about the reservations on the
new path the route will be installed and the traffic will flow along
the new path.
Another example related to route changes is denoted as severe The problem of route changes would not occur if there was a way to do
congestion and is explained in [19]. This solution adapts to a route route pinning. Route pinning refers to the independence of the path
change, when a route change creates a congestion on the new routed taken by certain data packets from reachability changes caused by
path. routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an
Exterior Gateway Protocol (BGP).
5.2.5 Router Redundancy 5.1.3 Router Redundancy
In some environments, it is desired to provide connectivity and per In some environments, it is desired to provide connectivity and per
flow or per class resource management with high-availability flow or per class flow management with high-availability
characteristics, i.e. with rapid transparent recovery even in the characteristics, i.e. with rapid transparent recovery even in the
presence of route changes. This may involve interactions with the presence of route changes. This may involve interactions with the
basic protocols which are used to manage the routing in this case, basic protocols which are used to manage the routing in this case,
such as VRRP [20]. A future version of this document may consider such as VRRP [19]. A future version of this document may consider
interactions between NSIS and such protocols in support of high interactions between NSIS and such protocols in support of high
availability functionality. availability functionality.
5.3 Mobility Interactions 5.2 Mobility Interactions
The interactions between mobility and resource signaling protocols Mobility, in most cases, causes changes to the data path that packets
have been extensively analyzed in recent years, primarily in the take. Assuming that signaling has taken place prior to any mobility
context of RSVP and Mobile IP interaction (e.g. [21]), but also in to establish some state along the data path, new signaling may be
the context of other types of network (e.g. [22]). This analysis work needed in order to (re)establish state along the changed data path.
has shown that some difficulties in the interactions are quite deep
seated in the detailed design of these protocols; however, the
problems and their possible solutions fall under five broad headings.
The main issue is to limit the period after handovers during which
the resource state has not been installed on the path, in particular
the new part of the path.
We can use this work as the starting point for considering the The interactions between mobility and signaling protocols have been
framework aspects of a new signaling protocol like NSIS, which will extensively analyzed in recent years, primarily in the context of
need to interwork with mobility signaling, from Mobile IP to mobility RSVP and Mobile IP interaction (e.g. [20]), but also in the context
paradigms based on micromobility or application layer approaches. of other types of network (e.g. [21]). 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 for which the resource states are not
available along the path; and avoiding double reservations -
reservations on both the old path and new path. Similar issues may
apply to other types of signaling application.
5.3.1 Addressing and Encapsulation 5.2.1 Addressing and Encapsulation
A mobility solution typically involves address reallocation on A mobility solution typically involves address reallocation on
handover (unless a network supports per host routing) and may involve handover (unless a network supports per host routing) and may involve
special packet formats (e.g. the routing header and Home Address special packet formats (e.g. the routing header and Home Address
option of MIPv6). Since NSIS may depend on end system addresses for option of MIPv6). Since NSIS may depend on end system addresses for
forwarding signaling messages and defining flows (section 4.5.1), the forwarding signaling messages and defining flows (section 4.5.1), the
special implications of mobility for addressing need to be special implications of mobility for addressing need to be
considered. Examples of possible approaches that could be used to considered. Examples of possible approaches that could be used to
solve the addressing and encapsulation problem are as follows: solve the addressing and encapsulation problem are as follows:
*) Use a flow identification based on low level IP addresses (e.g.
the Care of Address) and other 'standard' fields in the IP header. * Use a flow identification based on low level IP addresses (e.g. the
This makes least demands on the packet classification engines within Care of Address) and other 'standard' fields in the IP header. This
the network. However, it means that even on a part of the flow path makes least demands on the packet classification engines within the
which is unchanged, the reservation will need to be modified to network. However, it means that even on a part of the flow path that
reflect the changed flow identification (see section 5.3.3). is unchanged, the session will need to be modified to reflect the
*) Use a flow identification that does not change (e.g. based on changed flow identification (see section 5.2.3).
Home Address); this is the approach assumed in [23]. This simplifies
the problem of reservation update, at the likely cost of considerably * Use a flow identification that does not change (e.g. based on Home
Address); this is the approach assumed in [22]. This simplifies the
problem of session update, at the likely cost of considerably
complicating the flow identification requirements. complicating the flow identification requirements.
In the first approach, to prevent double reservation, NSIS nodes need In the first approach, to prevent double reservation, NSIS entities
to be able to recognize that a reservation with the new flow need to be able to recognize that a session with the new flow
identifier is to be correlated with an existing one. The reservation identifier is to be correlated with an existing one. A session
identifier (section 4.5.2) was introduced for exactly this purpose. identifier could be used for this purpose. This is why the session
Note that this would require the reservation identifier to have identifier as described in section 4.5.2 has to have end-to-end
(secure) end to end significance. (An additional optimization here semantics.
would be use a local mobility management scheme to localize the
visibility of the address change.)
The feasibility and performance of this first approach needs to be While the feasibility and performance of this first approach needs to
assessed, including a detailed analysis of the signaling scenarios be assessed, given the high impact of requiring more sophisticated
after a handover. However, given the high impact of requiring more packet classifiers, it still seems more plausible than the second
sophisticated packet classifiers, initially it still seems more approach. This implies that signaling applications should define
plausible than the second approach. This implies that the NSIS flows in terms of real, routable (care of) addresses rather than
initiator should define flows in terms of real (care of) addresses virtual (home) addresses.
rather than virtual (home) addresses. Thus, it would have detailed
access to lower layer interface configuration (cf. section 4.1),
rather than operating as a pure application level daemon as is
commonplace with current RSVP implementations.
5.3.2 Localized Path Repair 5.2.2 Localized Path Repair
In any mobility approach, a handover will cause at least some changes In any mobility approach, a handover will cause at least some changes
in the path of upstream and downstream packets. NSIS needs to install in the path of upstream and downstream packets. At some point along
new state on the new path, and remove it on the old. Provided that the joined path, an NSIS entity should be able to recognize this
some NSIS node on the joined path - the crossover router - can situation, based upon session identification. New state needs to be
recognize this situation (which again depends on reservation installed on the new path, and removed from the old. Who triggers the
identification), state installation and teardown can be done locally new state may be constrained by which entities are allowed to carry
between it and the mobile node. (This may have implications for which out which state manipulations, which is then a signaling application
entities are allowed to generate which message types, see section question.
4.3.2). It seems that the basic NSIS framework already contains the
fundamental components necessary for this.
A critical point here is the signaling that is used to discover the A critical point here is the signaling that is used to discover the
crossover router. This is a generalization of the problem of finding crossover node. This is a generalization of the problem of finding
next-NSIS-hop nodes: it requires extending the new path over several next-NSIS peer: it requires extending the new path over several hops
hops until it intersects the old one. This is easy for uplink traffic until it intersects the old one. This is easy for the uplink
(where the mobile is the sender), but much harder for downlink direction (where the mobile is the sender), but much harder for
traffic without signaling via the correspondent. There is no reason downlink without signaling via the correspondent. There is no reason
for the crossover routers for uplink and downlink flows to be the for the crossover node for uplink and downlink flows to be the same,
same, even for the same correspondent. The problem is discussed even for the same correspondent. The problem is discussed further in
further in [24]. [23].
5.3.3 Reservation Update on the Unchanged Path 5.2.3 Update on the Unchanged Path
On the path between the crossover router(s) and the correspondent, it On the path between the crossover node(s) and the correspondent, it
is necessary to avoid, if possible, double reservations, but rather is necessary to avoid, if possible, double reservations, but rather
to update the reservation state to reflect new flow identification to update the network control state to reflect new flow
(if this is needed, which is the default assumption of section identification (this is needed, by the default assumption of section
5.3.1). Examples of approaches that could be used to solve this 5.2.1). Examples of approaches that could be used to solve this
problem are the following: problem are the following:
*) Use a reservation state definition that does not change even if
the flow definition changes (see Section 4.5.2). In this case this
problem is solved.
*) Use signaling all the way to the correspondent node (receiver end
host), accepting the additional latency that this might impose.
*) Use an NSIS-capable crossover router that manages this
reservation update autonomously (more efficiently than the end
nodes), with similar considerations to the local path repair case.
5.3.4 Interaction with Mobility Signaling *) Use a session state identification that does not change even if
the flow definition changes (see Section 4.5.2). Signaling is still
needed to update a changed flow identification, but it should be
possible to avoid AAA and admission control processing.
In existing work on mobility protocol and resource signaling protocol *) 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
interactions, several framework proposals describing the protocol interactions, several framework proposals describing the protocol
interactions have been made. Usually they have taken existing interactions have been made. Usually they have taken existing
protocols (Mobile IP and RSVP respectively) as the starting point; it protocols (Mobile IP and RSVP respectively) as the starting point; it
should be noted that an NSIS protocol might operate in quite a should be noted that an NSIS protocol might operate in quite a
different way. In this section, we provide an overview of how these different way. In this section, we provide an overview of how these
proposals would be reflected in framework of NSIS. The mobility proposals would be reflected in framework of NSIS. The mobility
aspects are described using Mobile IP terminology, but are generally aspects are described using Mobile IP terminology, but are generally
applicable to other network layer mobility solutions. The purpose of applicable to other network layer mobility solutions. The purpose of
this overview is not to select or prioritise any particular approach, this overview is not to select or prioritise any particular approach,
but simply to point out how they would fit into our framework and any but simply to point out how they would fit into our framework and any
major issues with them. major issues with them.
We can consider that two signaling processes are active: mobility We can consider that two signaling processes are active: mobility
signaling (e.g. binding updates or local micromobility signals) and signaling and NSIS signaling. The discussion so far considered how
NSIS. The discussion so far considered how NSIS should operate. There NSIS signaling should operate. There is still a question of how the
is still a question of how the interactions between the NSIS and interactions between the NSIS and mobility signaling should be
mobility signaling should be considered. considered.
The basic case of totally independent specification and The basic case of totally independent specification and
implementation seems likely to lead to ambiguities and even implementation seems likely to lead to ambiguities and even
interoperability problems (see [23]). At least, the addressing and interoperability problems (see [22]). At least, the addressing and
encapsulation issues for mobility solutions that use virtual links or encapsulation issues for mobility solutions that use virtual links or
their equivalents need to be specified in an implementation-neutral their equivalents need to be specified in an implementation-neutral
way. way.
A type of 'loose' integration is to have independent protocol A type of 'loose' integration is to have independent protocol
definitions, but to define how they trigger each other - in definitions, but to define how they trigger each other - in
particular, how the mobility protocol triggers NSIS to send particular, how the mobility protocol triggers sending of
refresh/modify/tear messages. A pair of implementations could use refresh/modify/tear messages. A pair of implementations could use
these triggers to improve performance, primarily reducing latency. these triggers to improve performance, primarily reducing latency.
(Existing RSVP modification consider the closer interaction of making (Existing RSVP modifications consider the closer interaction of
the RSVP implementation mobility-routing aware, e.g. so it is able to making the RSVP implementation mobility routing aware, e.g. so it is
localize refresh signaling; this would be a self contained aspect of able to localize refresh signaling; this would be a self contained
NSIS.) This information could be developed for NSIS by analyzing aspect of NSIS.) This information could be developed by analyzing
message flows for various mobility signaling scenarios as was done message flows for various mobility signaling scenarios as was done in
in [21]. [20].
An even tighter level of integration is to consider a single protocol An even tighter level of integration is to consider a single protocol
carrying both mobility and resource information. Logically, there are carrying both mobility and network control state information.
two cases: Logically, there are two cases:
1. Carry mobility routing information (a 'mobility object') in the 1. Carry mobility routing information (a 'mobility object') in the
resource messages, as is done in [23]. (The prime purpose in this signaling messages, as is done in [22]. (The prime purpose in this
approach is to enable crossover router discovery.) approach is to enable crossover router discovery.)
2. Carry resource signaling in the mobility messages, typically as a
new extension header. This was proposed in [25] and followed up 2. Carry signaling in the mobility messages, typically as a new
in [26]; [27] also anticipates this approach. In our framework, we extension header. This was proposed in [24] and followed up in [25];
could consider this a special case of NSIS layering, with the [26] also anticipates this approach. In our framework, we could
mobility protocol playing the role of the signaling transport (as consider this a special case of NSIS layering, with the mobility
in 4.3.1). protocol playing the role of the signaling transport.
The usefulness of this class of approach depends on a tradeoff
between specification simplicity and performance. Simulation work is
under way to compare the performance of the two approaches in the
case of RSVP and micromobility protocols.
Other modes of interaction might also be possible. The critical point Other modes of interaction might also be possible. The critical point
with all these models is that the general solutions developed by NSIS with all these models is that the general solutions developed by NSIS
should not depend fundamentally on the choice of any particular should be independent of mobility protocols. Tight integration would
mobility protocol. Especially if it has interdomain scope, tight have major deployment issues especially in interdomain cases.
integration would have major deployment issues (even loose Therefore, any tightly integrated solution is considered out of scope
integration could require NSIS implementations to hook into multiple of initial NSIS development.
different mobility protocols). Therefore, any tightly integrated
solution should be considered out of scope of initial NSIS
development, and even in the long term is probably only applicable if
it can be localized within a particular part of the network.
5.3.5 Interaction with Fast Handoff Support Protocols 5.2.5 Interaction with Context Transfer
In the context of mobility between different access routers, it is In the context of mobility between different access routers, it is
common to consider performance optimizations in two areas: selection common to consider performance optimizations in two areas: selection
of the optimal access router to handover to, and transfer of state of the optimal access router to handover to, and transfer of state
information between the access routers to avoid having to regenerate information between the access routers to avoid having to regenerate
it in the new access router after handover. The seamoby working group it in the new access router after handover. The Seamoby Working Group
is developing solutions for these protocols for pure IP based is developing solutions for these protocols (CARD [27] and Context
networks (CARD[28] and CT[29] respectively); other networks, which Transfer [28] respectively); alternative approaches with similar
use NSIS for resource signaling within the network, may use different characteristics are also possible.
types of solution.
In this section, we consider how NSIS should interact with these
functions, however they are implemented. Detailed solutions are not
proposed, but the way in which interaction these functions is seen
within the NSIS framework is described. NSIS should be able to
operate independently of these protocols. However, significant
performance gains could be achieved if they could be made to
cooperate. In addition, the resource signaling aspects of these
protocols could profitably use a common set of resource types and
definitions, since they will probably be supporting the same overall
signaling application.
The question arises, what the mode of interaction should be:
independent operation, NSIS triggering access router discovery and
state transfer, or vice versa. The questions for the two cases seem
to be independent.
For access router discovery, a typical model of operation is that the
mobile carries out an information gathering exercise about a range of
capabilities. In addition, where those capabilities relate purely to
the AR and mobile, there is no role for NSIS (its special
functionality is not relevant). However, considering resource
aspects, one aspect of the AR 'capability' is resource availability
on the path between it and the correspondent, and NSIS should be able
to fulfill this part. Indeed, this is effectively precisely the
application considered in [26], where it is a sort of special case of
resource signaling during handover.
Therefore, a possible model of access router discovery/NSIS
relationship is that some entity in a candidate AR triggers NSIS
using resource and reservation information (including reservation id)
from the current AR to find out about what would be available on the
new path. Note that this should be a query rather than an actual
reservation; this semantic could be included either in the NTLP or
NSLP.
The case of state transfer is more complex. There are two obvious
options, corresponding to whether one transfers just signaling
application state or NSIS state as well:
1. "State transfer triggering NSIS": A state transfer process passes
the 'raw' resource state to the new AR. This triggers a new instance
of NSIS to request that resource.
2. "NSIS using state transfer": NSIS transfers its own state
information from the old to the new AR. It can then carry out the
same update signaling as though it was a single 'virtual AR' which
had just had a topology change towards the correspondent. (This is
essentially the conceptual model of [21].)
The first model is simpler, and maybe more in line with the basic
state transfer expectation; however, it seems hard to avoid double
reservations since the two NSIS protocol instances are not
coordinated. Therefore, the second model seems more appropriate. An
advantage of the 'virtual AR' model is that it ensures that the
impact of the interaction is limited to the NSIS instances at ARs
themselves, since the rest of the network must be able to handle a
topology change anyway.
Note that there is an open issue of who is responsible between the As these solutions are still underdevelopment, it is premature to
mobile and AR to decide that the state transfer procedures have not specify details on the interaction. It is thought that Context
happened for whatever reason - e.g. because they were not even Transfer transfers state between access routers based upon changes
implemented - and take recovery action to have the mobile refresh caused by mobility. NSIS protocol state may be a candidate for
reservations promptly. It appears this has to be an NSIS context transfer. Such work, should it be undertaken, will be done
responsibility in the AR, and probably requires a custom notification in the Seamoby working group.
message for this circumstance.
5.4 NSIS Interacting with NATs 5.3 Interactions with NATs
Because at least some NSIS messages will almost inevitably contain Because at least some messages will almost inevitably contain address
address and possibly higher layer information as payload (see section and possibly higher layer information as payload, we must consider
4.5.1), we must consider the interaction between NSIS and address the interaction with address translation devices (NATs). As well as
translation devices (NATs). As well as 'traditional' NATs of various 'traditional' NATs of various types (as defined in [29]) very similar
types (as defined in [30]) very similar considerations would apply to considerations would apply to some IPv4/v6 transition mechanisms such
some IPv4/v6 transition mechanisms such as SIIT [31]. as SIIT [30].
In the simplest case of an NSIS unaware NAT in the signaling path, In the simplest case of an NSIS unaware NAT in the signaling path,
payloads will be uncorrected and the signaling will be for the payloads will be uncorrected and the signaling will be for the
incorrect flow. Applications could attempt to use STUN [32] or incorrect flow. Applications could attempt to use STUN [31] or
similar techniques to detect and recover from the presence of the similar techniques to detect and recover from the presence of the
NAT. Even then, NSIS would have to use a well known encapsulation NAT. Even then, NSIS protocols would have to use a well known
(TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end encapsulation (TCP/UDP/ICMP) to avoid being dropped by the more
NAT devices. cautious low-end NAT devices.
A simple 'NSIS-aware' NAT would require flow identification A simple 'NSIS-aware' NAT would require flow identification
information to be in the clear and not integrity protected. An information to be in the clear and not integrity protected. An
alternative conceptual approach is to consider the NAT functionality alternative conceptual approach is to consider the NAT functionality
being part of NSIS 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 security translating node can take part natively in any NSIS protocol security
mechanisms. Depending on NSIS layering, it could be possible for this mechanisms. Depending on NSIS protocol layering, it would be possible
processing to be done in an NSIS node which was otherwise ignorant of for this processing to be done in an NSIS entity which was otherwise
any particular NSIS signaling applications. ignorant of any particular signaling applications. This is the
motivation for including basic flow identification information in the
Note that all of this discussion is independent of the use of NSIS NTLP (section 4.5.1).
for general control of NATs (and firewalls). This is considered in
section 7.4.
6. Security and AAA Considerations
A framework is meant to create boundaries for a later protocol and to
describe the interaction between the protocol and its environment.
Security issues usually turn out to have impacts in the interaction
of these protocols and must therefore be appropriately addressed in
such a framework. This section describes these general security
issues, and in particular considers the interactions between NSIS and
authentication, authorization and accounting. Together with
authentication the protection of the signaling messages is addressed
- namely replay and integrity protection.
An initial analysis of the major security threats that apply in the
typical of scenario where NSIS is expected to be used is given in
[5]; these threats are described at the overall scenario level, in
terms of the impact on users and networks. However, in any given
scenario, NSIS will be just one part of the overall solution.
Ultimately, the framework will need to define which of these threats
need to be handled by NSIS (and which parts of NSIS) and which by the
other components. Currently, we can only make initial scoping
assumptions of this sort.
6.1 Authentication
Authentication and key establishment for a signaling protocol should
be seen as a two-phase process. The first-phase is usually more
performance intensive because of a larger number of roundtrips,
denial of service protection, cross-realm handling, interaction with
other protocols and the likely larger cryptographic computation
associated with it. As stated in section 4.3, this functionality
could be provided externally to NSIS, e.g. by reusing a standard
protocol which already included this functionality.
At the end of this phase it should be possible to create or derive
security associations that are usable for the protection of the NSIS
signaling messages themselves. The functionality required here
relates to (data origin) authentication (including integrity and
replay protection) of individual signaling messages. Key
establishment, rekeying, synchronization issues are issue that may be
addressed here depending on the specific method. In any case the
protection applied to each signaling message must be fast and
efficient.
When using cryptography to protect signaling messages, it is obvious
that a node must be able to select the appropriate security
association in order to be able to apply signaling message
protection. This should just be a general point about endpoint
identity issues. Hence the identifier must be available to the
transmitting node. Regarding identities there is a need to support
different identity types to enable the flexible usage of several
signaling initiators and receivers. Supporting static configuration
and dynamic learning of these identities should be provided.
6.2 Authorization
Authorization information can be seen in an abstract form as "Can the
resource requestor be trusted to pay for the reservation?". This
abstraction is supported by the fact that reservations require some
form of incentive to use some 'default' resource (or vice versa -
penalty for not reserving too many resources). In general, the
semantics of the authorisation will depend on the signaling
application in use. The implication of this is that NSIS will not
directly make authorisation decisions; instead, the authorisation
information must be fed into the resource management function
(section 5.1) which actually decides on the request.
Some negotiation needs to take place to determine which node will
take responsibility for authorising a resource request, the
implication being that the same node will ultimately be accounted to
for it. Such a negotiation needs to be flexible enough to support
most currently deployed schemes (e.g. reverse charging, etc.) while
keeping efficiency and simplicity in mind. This negotiation might be
executed before starting resource signaling (assumed in section 4.2),
although it could also be part of the NSIS signaling messages (as in
some proposals dealing with charging and RSVP). Since information
needs to be sent to the networks, some information needs to be
included to provide the network with the necessary information to
start the authorisation process. Hence fully opaque objects might not
always be the proper choice.
It is not clear if 'initiation' of a reservation is related to
willingness to accept authorisation responsibility. (Current
practices tend to assume that flow originators are responsible.) In
any case, it seems unlikely that a domain will make a cost-incurring
request of a peer domain without already having received a matching
request from the peer in the other direction - in other words,
requests must propagate between domains in the same direction as
authorisation responsibility.
If this argument is correct, and if NSIS initiation and authorisation Note that all of this discussion is independent of the use of a
responsibility are decoupled, it must be possible for the specific NSLP for general control of NATs (and firewalls). This is
authorisation responsibility to propagate both in the direction considered in section 6.2.
initiator->responder and vice versa. Also, if both [flow] sender and
receiver initiation are possible, service descriptions must include
information about the authorisation policy to be applied, which must
be imposed consistently along the whole path. These issues should be
analyzed to determine if 1, 2 or 4 alternative scenarios are possible
and realistic.
A second question is that of which entities actually authorise which. 6. Signaling Applications
One end user must ultimately get authorisation for the request (this
may or may not be assumed to be the NSIS initiator, see below). There
are then two possible models for how this authorisation is done
throughout the path.
The first model assumes that each network along the path is able to This section describes NSLPs for particular signaling applications.
authenticate and authorise the user directly. The implication for a The assumption is that the NSLP uses the generic functionality of the
signaling protocol is that the user credentials cannot be removed NTLP given earlier; this section describes specific aspects of NSLP
after the first hop and have to be further included in the message operation.
when forwarded to other networks. Every node along the path is then
able to verify the user and to provide policy based admission
control.
The second model assumes that the user credentials are removed at the 6.1 Signaling for Quality of Service
first hop. The first network knows the user identity requesting the
resources but does not include this information further along the
path. The first network can therefore be seen as acting on behalf of
the originator to take responsibility to enable further reservations
to be done along the path i.e. in particular to the next network
only. This procedure is then applied on a hop-by-hop basis.
Note that both models are independent of whether a traditional In the case of signaling for QoS, all the basic NSIS concepts of
subscription based approach or an alternative means of payment (such section 3.1 apply. In addition, there is an assumed directionality of
as pre-pay on on-line charging by the visited network) is used. These the signaling process, in that one end of the signaling flow takes
issues only have an impact for the transmission of accounting records responsibility for actually requesting the resource. This leads to
and for a requirement to execute an online verification whether a the following definitions:
user still has sufficient credits/funds; therefore, these details do *) NSIS Initiator (NI): the signaling entity which makes the resource
not affect NSIS operation. request, usually as a result of user application request.
*) NSIS Responder (NR): the signaling entity that acts as the
endpoint for the signaling and can optionally interact with
applications as well.
*) NSIS Forwarder (NF): the signaling entity an NI and NR which
propagates NSIS signaling further through the network.
Each of these entities will interact with a resource management
function (RMF) which actually allocates network resources (router
buffers, interface bandwidth and so on).
6.3 Accounting 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
direction it could be at the sending or receiving end.
It is obvious that accounting/charging is an important part for the 6.1.1 Protocol Messages
success and the acceptance of a resource signaling protocol. Most of
the thinking in this area is derived from the specific case of
signaling for QoS; however, we make an initial working assumption
that the same paradigm should apply to any signaling application for
which accounting is necessary. We make the general assumption here
that accounting records are generated by the resource management
function based entirely on traffic measurements and processed in
accordance with the authorisation information that was used in
deciding to grant the request in the first place.
Therefore, NSIS plays no further part in this activity; the The QoS NSLP will include a set of messages to carry out resource
accounting records are transmitted using the AAA infrastructure, and reservations along the signaling path. A message set for the QoS NSLP
charging and billing for the overall service is carried out at some is shown below (a very similar set of messages was generated in
higher layer. This would include feedback to applications (and users) [32]). Note that the 'direction' column in the table below only
about total session cost (of which the network resource cost might be indicates the 'orientation' of the message. The messages can be
only a part). An open issue is whether a query (without actually originated and absorbed at NF nodes as well as the NI or NR; an
making a reservation) to the network should also generate a example might be NFs at the edge of a domain exchanging messages to
chargeable event; this could be considered as an aspect of the set up resources for a flow across a it.
service definition.
6.4 End-to-End vs. Peer Relationship Protection Note the working assumption that responder as well as the initiator
can release a reservation (comparable to rejecting it in the first
place). It is left open if the responder can 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.
It is reasonable to assume that peer relationship security (with +-------+---------+---------------------------------------------+
chain-of-trust) is used for most signaling environments relevant to | Name |Direction| Semantics |
NSIS. Especially the separation of signaling into different network +-------+---------+---------------------------------------------+
parts (intra-domain within the access network, end-node to access |Request| I-->R | Create a new reservation for a flow |
network, intra-domain, and so on) and new proposals regarding +-------+---------+---------------------------------------------+
mobility and proxy support show that traditional end-to-end signaling |Modify | I-->R | Modify an existing reservation |
is not applicable in every environment (or possibly only in a minor | |(&R-->I?)| |
number of environments). End-to-end security in a signaling protocol +-------+---------+---------------------------------------------+
is actually problematic for two reasons: |Release| I-->R & | Delete (tear down) an existing reservation |
| | R-->I | |
+-------+---------+---------------------------------------------+
|Accept/| R-->I | Confirm (possibly modified?) or reject a |
| Reject| | reservation request |
+-------+---------+---------------------------------------------+
|Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
+-------+---------+---------------------------------------------+
|Refresh| I-->R | State management (see section 4.4) |
+-------+---------+---------------------------------------------+
1. Even if the messages use the address of the end-host (to support The table also explicitly includes a refresh message. This does
routing), the messages still have to be interpreted and modified nothing to a reservation except extend its lifetime, and is one
along the path. possible state management mechanism (see next section).
2. The only property that can be achieved by using end-to-end 6.1.2 State Management
security is that one end-host can be assured that the other end-host
included some parameters (possibly resource parameters) that have not
been modified along the path. Nodes along the path usually do not
have the possibility to cryptographically verify the protected
message parts. If the two end-points negotiate which side has to pay
for the reservation (or possibly how much and other parameters)
within the signaling protocol then there is a need to protect this
information. This leads to the question which protocols are executed
before the signaling message exchange starts. If resource parameters
and payment/charging related information are already exchanged
beforehand as part of a separate protocol (possibly SIP) then there
is little need to protect (and possibly retransmit) this information
at the NSIS level basis. In most cases an opaque token to link the
different protocols may be sufficient.
7. NSIS Application Scenarios The prime purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in
section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made.
This section considers various application scenarios or deployment There two critical issues to be considered in building a robust NSLP
configurations for NSIS. Our goal is that an NSIS protocol designed to handle this problem:
according to the framework presented in the previous sections should *) The protocol must be scalable. It should allow minimization of the
be able to support these scenarios if implemented appropriately; resource reservation state storage demands that it implies for
therefore, this section does not form part of the framework intermediate nodes; in particular, storage of state per 'micro' flow
definition, but rather provides examples of how NSIS can be used to is likely to be impossible except at the very edge of the network. A
do something interesting. In the long term, some of this material may QoS signaling application might require per flow or lower granularity
be contained in specific NSIS applicability statements. state; examples of each for the case of QoS would be IntServ [33] or
RMD [34] (per 'class' state) respectively.
*) The protocol must be robust against failure and other conditions,
which imply that the stored resource reservation state has to be
moved or removed.
7.1 NSIS and Existing Resource Signaling Protocols For resource reservations, typically soft state management is
considered for robustness reasons. It is currently open whether the
soft state protocol aspects should be built into the NSLP for
specific signaling applications, or provided as a generic service by
the NTLP; this issue is discussed in section 3.4.2.
It is hoped that NSIS could eventually achieve widespread use for 6.1.3 QoS Forwarding
resource signaling. However, it is bound to have to inter-operate
with existing resource signaling protocols at least during transition
and possibly long term. The prime example for QoS is RSVP, although
other proprietary or domain specific protocols (e.g. bandwidth broker
related) may also be considered. A related issue is that NSIS will be
only one part of the solution: it will always need to interwork with
other resource-related protocols (e.g. COPS).
Analyzing the constraints on NSIS that come from these requirements The assumption is that the NTLP works with standard (i.e. best-
is hard before further refinement of the framework has been carried effort) layer 3 routing. There are, however, several proposals for
out and critical assumptions pinned down. However, we can identify the introduction of QoS awareness in the routing protocols. All of
various modes of interoperation, and the attributes of the framework these essentially lead to the existence of multiple paths (with
that will make them easy. 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.
Firstly, we allow for NSIS use over a 'long range', in conjunction For intra-domain data flows, the difference in routing may result
with a different protocol locally (e.g. intra-domain); or, the two from a QoS-aware traffic engineering scheme, that e.g. maps incoming
roles could be reversed. This is actually very similar to the case of flows to LSPs based on multi-field classification. In BGP, several
use of NSIS layered over itself (section 7.5). In the case where the techniques for including QoS information in the routing decision are
'inter-layer' interaction is mediated via resource management, the currently proposed. A first proposal is based on a newly defined BGP-
same should approach should work with non-NSIS protocols. What needs 4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute is
to be validated here is whether NSIS layering requires the exchange an optional transitive attribute that can be used to advertise a QoS
of NSIS specific information between the layers. 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.
A second issue is that NSIS should be deployable within an 6.1.4 Route Changes and QoS Reservations
environment without radical changes to supporting resource (or AAA)
related protocols. The main issue here is that NSIS should be
flexible in its ability to support different service definitions (and
possibly flow classifications). This is already one of the main goals
of the framework presented here.
The final point is that it should be possible to use NSIS over one In this section, we will explore the expected interworking between a
network region, concatenated with another protocol over an adjacent signaling for resource BGP routing updates, although the same applies
region. The main issue here, apart from the flexible service and flow for any source of routing updates. The normal operation of the NSIS
capabilities already mentioned, is that NSIS should be adaptable in protocol will lead to the situation depicted in Figure 7, where the
what it assumes about signaling paths (e.g. to interwork with both reserved resources match the data path.
path-coupled and decoupled solutions), and in initiation paradigms
(e.g. to interwork with sender and receiver initiated solutions).
7.2 NSIS Supporting Centralized QoS Resource Management reserved +----+ reserved +----+
------->| NF |----------->| NF |
+----+ +----+
=====================================
data path
One area of application for the NSIS protocol is for QoS resource Figure 7: Normal NSIS protocol operation
reservation and provisioning. The NSIS protocol may be used to
provide intra-domain or inter-domain QoS bandwidth reservation setup
by means of its interaction with the RMF. In what follows we assume
that the NEs are colocated with an admission control entity that has
a logical (abstract) view on the resources managed by the RMF, as
described in section 5.1.
The NEs in a domain can interface with an RMF managing the complete A route change (triggered by a BGP routing update for instance) can
domain, in which case, the abstract topology view provided between occur while such a reservation is in place. In case of RSVP, the
NSIS and RMF can be formalized as a Service Level Agreement (SLA). route change will be installed immediately and any data that is sent
This situation is depicted schematically in Figure 7. will be forwarded on the new path. This situation is depicted Figure
8.
+----+ NSIS +-----+ NSIS +----+ Route update
| NI |============| NF |=============| NR |
+----+ +-----+ +----+
|
| SLA
| |
+------+ v
| RMF | reserved +----+ reserved +----+
+------+ ------->| NF |----------->| NF |
+----+ +----+
Figure 7: Resource Reservation using RMF as a Server to NSIS ========== |
|| | +----+
In case of centralized RMF, the SLA or its technical part, the || +---------->| NF |
Service Level Specification (SLS) [33] specifies the resource || +----+
guarantees that the RMF needs to provide to the NF. These guarantees ============================
apply between one or more ingress and egress points of the network. data path
The SLS also specifies the availability and reliability of the
service. In the case of QoS signaling, it may refer to a bandwidth
service with certain performance guarantees regarding delay, jitter
or packet loss. The SLS interface can be automated by means of an SLS
negotiation protocol. This allows for more dynamical SLS
modifications and the exchange of notification messages with the NF.
These can for instance be used to provide monitoring feedback from
the RFM to the NF.
The decoupling of NSIS signaling and network management by means of
an SLS has some attractive properties:
*) It allows a Network Provider to easily share the use of its
infrastructure between several Service Providers using NSIS signaling
to provide their service.
*) It allows a clear separation between resource provisioning and
management and reservation signaling and admission control.
*) It relieves the NF from several tasks, making it potentially more
scalable in the core of the network.
The NF can perform either per-flow or per-class admission control Figure 8: Route Change
decisions based on the requested QoS information and on the
reservation state it keeps regarding active flows (or classes).
Keeping per-flow state may be required for policing,
accounting/billing and explicit reservation teardown. These functions
are mandatory in the access or edge of the network. Conveniently,
this is also where the processing needed to maintain per-flow state
will remain manageable. In the core, this approach may not scale very
well and per-class state may be used as an alternative that is very
scalable and allows for a lightweight processing of signaling
messages. With per-class state, however, we lose the ability to
directly notify the NI in case of unsolicited network events because
the affected flows cannot be identified. Instead, the NI needs to be
indirectly notified in response to a refresh message which in turn
mandates the use of soft-state with separate messages or message
structure for requests and refreshes.
The RMF can execute its network provisioning functions according to Resource reservation on the new path will only be started once the
its internal policies. In the easiest case, it may run an next control message is routed along the new path. This means that
overprovisioned network with only monitoring capabilities in order to there is a certain time interval during which resources are not
follow up on the delivered performance. In more complex scenarios, it reserved on (part of) the data path. To minimize this time interval
may use a whole array of network optimization tools in order to several techniques could be considered. As an example, RSVP [4] has
deliver and maintain service quality according to the SLS. This may the concept of local repair, where the router may be triggered by a
require network monitoring, the installation and use of appropriate route change. In that case the RSVP node can start sending PATH
protection mechanisms and providing feedback regarding actual traffic messages directly after the route has been changed. Note that this
performance to the NSIS entity. option may not be available if no per-flow state is kept in the NF.
Alternatively, the NSIS protocol may be used for resource It is not guaranteed that the new path will be able to provide the
provisioning. In that case, the RMF acts as a client towards the NSIS same guarantees that were available on the old path. Therefore, in a
protocol, as a particular "application" triggering an NI for more desirable scenario, the NF should wait until resources have been
resources in the network. This situation is depicted in Figure 8. reserved on the new path before installing the route change (unless
of course the old path no longer exists). The route change procedure
then consists of the following steps:
1. NF receives a route announcement,
2. Refresh messages are forwarded along the current path,
3. A copy of the refresh message is re-marked as a request and send
along the new path that was announced,
4. When the NF has been acknowledged about the reservations on the
new path the route will be installed and the data will flow along the
new path.
+------+ Another example related to route changes is denoted as severe
+----------| RMF |----------+ congestion and is explained in [34]. This solution adapts to a route
/ +------+ \ change, when a route change creates a congestion on the new routed
/ \ path.
/ \
/ \
+----+ NSIS +-----+ NSIS +----+
| NI |============| NF |=============| NR |
+----+ +-----+ +----+
Figure 8: NSIS for Resource Provisioning 6.1.5 Resource Management Interactions
In this case the RMF is providing traffic classification and The QoS NSLP itself is not involved in any specific resource
conditioning functions. An example of such functionality is described allocation or management techniques. The definition of an NSLP for
in [34]. The packet "classifiers" select the packets in a traffic resource reservation with Quality-of-Service, however, implies the
stream based on the content of some portion of the packet header. The notion of admission control. For a QoS NSLP, the measure of signaling
traffic "conditioner" performs metering, shaping, policing, success will be the ability to reserve resources from the total
scheduling and/or re- marking of packets to ensure that the traffic resource pool that is provisioned in the network. We define the
entering a node conforms to a certain predefined policy. function responsible for allocating this resource pool as the
Resource Management Function (RMF). The RMF is responsible for all
resource provisioning, monitoring and assurance functions in the
network.
7.3 NSIS Supporting Distributed Resource Management 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
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
provisioning in the network. In this case, the RMF acts as the
initiator (client) of an NSLP.
Section 7.2 described the situation where NSIS is supporting a This essentially corresponds to a multi-level signaling paradigm,
centralized RMF. This section introduces the situation where NSIS is with an 'upper' level handling internetworking QoS signaling,
supporting a distributed RMF. When the RMF is distributed in the possibly running end-to-end, and a 'lower' level handling the more
network, a protocol for communication with the NI, NF, NR may not be specialised intradomain QoS signaling, running between just the edges
required. In this case the RMF is providing traffic classification of the network (see [35], [36], and [37] for a discussion of similar
and conditioning functions; an example of such functionality is architectures). Given that NSIS signaling is already supposed to be
described in [34]. Figure 9 shows how a distributed RMF could able to support multiple instances of NSLPs for a given flow, and
interact with the NSIS protocol. limited scope (e.g. edge-to-edge) operation, it is not currently
clear that supporting the multi-level model leads to any new protocol
requirements for the QoS NSLP.
+----+ NSIS +-----+ NSIS +-----+ NSIS +----+ The RMF may or may not be co-located with an NF (note that co-
| NI |==========| NF |====...====| NF |==========| NR | location with an NI/NR can be handled logically as a combination
+----+ +-----+ +-----+ +----+ between NF and NI/NR). To cater for both cases, we define a (possibly
+----+ +-----+ +-----+ +----+ logical) NF-RMF interface. Over this interface, information may be
|RMF | | RMF | | RMF | |RMF | provided from the RMF about monitoring, resource availability,
+----+ +-----+ +-----+ +----+ topology, and configuration. In the other direction, the interface
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
Level Agreement (SLA). The SLA may be static or it may be dynamically
updated by means of a negotiation protocol. Such a protocol is
outside the scope of NSIS.
Figure 9: Distributed RMF as a server for NSIS There is no assumed restriction on the placement of the RMF. It may
be a centralized RMF per domain, several off-path distributed RMFs,
or an on-path RMF per router. The advantages and disadvantages of
both approaches are well-known. Centralization typically allows
decisions to be taken on more global information with more efficient
resource utilization as a result. It also facilitates deployment or
upgrade of policies. Distribution allows local decision processes and
rapid response to data path changes.
7.4 NSIS for Middlebox Signaling 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 NSIS to set up flow-related state in middleboxes possible to use develop NSLPs for other signaling applications which
(firewalls, NATs, and so on). Requirements for such communication are operate on different types of network control state. One specific
given in [35], and initial discussions of NSIS-like solutions are case is setting up flow-related state in middleboxes (firewalls,
contained in [36], [37] and [38]. A future version of this document NATs, and so on). Requirements for such communication are given in
may contain more details on how an NSIS should be used for this type [6], and initial discussions of NSIS-like solutions are contained in
of signaling application. [38], [39] and [40]. Other examples include network monitoring and
testing, and tunnel endpoint discovery.
7.5 Multi-Level NSIS Signaling
This section describes a way of separating the NSIS signaling
protocol into more than one hierarchical level. In this section three
levels of hierarchy are considered (see Figure 10); however, the
approach is quite general to more (or fewer) levels: the important
issue is the use of NSIS at more than one level at all.
The lowest hierarchical level ("level 1") provides basic resource
management functionality related to scalable, simple and fast soft
state maintenance and to transport functions, such as reliable
delivery of signaling messages, congestion control notification and
load sharing adaptation. Soft state that is maintained by this level
is usually per traffic class based.
The second hierarchical level ("level 2") is more complex than level
1 as regards soft state maintenance. Soft state maintained by this
hierarchical level is usually per flow. Note that this level, like
level 1, also supports transport functions. When an NSIS edge-to-edge
multi-domain protocol is used, level 2 stretches beyond domain
boundaries and is applied on all the edges of the domains that are
included in the multidomain region.
The third hierarchical level ("level 3") includes a set of upper-
level signaling functions that are specific to particular signaling
applications. Such functions could, for example, be security, policy,
billing, etc.
As shown in Figure 10, the three hierarchical levels might be applied
on different NSIS entities.
This three-level architecture for NSIS signaling can be provided by
using:
*) a single end-to-end NSIS protocol that supports all three
hierarchical levels
*) two independent NSIS protocols: Level 3 is supported by an end-
to-end NSIS protocol, and levels 1 and 2 are supported by another
edge-to-edge NSIS protocol.
|-----| |-------| |-------| |-----|
|level|<--| level |<--------------------------| level |<->|level|
| 3 |<--| 3 | | 3 |<->| 3 |
|-----| |-------| |-------| |-----|
| | | | | | | |
| | |-------| |-------| | |
| | | level |<------------------------->| level | | |
| | | 2 | | 2 | | |
| | |-------| |-------| | |
| | | | | | | |
|-----| | | |
------- -------| |-------| |-------| |-----|
|level|<->| level |<->| level |<->| level |<->| level |<->|level|
| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |
|-----| |-------| |-------| |-------| |-------| |-----|
NI NF NF NF NF NR
(edge) (interior) (interior) (edge)
Figure 10: Three level architecture for NSIS signaling
The components in the scenario are as follows:
*) NI (NSIS Initiator): can be an end-host or a proxy and can
process and use the "level 1" and "level 3" protocol components
*) NR (NSIS Responder): can be an end-host or a proxy and can
process and use the "level 1" and "level 3" protocol components
*) NF (NSIS Forwarder) (edge): can be a Diffserv edge, MPLS edge,
etc. It can process and use the "level 3", "level 2" and "level 1"
protocol components. Usually, "level 2" provides an interworking
between "level 1" and "level 3" protocol components.
*) NF (interior): can be any router within a domain. It can process
and use only the "level 1" protocol component. The "level 3" and
"level 2" protocol components are not processed (used or checked).
The hierarchical level separation can be provided by supporting a
hierarchical object structure. In other words, the NSIS protocol
objects should be structured and positioned within the NSIS messages
in a hierarchical way, i.e., first the "level 1" objects, then the
"level 2" objects and finally the "level 3" objects.
8. Open Issues
The following issues are currently open points within the framework.
They are summarized here to provide a single overview.
1. It is not clear which of the NI, NF and NR can modify or release
existing reservations (this is essentially an authorisation issue).
(Section 3.3.2.)
2. It is not clear whether NSIS entities relate to each other only
locally (peer-peer) or whether longer distance, non-local
interactions and state have to be managed and stored. (Section
3.3.3.)
3. NSIS messages could be addressed either explicitly (to the
neighboring peer) or implicitly, using the flow endpoint addresses.
(Section 3.3.4.)
4. It is not clear where to draw the boundaries between the NTLP and
NSIS signaling layer, and how to establish the extent to which the
requirements of the diverse signaling applications considered for
NSIS should influence NTLP functionality. (Section 3.3.5.)
5. If NSIS has explicit acknowledgement and notification messages,
it is open whether they should relate to anything beyond the
immediate peer relationship. (Section 3.3.6.)
6. To function as part of a complete system, the NSIS protocol may
need to be supported by extensions to other protocols. These
extensions are still to be identified. (Section 4.2.)
7. The NSIS protocol could be constructed on the services offered by A future version of this document may contain more details on how to
lower layer protocols, but the dividing line between NSIS and these build NSLPs for these types of signaling application.
lower layers is not fixed. Use of standard lower layer protocols may
be difficult if 'end-to-end addressing' (see section 3.3.4) is used.
(Section 4.3.1.)
8. It is commonly expected that a future resource signaling protocol 7. Security Considerations
would need to use abstract reservation identifiers. However, the
precise properties needed of these identifiers are unclear, and
enabling their secure use may be hard. (Sections 4.5.2 and 5.3.2.)
9. Use of some routing techniques (e.g. load sharing or QoS This document describes a framework for signaling protocols which
routing), even in remote parts of the network, could be incompatible assumes a two-layer decomposition, with a common lower layer (NTLP)
with naive use of end-to-end addressing. (Sections 5.2.1 and 5.2.2.) supporting a family of signaling application specific upper layer
protocols (NSLPs). The overall security considerations for the
signaling therefore depend on the joint security properties assumed
or demanded for each layer.
10. The correct flow identification semantics need to be defined in Security for the NTLP is discussed in section 4.6. We have assumed
the case where mobility encapsulations might make it ambiguous which that the role of the NTLP will be to provide message protection over
addresses to use. (Section 5.3.1.) the scope of a single peer relationship (between adjacent signaling
entities), and that this can most likely be provided by some kind of
channel 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.
11. The interactions between mobility and resource signaling during Security for the NSLPs is entirely dependent on signaling application
path updating need to be further analyzed, especially from the point requirements. In some cases, no additional protection may be required
of view of combined overall latency. (Section 5.3.2 and 5.3.3.) compared to what is provided by the NTLP. In other cases, more
sophisticated object-level protection and the use of public key based
solutions may be required. In addition, the NSLP needs to consider
the authorisation requirements of the signaling application.
9. Change History Another factor is that NTLP security mechanisms operate only locally,
whereas NSLP mechanisms may also need to operate over larger regions
(not just between adjacent peers) especially for authorisation
aspects; this complicates the analysis of basing signaling
application security on NTLP protection. Further work on this and
other security design will depend on a refinement of the NSIS threats
work begun in [12].
9.1 Changes from draft-ietf-nsis-fw-00.txt 8. Change History
1. Editorial fix in 'classifier' definition (section 2). 8.1 Changes from draft-ietf-nsis-fw-01.txt
2. Added definition of 'peer determination' (finding the right peer
for a given flow) (section 2).
3. Added definitions for 'sender' and 'receiver' refers to role
relative to data packets always (section 2, and minor fixes in
sections 3.2.6 and 3.2.7).
4. Updated references.
5. Replaced 'peer session' with 'peer relationship' and 'peer
session addressing' with 'peer-peer addressing' (throughout), and
attempted redraw of Figure 1 to make it less session-like
(corresponding changes in Figure 4, Figure 7, Figure 8, and
Figure 9).
6. Added terms for transport and signaling layer protocols
(NTLP/NSLP) and explanation in new section 3.1.3. New terms used
throughout (significant rewrites to section 4, although this
should be at most a change of emphasis rather than technical
content).
7. Clarified that section 3.2 is about possible modes of operation
(listing alternatives, not all to be supported).
8. Clarified 'local object' definition in 3.2.4.
9. Added working assumption in 3.3.1 that end-to-end routing is done
by sequentially determining the right peer in the NTLP, and no-
one discovers or uses global topology information for this.
10.Added working assumption in 3.3.3 that NTLP operates only
locally.
11.Slightly trimmed 3.3.5 in preparation for turning it into a
discussion about NSIS layering boundaries.
12.Clarified in section 4.2 that peer determination doesn't have to
be a separate capability, just that it could additionally be done
separately.
13.Fixed some flow identification terminology inconsistencies in
section 5.3.1.
9.2 Changes from draft-hancock-nsis-fw-00.txt This -02 version has been very significantly restructured compared to
the previous version, and a section by section change history is
probably neither possible or useful. Instead, this section lists the
major technical and structural changes.
1. Changed title, document name and dates. 1. The concept of splitting the protocol suite into two layers is
2. Updated references. now introduced much earlier, and the rest of the framework
3. Editorial fix in NSIS Forwarder definition (section 2). restructured around it. In general, the content is supposed to be
4. Revised section 3.2.1 (path-coupled terminology), now used signaling application independent: possibilities for application
consistently in the rest of the document. Likewise, 'signaling dependent behavior are described in section 3.3, and the specific
application' terminology used consistently in remainder of document. case of QoS/resource management is restricted to section 6.1.
5. Split old section 5 into new sections (new 5 "real interactions", 2. Sender and receiver orientation is now assumed to be a signaling
new 7 "how to use NSIS to do something useful"). application protocol property (section 3.3.1), with the NTLP by
default operating bidirectionally (section 3.2.3). As a
consequence, the initiator, forwarder, and responder concepts
only appear in the later sections.
3. In general, the NTLP is now a 'thinner' layer than previously
envisaged (e.g. without specific reserve/tear messages), and so
the possible inter-layer coupling with the NSLP is much reduced.
However, the option of the NTLP providing some kind of generic
state management service is still an open issue (section 3.4.2).
4. In general, authorisation issues are still handled by the NSLP,
including the question of which network entities are allowed to
modify network state. In particular, the issue of 'session'
(previously 'reservation') ownership (section 3.1.4) is assumed
to be handled by the NSLP level, although session identification
is still visible to the NTLP (section 4.5.2). The implication is
that most key aspects of mobility support (section 5.2) are now
NSLP responsibilities.
6. Added new resource management text for section 5.1; slight 5. Both peer-peer and end-to-end addressing modes are assumed to be
smoothing to balance centralized and distributed, and comment on needed for the NTLP, and any choice between them is a protocol
NI/NF/NR distinction. design issue (not visible externally).
7. Added VRRP placeholder in routing section of section 5 (5.2.5).
8. Added section 5.4 on NSIS/NAT interactions based on Melinda's
email.
9. Added new text for resource management in section 7.2; slightly
trimmed and made clearer that it is mainly discussing the centralized
case (and isn't specific to the inter-domain case). Comment that it's
OK to use the Q-word here since we aren't talking about the NSIS
protocol but a use of the NSIS protocol.
10. Added section 7.3 for discussion of how NSIS can be used in a
distributed resource management environment.
11. Added a placeholder in section 7.4 for use of NSIS for midcom
(no technical content, but references to the midcom requirements and
the TIST and NEC drafts).
12. Moved open issues from section 3.3.1 to new section 8 (left
assumptions behind).
13. Added this changes section 9.
References References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Brunner, M., "Requirements for QoS Signaling Protocols", draft- 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Brunner, M., "Requirements for QoS Signaling Protocols", draft-
ietf-nsis-req-05.txt (work in progress), November 2002 ietf-nsis-req-05.txt (work in progress), November 2002
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 4 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
Levels", BCP 14, RFC 2119, March 1997 ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997
4 Manner, J. and X. Fu, "Analysis of Existing Quality of Service 5 Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile
Signaling Protocols", draft-ietf-nsis-signalling-analysis-00.txt IP", draft-ietf-mobileip-qos-requirements-03.txt (work in
(work in progress), October 2002 progress), July 2002
5 Tschofenig, H., "NSIS Threats", draft-ietf-nsis-threats-00.txt 6 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
(work in progress), October 2002 Communications (midcom) Protocol Requirements", RFC 3304, August
2002
6 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 7 Manner, J. and X. Fu, "Analysis of Existing Quality of Service
Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txt
(work in progress), February 2003
7 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 8 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-
October 1999 thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002
8 Braden, R., and B. Lindell, "A Two-Level Architecture for Internet 9 Braden, R., and B. Lindell, "A Two-Level Architecture for Internet
Signaling", draft-braden-2level-signaling-01.txt (work in Signaling", draft-braden-2level-signaling-01.txt (work in
progress), November 2002 progress), November 2002
9 Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream
Control Transmission Protocol", RFC 2960, October 2000
10 Kent, S., R. Atkinson, "Security Architecture for the Internet 10 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security
Protocol", RFC 2401, November 1998 Considerations", draft-iab-sec-cons-03.txt (work in progress),
January 2003
11 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework 11 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne,
for Edge-to Edge NSIS Signaling", draft "NSIS Authentication, Authorization and Accounting Issues", draft-
- -westberg-nsis-edge-edge- tschofenig-nsis-aaa-issues-00.txt (work in progress), February
framework-00.txt (work in progress), May 2002 2003
12 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-01.txt (work in progress), January 2003
12 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 13 Katz, D., "IP Router Alert Option", RFC 2113, February 1997
14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,
October 1999
15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda,
T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC
2676, August 1999 2676, August 1999
13 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995 1771, March 1995
14 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 17 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
draft-ietf-idr-bgp4-17.txt (work in progress), January 2002 draft-ietf-idr-bgp4-17.txt (work in progress), January 2002
(expired) (expired)
15 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of 18 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of
Multiple Paths in BGP", draft-walton-bgp-add-paths-00.txt (work in Multiple Paths in BGP", draft-walton-bgp-add-paths-01.txt (work in
progress), May 2002 progress), November 2002
16 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service
Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft-
jacquenet-qos-nlri-04.txt (work in progress), March 2002 (expired)
17 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White,
"Controlling the redistribution of BGP Routes", draft-bonaventure-
bgp-redistribution-02.txt (work in progress), February 2002
(expired)
18 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997
19 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D. 19 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,
Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management
in Diffserv (RMD) Framework", draft-westberg-rmd-framework-02.txt
(work in progress), October 2002
20 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
21 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-
thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002 thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002
22 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource 21 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource
Reservation Issues in Cellular Radio Access Networks", draft- Reservation Issues in Cellular Radio Access Networks", draft-
westberg-rmd-cellular-issues-01.txt (work in progress), June 2002 westberg-rmd-cellular-issues-01.txt (work in progress), June 2002
23 Shen, C. et al., "An Interoperation Framework for Using RSVP in 22 Shen, C. et al., "An Interoperation Framework for Using RSVP in
Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt
(work in progress), July 2001 (expired) (work in progress), July 2001 (expired)
24 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt 23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt
(work in progress), May 2002 (work in progress), January 2003
25 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile
IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March
2001 (expired) 2001 (expired)
25 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile
26 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile
IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress), IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress),
January 2002 (expired) January 2002 (expired)
27 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6 26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6
Networks", draft-kan-qos-framework-01.txt (work in progress), July Networks", draft-kan-qos-framework-01.txt (work in progress), July
2002 2002
28 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 27 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in
candidate access router discovery for seamless IP-level handoffs", candidate access router discovery for seamless IP-level handoffs",
draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress),
October 2002 October 2002
29 Kempf, J., "Problem Description: Reasons For Performing Context 28 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
30 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 29 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999 (NAT) Terminology and Considerations", RFC2663, August 1999
31 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 30 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC2765, February 2000 RFC2765, February 2000
32 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
31 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
Traversal of UDP Through Network Address Translators", draft-ietf- Traversal of UDP Through Network Address Translators", draft-ietf-
midcom-stun-03.txt (work in progress), October 2002 midcom-stun-05.txt (work in progress), December 2002
33 Danny Goderis, et al. "Service Level Specification Semantics and 32 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework
Parameters", draft-tequila-sls-02.txt (work in progress), February for Edge-to-Edge NSIS Signaling", draft-westberg-nsis-edge-edge-
2002 (expired) framework-00.txt (work in progress), May 2002
34 Blake, S., D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 33 Braden, R., D. Clark, S. Shenker, "Integrated Services in the
Architecture for Differentiated Services", RFC2475, December 1998 Internet Architecture: an Overview", RFC 1633, June 1994
35 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 34 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Communications (midcom) Protocol Requirements", RFC3304, August Partain, D., Pop, O., Rexhepi, V., Szabó, R., Takács, A.,
2002 "Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop on
Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002
36 Shore, M., "Towards a Network-friendlier Midcom", draft-shore- 35 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
072, November 1992
36 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet", RFC 2638, July 1999
37 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
38 Shore, M., "Towards a Network-friendlier Midcom", draft-shore-
friendly-midcom-01.txt (work in progress), June 2002 friendly-midcom-01.txt (work in progress), June 2002
37 Shore, M., "The TIST (Topology-Insensitive Service Traversal) 39 Shore, M., "The TIST (Topology-Insensitive Service Traversal)
Protocol", draft-shore-tist-prot-00.txt (work in progress), May Protocol", draft-shore-tist-prot-00.txt (work in progress), May
2002 2002
38 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS 40 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS
Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in
progress), June 2002 progress), June 2002
Acknowledgments Acknowledgments
The authors would like to thank Anders Bergsten, Bob Braden, Maarten The authors would like to thank Anders Bergsten, Bob Braden, Maarten
Buchli, Melinda Shore and Hannes Tschofenig for significant Buchli, Eleanor Hepworth, 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 Marcus Brunner, Danny Goderis, addition, the authors would like to acknowledge Cedric Aoun, Marcus
Eleanor Hepworth, Cornelia Kappler, Hans De Neve, David Partain, Brunner, Danny Goderis, Cornelia Kappler, Mac McTiffin, Hans De Neve,
Vlora Rexhepi, and Lars Westberg for insights and inputs during this David Partain, Vlora Rexhepi, Henning Schulzrinne and Lars Westberg
and previous framework activities. for insights and inputs during this and previous framework
activities.
Author's Addresses Authors' Addresses
Ilya Freytsis Ilya Freytsis
Cetacean Networks Inc. Cetacean Networks Inc.
100 Arboretum Drive 100 Arboretum Drive
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
email: ifreytsis@cetacean.com email: ifreytsis@cetacean.com
Robert Hancock Robert Hancock
Roke Manor Research Roke Manor Research
Old Salisbury Lane Old Salisbury Lane
Romsey Romsey
Hampshire Hampshire
SO51 0ZN SO51 0ZN
United Kingdom United Kingdom
email: robert.hancock@roke.co.uk email: robert.hancock@roke.co.uk
Georgios Karagiannis Georgios Karagiannis
Ericsson EuroLab Netherlands B.V. Ericsson EuroLab Netherlands B.V.
Institutenweg 25 Institutenweg 25
P.O.Box 645 P.O.Box 645
7500 AP Enschede 7500 AP Enschede
The Netherlands The Netherlands
email: georgios.karagiannis@eln.ericsson.se email: georgios.karagiannis@eln.ericsson.se
John Loughney John Loughney
Nokia Research Center Nokia Research Center
skipping to change at page 52, line 35 skipping to change at page 45, line 26
Finland Finland
email: john.loughney@nokia.com email: john.loughney@nokia.com
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
email: sven.van_den_bosch@alcatel.be email: sven.van_den_bosch@alcatel.be
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2002). 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
skipping to change at line 2441 skipping to change at page 46, line 30
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
Hancock et al. Expires - Septemb
 End of changes. 

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