draft-ietf-nsis-fw-04.txt   draft-ietf-nsis-fw-05.txt 
NSIS Working Group Network Working Group
Internet Draft Robert Hancock (editor) Internet Draft R. Hancock (editor)
Siemens/Roke Manor Research Siemens/Roke Manor Research
Ilya Freytsis I. Freytsis
Cetacean Networks Cetacean Networks
Georgios Karagiannis G. Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
John Loughney J. Loughney
Nokia Nokia
Sven Van den Bosch S. Van den Bosch
Alcatel Alcatel
Document: draft-ietf-nsis-fw-04.txt Document: draft-ietf-nsis-fw-05.txt
Expires: March 2004 September 2003 Expires: April 2004 October 2003
Next Steps in Signaling: Framework Next Steps in Signaling: Framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 21 skipping to change at page 2, line 21
signaling and other network layer functions, specifically routing, signaling and other network layer functions, specifically routing,
mobility, and address translators. The different events that impact mobility, and address translators. The different events that impact
signaling operation are described, along with how their handling signaling operation are described, along with how their handling
should be divided between the generic and application-specific should be divided between the generic and application-specific
layers. Finally, an example signaling application (for Quality of layers. Finally, an example signaling application (for Quality of
Service) is described in more detail. Service) is described in more detail.
Table of Contents Table of Contents
1 Introduction ...................................................3 1 Introduction ...................................................3
1.1 Definition of the NSIS Signaling Problem .................3 1.1 Definition of the Signaling Problem ......................3
1.2 Scope and Structure of the NSIS Framework ................4 1.2 Scope and Structure of the NSIS Framework ................4
2 Terminology ....................................................5 2 Terminology ....................................................5
3 Overview of Signaling Scenarios and Protocol Structure .........6 3 Overview of Signaling Scenarios and Protocol Structure .........6
3.1 Fundamental Signaling Concepts ...........................6 3.1 Fundamental Signaling Concepts ...........................6
3.1.1 Simple Network and Signaling Topology ..................6 3.1.1 Simple Network and Signaling Topology ..................6
3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7 3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7
3.1.3 Signaling to Hosts, Networks and Proxies ...............8 3.1.3 Signaling to Hosts, Networks and Proxies ...............8
3.1.4 Signaling Messages and Network Control State ..........10 3.1.4 Signaling Messages and Network Control State ..........10
3.1.5 Data Flows and Sessions ...............................10 3.1.5 Data Flows and Sessions ...............................10
3.2 Layer Model for the Protocol Suite ......................11 3.2 Layer Model for the Protocol Suite ......................11
skipping to change at page 3, line 22 skipping to change at page 3, line 22
5.1.2 Route Changes .........................................29 5.1.2 Route Changes .........................................29
5.2 Mobility and Multihoming Interactions ...................31 5.2 Mobility and Multihoming Interactions ...................31
5.3 Interactions with NATs ..................................33 5.3 Interactions with NATs ..................................33
5.4 Interactions with IP Tunneling ..........................34 5.4 Interactions with IP Tunneling ..........................34
6 Signaling Applications ........................................35 6 Signaling Applications ........................................35
6.1 Signaling for Quality of Service ........................35 6.1 Signaling for Quality of Service ........................35
6.1.1 Protocol Message Semantics ............................36 6.1.1 Protocol Message Semantics ............................36
6.1.2 State Management ......................................36 6.1.2 State Management ......................................36
6.1.3 Route Changes and QoS Reservations ....................37 6.1.3 Route Changes and QoS Reservations ....................37
6.1.4 Resource Management Interactions ......................38 6.1.4 Resource Management Interactions ......................38
6.2 Other Signaling Applications ............................40 6.2 Other Signaling Applications ............................39
7 Security Considerations .......................................40 7 Security Considerations .......................................40
8 Change History ................................................41 Normative References.............................................41
8.1 Changes from draft-ietf-nsis-fw-03.txt ..................41 Informative References...........................................41
8.2 Changes from draft-ietf-nsis-fw-02.txt ..................42 Acknowledgments..................................................43
8.3 Changes from draft-ietf-nsis-fw-01.txt ..................42 Authors' Addresses...............................................44
References.......................................................43 Intellectual Property Considerations.............................44
Acknowledgments..................................................45 Full Copyright Statement.........................................45
Authors' Addresses...............................................46
Intellectual Property Considerations.............................46
Full Copyright Statement.........................................47
1 Introduction 1 Introduction
1.1 Definition of the NSIS Signaling Problem 1.1 Definition of the Signaling Problem
The NSIS working group is considering protocols for signaling The Next Steps in Signaling (NSIS) working group is considering
information about a data flow along its path in the network. 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 It is assumed that the path taken by the data flow is already
determined by network configuration and routing protocols, determined by network configuration and routing protocols,
independent of the signaling itself; that is, signaling to set up the independent of the signaling itself; that is, signaling to set up the
routes themselves is not considered. Instead, the signaling simply routes themselves is not considered. Instead, the signaling simply
interacts with nodes along the data flow path. Additional interacts with nodes along the data flow path. Additional
simplifications are that the actual signaling messages pass directly simplifications are that the actual signaling messages pass directly
through these nodes themselves (i.e. the 'path-coupled' case, see through these nodes themselves (i.e. the 'path-coupled' case, see
section 3.1.2) and that only unicast data flows are considered. section 3.1.2) and that only unicast data flows are considered.
The signaling problem in this sense is very similar to that addressed The signaling problem in this sense is very similar to that addressed
by RSVP [1]. However, there are two generalizations. Firstly, the by RSVP. However, there are two generalizations. Firstly, the
intention is that components of the NSIS protocol suite will be intention is that components of the NSIS protocol suite will be
usable in different parts of the Internet, for different needs, usable in different parts of the Internet, for different needs,
without requiring a complete end-to-end deployment (in particular, without requiring a complete end-to-end deployment (in particular,
the signaling protocol messages may not need to run all the way the signaling protocol messages may not need to run all the way
between the data flow endpoints). between the data flow endpoints).
Secondly, the signaling is intended for more purposes than just QoS Secondly, the signaling is intended for more purposes than just QoS
(resource reservation). The basic mechanism to achieve this (resource reservation). The basic mechanism to achieve this
flexibility is to divide the signaling protocol stack into two flexibility is to divide the signaling protocol stack into two
layers: a generic (lower) layer, and an upper layer specific to each layers: a generic (lower) layer, and an upper layer specific to each
signaling application. The scope of NSIS work is to define both the signaling application. The scope of NSIS work is to define both the
generic protocol, and initially upper layers suitable for QoS generic protocol, and initially upper layers suitable for QoS
signaling (similar to the corresponding functionality in RSVP) and signaling (similar to the corresponding functionality in RSVP) and
middlebox signaling. Further applications may be considered later. middlebox signaling. Further applications may be considered later.
1.2 Scope and Structure of the NSIS Framework 1.2 Scope and Structure of the NSIS Framework
The underlying requirements for signaling in the context of NSIS are The underlying requirements for signaling in the context of NSIS are
defined in [2] and a separate security threats document [3]; other defined in [1] and a separate security threats document [2]; other
related requirements can be found in [4] and [5]. This framework does related requirements can be found in [3] and [4]. This framework does
not replace or update these requirements. Discussions about lessons not replace or update these requirements. Discussions about lessons
to be learned from existing signaling and resource management to be learned from existing signaling and resource management
protocols are contained in separate analysis documents [6], [7]. protocols are contained in separate analysis documents [5], [6].
The role of this framework is to explain how NSIS signaling should The role of this framework is to explain how NSIS signaling should
work within the broader networking context, and to describe the work within the broader networking context, and to describe the
overall structure of the protocol suite itself. Therefore, it overall structure of the protocol suite itself. Therefore, it
discusses important protocol considerations, such as routing, discusses important protocol considerations, such as routing,
mobility, security, and interactions with network 'resource' mobility, security, and interactions with network 'resource'
management (in the broadest sense). management (in the broadest sense).
The basic context for NSIS protocols is given in section 3. Section The basic context for NSIS protocols is given in section 3. Section
3.1 describes the fundamental elements of NSIS protocol operation in 3.1 describes the fundamental elements of NSIS protocol operation in
comparison to RSVP; in particular, section 3.1.3 describes more comparison to RSVP [7]; in particular, section 3.1.3 describes more
general signaling scenarios, and 3.1.4 defines a broader class of general signaling scenarios, and 3.1.4 defines a broader class of
signaling applications for which the NSIS protocols should be useful. signaling applications for which the NSIS protocols should be useful.
The two-layer protocol architecture that supports this generality is The two-layer protocol architecture that supports this generality is
described in section 3.2, and section 3.3 gives examples of the ways described in section 3.2, and section 3.3 gives examples of the ways
in which particular signaling application properties can be in which particular signaling application properties can be
accommodated within signaling layer protocol behavior. accommodated within signaling layer protocol behavior.
The overall functionality required from the lower (generic) protocol The overall functionality required from the lower (generic) protocol
layer is described in section 4. This is not intended to define the layer is described in section 4. This is not intended to define the
detailed design of the protocol or even design options, although some detailed design of the protocol or even design options, although some
skipping to change at page 11, line 9 skipping to change at page 11, line 9
The simplest service provided by NSIS signaling protocols is The simplest service provided by NSIS signaling protocols is
management of network control state at the level of a specific flow, management of network control state at the level of a specific flow,
as described in the previous subsection. In particular, it should be as described in the previous subsection. In particular, it should be
possible to monitor routing updates as they change the path taken by possible to monitor routing updates as they change the path taken by
a flow and, for example, update network state appropriately. This is a flow and, for example, update network state appropriately. This is
no different from the case for RSVP (local path repair). Where there no different from the case for RSVP (local path repair). Where there
is a 1:1 flow:session relationship, this is all that is required. is a 1:1 flow:session relationship, this is all that is required.
However, for some more complex scenarios (especially mobility and However, for some more complex scenarios (especially mobility and
multihoming related ones, see [2] and the mobility discussion of [6]) multihoming related ones, see [1] and the mobility discussion of [5])
it is desirable to update the flow:session mapping during the session it is desirable to update the flow:session mapping during the session
lifetime. For example, a new flow can be added, and the old one lifetime. For example, a new flow can be added, and the old one
deleted (and maybe in that order, for a 'make-before-break' deleted (and maybe in that order, for a 'make-before-break'
handover), effectively transferring the network control state between handover), effectively transferring the network control state between
data flows to keep it associated with the same session. Such updates data flows to keep it associated with the same session. Such updates
are best managed by the end systems (generally, systems which are best managed by the end systems (generally, systems which
understand the flow:session mapping and are aware of the packet understand the flow:session mapping and are aware of the packet
classifier change). To enable this, it must be possible to relate classifier change). To enable this, it must be possible to relate
signaling messages to sessions as well as data flows. A session signaling messages to sessions as well as data flows. A session
identifier (section 4.6.2) is one component of the solution. identifier (section 4.6.2) is one component of the solution.
skipping to change at page 23, line 19 skipping to change at page 23, line 19
using some local routing table or through participation in active using some local routing table or through participation in active
peer discovery message exchanges. Peer-peer addressing inherently peer discovery message exchanges. Peer-peer addressing inherently
supports tunneling of messages between NEs, and is equally applicable supports tunneling of messages between NEs, and is equally applicable
to the path-coupled and path-decoupled cases. to the path-coupled and path-decoupled cases.
In the case of end-to-end addressing, the message is addressed to the In the case of end-to-end addressing, the message is addressed to the
data flow receiver, and (some of) the NEs along the data path data flow receiver, and (some of) the NEs along the data path
intercept the messages. The routing of the messages should follow intercept the messages. The routing of the messages should follow
exactly the same path as the associated data flow (but see section exactly the same path as the associated data flow (but see section
5.1.1 on this point). Note that securing messages sent this way 5.1.1 on this point). Note that securing messages sent this way
raises some interesting security issues (these are discussed in [3]). raises some interesting security issues (these are discussed in [2]).
It is not possible at this stage to mandate one addressing mode or It is not possible at this stage to mandate one addressing mode or
the other. Indeed, each is necessary for some aspects of NTLP the other. Indeed, each is necessary for some aspects of NTLP
operation: in particular, initial discovery of the next downstream operation: in particular, initial discovery of the next downstream
peer will usually require end-to-end addressing, whereas reverse peer will usually require end-to-end addressing, whereas reverse
routing will always require peer-peer addressing. For other message routing will always require peer-peer addressing. For other message
types, the choice is a matter of protocol design. The mode used is types, the choice is a matter of protocol design. The mode used is
not visible to the NSLP, and the information needed in each case is not visible to the NSLP, and the information needed in each case is
available from the flow identifier (section 4.6.1) or locally stored available from the flow identifier (section 4.6.1) or locally stored
NTLP state. NTLP state.
skipping to change at page 32, line 7 skipping to change at page 32, line 7
for some segments of the data path. for some segments of the data path.
3) The double route may persist for some time in the network (e.g. in 3) The double route may persist for some time in the network (e.g. in
the case of a 'make-before-break' handover being done by a multihomed the case of a 'make-before-break' handover being done by a multihomed
host). host).
4) Conversely, the re-routing may be rapid and routine (unlike 4) Conversely, the re-routing may be rapid and routine (unlike
network internal route changes), increasing the importance of rapid network internal route changes), increasing the importance of rapid
state release on old paths. state release on old paths.
The interactions between mobility and signaling have been extensively The interactions between mobility and signaling have been extensively
analyzed in recent years, primarily in the context of RSVP and Mobile analyzed in recent years, primarily in the context of RSVP and Mobile
IP interaction (e.g. the mobility discussion of [6]), but also in the IP interaction (e.g. the mobility discussion of [5]), but also in the
context of other types of network (e.g. [18]); a general review of context of other types of network (e.g. [18]); a general review of
the fundamental interactions is given in [19], which provides further the fundamental interactions is given in [19], which provides further
details on many of the subjects considered in this section. details on many of the subjects considered in this section.
We are assuming that the signaling will refer to 'outer' IP headers We are assuming that the signaling will refer to 'outer' IP headers
when defining the flows it is controlling. There two main reasons for when defining the flows it is controlling. There two main reasons for
this. The first is that the data plane will usually be unable to work this. The first is that the data plane will usually be unable to work
in terms of anything else when implementing per-flow treatment (e.g. in terms of anything else when implementing per-flow treatment (e.g.
we cannot expect a router will analyse inner headers to decide how to we cannot expect a router will analyse inner headers to decide how to
schedule packets). The second reason is that we are implicitly schedule packets). The second reason is that we are implicitly
skipping to change at page 35, line 13 skipping to change at page 35, line 13
needs to be the ability to provide a binding between the original needs to be the ability to provide a binding between the original
flow identification and that for the tunneled flow. It is left open flow identification and that for the tunneled flow. It is left open
here whether this should be an NTLP or an NSLP function. here whether this should be an NTLP or an NSLP function.
6 Signaling Applications 6 Signaling Applications
This section gives an overview of NSLPs for particular signaling This section gives an overview of NSLPs for particular signaling
applications. The assumption is that the NSLP uses the generic applications. The assumption is that the NSLP uses the generic
functionality of the NTLP given earlier; this section describes functionality of the NTLP given earlier; this section describes
specific aspects of NSLP operation. It is intended to clarify by specific aspects of NSLP operation. It is intended to clarify by
example how NSLPs fit into the framework; formal NSLP protocol simple examples how NSLPs fit into the framework. It does not replace
designs will be contained in separate documents. or even form part of the formal NSLP protocol specifications; in
particular, initial designs are being developed for NSLPs for
resource reservation [27] and middlebox communication [28].
6.1 Signaling for Quality of Service 6.1 Signaling for Quality of Service
In the case of signaling for QoS, all the basic NSIS concepts of In the case of signaling for QoS, all the basic NSIS concepts of
section 3.1 apply. In addition, there is an assumed directionality of section 3.1 apply. In addition, there is an assumed directionality of
the signaling process, in that one end of the signaling flow takes the signaling process, in that one end of the signaling flow takes
responsibility for actually requesting the resource. This leads to responsibility for actually requesting the resource. This leads to
the following definitions: the following definitions:
*) QoS NSIS Initiator (QNI): the signaling entity which makes the *) QoS NSIS Initiator (QNI): the signaling entity which makes the
resource request, usually as a result of user application request. resource request, usually as a result of user application request.
skipping to change at page 36, line 23 skipping to change at page 36, line 23
exchanging messages to set up resources for a flow across a it. Note exchanging messages to set up resources for a flow across a it. Note
that it is left open if the responder can release or modify a that it is left open if the responder can release or modify a
reservation, during or after setup. This seems mainly a matter of reservation, during or after setup. This seems mainly a matter of
assumptions about authorization, and the possibilities might depend assumptions about authorization, and the possibilities might depend
on resource type specifics. on resource type specifics.
The table also explicitly includes a refresh operation. This does The table also explicitly includes a refresh operation. This does
nothing to a reservation except extend its lifetime, and is one nothing to a reservation except extend its lifetime, and is one
possible state management mechanism (see next section). possible state management mechanism (see next section).
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Operation |Direction| Semantics | | Operation |Direction| Semantics |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Request | I-->R | Create a new reservation for a flow | | Request | I-->R | Create a new reservation for a flow |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Modify | I-->R | Modify an existing reservation | | Modify | I-->R | Modify an existing reservation |
| |(&R-->I?)| | | |(&R-->I?)| |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Release | I-->R | Delete (tear down) an existing reservation | | Release | I-->R | Delete (tear down) an |
| |(&R-->I?)| | | |(&R-->I?)| existing reservation |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Accept/ | R-->I | Confirm (possibly modified?) or reject a | | Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request | | Reject | | reservation request |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Notify | I-->R & | Report an event detected within the | | Notify | I-->R & | Report an event detected within the |
| | R-->I | network | | | R-->I | network |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
| Refresh | I-->R | State management (see section 6.1.2) | | Refresh | I-->R | State management (see section 6.1.2) |
+-----------+---------+--------------------------------------------+ +-----------+---------+------------------------------------------+
6.1.2 State Management 6.1.2 State Management
The prime purpose of NSIS is to manage state information along the The prime purpose of NSIS is to manage state information along the
path taken by a data flow. The issues regarding state management path taken by a data flow. The issues regarding state management
within the NTLP (state related to message transport) are described in within the NTLP (state related to message transport) are described in
section 4. The QoS NSLP will typically have to handle additional section 4. The QoS NSLP will typically have to handle additional
state related to the desired resource reservation to be made. state related to the desired resource reservation to be made.
There two critical issues to be considered in building a robust NSLP There two critical issues to be considered in building a robust NSLP
to handle this problem: to handle this problem:
*) The protocol must be scalable. It should allow minimization of the *) The protocol must be scalable. It should allow minimization of the
resource reservation state storage demands that it implies for resource reservation state storage demands that it implies for
intermediate nodes; in particular, storage of state per 'micro' flow intermediate nodes; in particular, storage of state per 'micro' flow
is likely to be impossible except at the very edge of the network. A is likely to be impossible except at the very edge of the network. A
QoS signaling application might require per flow or lower granularity QoS signaling application might require per flow or lower granularity
state; examples of each for the case of QoS would be IntServ [27] or state; examples of each for the case of QoS would be IntServ [29] or
RMD [28] (per 'class' state) respectively. RMD [30] (per 'class' state) respectively.
*) The protocol must be robust against failure and other conditions, *) The protocol must be robust against failure and other conditions,
which imply that the stored resource reservation state has to be which imply that the stored resource reservation state has to be
moved or removed. moved or removed.
For resource reservations, soft state management is typically used as For resource reservations, soft state management is typically used as
a general robustness mechanism. According to the discussion of a general robustness mechanism. According to the discussion of
section 3.2.5, the soft state protocol mechanisms are built into the section 3.2.5, the soft state protocol mechanisms are built into the
NSLP for the specific signaling application that needs them; the NTLP NSLP for the specific signaling application that needs them; the NTLP
sees this simply as a sequence of (presumably identical) messages. sees this simply as a sequence of (presumably identical) messages.
6.1.3 Route Changes and QoS Reservations 6.1.3 Route Changes and QoS Reservations
In this section, we will explore the expected interaction between In this section, we will explore the expected interaction between
resource signaling and routing updates (the precise source of routing resource signaling and routing updates (the precise source of routing
updates does not matter). The normal operation of the NSIS protocol updates does not matter). The normal operation of the NSIS protocol
will lead to the situation depicted in Figure 7, where the reserved will lead to the situation depicted in Figure 7, where the reserved
resources match the data path. resources match the data path.
reserved +-----+ reserved +-----+ reserved +-----+ reserved +-----+
------->| QNF |----------->| QNF | =========>| QNF |===========>| QNF |
+-----+ +-----+ +-----+ +-----+
======================================= --------------------------------------->
data path data path
Figure 7: Normal NSIS protocol operation Figure 7: Normal NSIS protocol operation
A route change can occur while such a reservation is in place. The A route change can occur while such a reservation is in place. The
route change will be installed immediately and any data will be route change will be installed immediately and any data will be
forwarded on the new path. This situation is depicted Figure 8. forwarded on the new path. This situation is depicted Figure 8.
Route update
|
v
reserved +-----+ reserved +-----+
------->| QNF |----------->| QNF |
+-----+ +-----+
========== |
|| | +-----+
|| +---------->| QNF |
|| +-----+
============================
data path
Figure 8: Route Change
Resource reservation on the new path will only be started once the Resource reservation on the new path will only be started once the
next control message is routed along the new path. This means that next control message is routed along the new path. This means that
there is a certain time interval during which resources are not there is a certain time interval during which resources are not
reserved on (part of) the data path. To minimize this time interval reserved on (part of) the data path. To minimize this time interval
several techniques could be considered. As an example, RSVP [1] has several techniques could be considered. As an example, RSVP [7] has
the concept of local repair, where the router may be triggered by a the concept of local repair, where the router may be triggered by a
route change. In that case the RSVP node can start sending PATH route change. In that case the RSVP node can start sending PATH
messages directly after the route has been changed. Note that this messages directly after the route has been changed. Note that this
option may not be available if no per-flow state is kept in the NF. option may not be available if no per-flow state is kept in the NF.
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Figure 8: Route Change
It is not guaranteed that the new path will be able to provide the It is not guaranteed that the new path will be able to provide the
same guarantees that were available on the old path. Therefore, in a same guarantees that were available on the old path. Therefore, in a
more desirable scenario, the QNF should wait until resources have more desirable scenario, the QNF should wait until resources have
been reserved on the new path before installing the route change been reserved on the new path before installing the route change
(unless of course the old path no longer exists). The route change (unless of course the old path no longer exists). The route change
procedure then consists of the following steps: procedure then consists of the following steps:
1. QNF receives a route announcement, 1. QNF receives a route announcement,
2. Refresh messages are forwarded along the current path, 2. Refresh messages are forwarded along the current path,
3. A copy of the refresh message is re-marked as a request and sent 3. A copy of the refresh message is re-marked as a request and sent
along the new path that was announced, along the new path that was announced,
4. When the QNF has been acknowledged about the reservations on the 4. When the QNF has been acknowledged about the reservations on the
new path, the route will be installed and data will flow along it. new path, the route will be installed and data will flow along it.
Another example related to route changes is denoted as severe Another example related to route changes is denoted as severe
congestion and is explained in [28]. This solution adapts to a route congestion and is explained in [30]. This solution adapts to a route
change, when a route change creates congestion on the new routed change, when a route change creates congestion on the new routed
path. path.
6.1.4 Resource Management Interactions 6.1.4 Resource Management Interactions
The QoS NSLP itself is not involved in any specific resource The QoS NSLP itself is not involved in any specific resource
allocation or management techniques. The definition of an NSLP for allocation or management techniques. The definition of an NSLP for
resource reservation with Quality of Service, however, implies the resource reservation with Quality of Service, however, implies the
notion of admission control. For a QoS NSLP, the measure of signaling notion of admission control. For a QoS NSLP, the measure of signaling
success will be the ability to reserve resources from the total success will be the ability to reserve resources from the total
skipping to change at page 39, line 23 skipping to change at page 39, line 13
provide inputs for admission control. In this model, the RMF acts as provide inputs for admission control. In this model, the RMF acts as
a server towards client NSLP(s). It is noted, however, that the RMF a server towards client NSLP(s). It is noted, however, that the RMF
may in turn use another NSLP instance to do the actual resource may in turn use another NSLP instance to do the actual resource
provisioning in the network. In this case, the RMF acts as the provisioning in the network. In this case, the RMF acts as the
initiator (client) of an NSLP. initiator (client) of an NSLP.
This essentially corresponds to a multi-level signaling paradigm, This essentially corresponds to a multi-level signaling paradigm,
with an 'upper' level handling internetworking QoS signaling, with an 'upper' level handling internetworking QoS signaling,
possibly running end-to-end, and a 'lower' level handling the more possibly running end-to-end, and a 'lower' level handling the more
specialized intradomain QoS signaling, running between just the edges specialized intradomain QoS signaling, running between just the edges
of the network (see [10], [29], and [30] for a discussion of similar of the network (see [10], [31], and [32] for a discussion of similar
architectures). Given that NSIS signaling is already supposed to be architectures). Given that NSIS signaling is already supposed to be
able to support multiple instances of NSLPs for a given flow, and able to support multiple instances of NSLPs for a given flow, and
limited scope (e.g. edge-to-edge) operation, it is not currently limited scope (e.g. edge-to-edge) operation, it is not currently
clear that supporting the multi-level model leads to any new protocol clear that supporting the multi-level model leads to any new protocol
requirements for the QoS NSLP. requirements for the QoS NSLP.
The RMF may or may not be co-located with a QNF (note that co- The RMF may or may not be co-located with a QNF (note that co-
location with a QNI/QNR can be handled logically as a combination location with a QNI/QNR can be handled logically as a combination
between QNF and QNI/QNR). To cater for both cases, we define a between QNF and QNI/QNR). To cater for both cases, we define a
(possibly logical) NF-RMF interface. Over this interface, information (possibly logical) NF-RMF interface. Over this interface, information
skipping to change at page 40, line 12 skipping to change at page 39, line 48
deployment or upgrade of policies. Distribution allows local decision deployment or upgrade of policies. Distribution allows local decision
processes and rapid response to data path changes. processes and rapid response to data path changes.
6.2 Other Signaling Applications 6.2 Other Signaling Applications
As well as the use for 'traditional' QoS signaling, it should be As well as the use for 'traditional' QoS signaling, it should be
possible to develop NSLPs for other signaling applications which possible to develop NSLPs for other signaling applications which
operate on different types of network control state. One specific operate on different types of network control state. One specific
case is setting up flow-related state in middleboxes (firewalls, case is setting up flow-related state in middleboxes (firewalls,
NATs, and so on). Requirements for such communication are given in NATs, and so on). Requirements for such communication are given in
[5], and initial discussions of NSIS-like solutions are contained in [4]. Other examples include network monitoring and testing, and
[31] and [32]. Other examples include network monitoring and testing, tunnel endpoint discovery.
and tunnel endpoint discovery.
7 Security Considerations 7 Security Considerations
This document describes a framework for signaling protocols which This document describes a framework for signaling protocols which
assumes a two-layer decomposition, with a common lower layer (NTLP) assumes a two-layer decomposition, with a common lower layer (NTLP)
supporting a family of signaling application specific upper layer supporting a family of signaling application specific upper layer
protocols (NSLPs). The overall security considerations for the protocols (NSLPs). The overall security considerations for the
signaling therefore depend on the joint security properties assumed signaling therefore depend on the joint security properties assumed
or demanded for each layer. or demanded for each layer.
skipping to change at page 41, line 13 skipping to change at page 40, line 51
this identifier is to decouple session identification (as a handle this identifier is to decouple session identification (as a handle
for network control state) from session "location" (i.e. the data for network control state) from session "location" (i.e. the data
flow endpoints). The identifier/locator distinction has been flow endpoints). The identifier/locator distinction has been
extensively discussed in the user plane for end to end data flows, extensively discussed in the user plane for end to end data flows,
and is known to lead to non-trivial security issues in binding the and is known to lead to non-trivial security issues in binding the
two together again; our problem is the analogue in the control plane, two together again; our problem is the analogue in the control plane,
and is at least similarly complex, because of the need to involve and is at least similarly complex, because of the need to involve
nodes in the interior of the network as well. nodes in the interior of the network as well.
Further work on this and other security design will depend on a Further work on this and other security design will depend on a
refinement of the NSIS threats work begun in [3]. refinement of the NSIS threats work begun in [2].
8 Change History
[Editor's note: this section to be removed in final published
version.]
8.1 Changes from draft-ietf-nsis-fw-03.txt
1. Added new general section (using part of old content of 3.2.1)
about how to handle intermediate nodes which don't really want to
process some signaling application messages fully (new section
3.2.3).
2. Added a new section outlining where responsibility for
aggregation is placed within the layer split (section 3.3.4).
3. Closed the issue about reliability by saying that the NTLP must
provide the ability to deliver a message reliably but that this
doesn't mean the same thing as hard state or guaranteed execution
at the receiver - essentially the conclusions from draft-hancock-
nsis-reliability-00.txt (section 4.3).
4. Removed the issue about summary refreshes (section 4.3), allowing
the NSLP to do it by choice and leaving open extension of the
NTLP to do more general lower layer compression.
5. Included small notes on route change interactions and layer split
assumption, including merging in of VRRP considerations; also
some general text tidying (section 5.1.2).
6. Radically shortened and updated the mobility discussion (section
5.2), outlining the layer split assumption but removing most of
the analysis and justification, in the hope that a separate
document will eventually cover this area.
7. Included new section on tunnel handling (section 5.4).
8. Removed most of the detailed discussion of QoS routing and BGP
from section 6.1. Updated terminology in line with current QoS-
NSLP design work, and clarified that this is not actually the
official protocol design.
9. Updated references and fixed a number of minor typos.
8.2 Changes from draft-ietf-nsis-fw-02.txt
1. Re-instated 'long' definition of path-coupled from -01 version
(section 3.1.2).
2. Moved NTLP open issues (transport and state management
functionality) to section 3.2.5 and 4.3, and closed several of
them: NTLP does bundling and fragmentation, but is ignorant of
NSLP state and vice versa. However, added a new open issue on
message summarization.
3. Updated section 5.2 and elsewhere to refer to the WG draft on
mobility/RSVP analysis and an external review paper. Updated
section 6.2 with references to more recent work on path-coupled
signaling to middleboxes. General tidying of other references.
8.3 Changes from draft-ietf-nsis-fw-01.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. The concept of splitting the protocol suite into two layers is
now introduced much earlier, and the rest of the framework
restructured around it. In general, the content is supposed to be
signaling application independent: possibilities for application
dependent behavior are described in section 3.3, and the specific
case of QoS/resource management is restricted to section 6.1.
2. Sender and receiver orientation is now assumed to be a signaling
application protocol property (section 3.3.1), with the NTLP by
default operating bidirectionally (section 3.2.4). 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.
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.5) is assumed
to be handled by the NSLP level, although session identification
is still visible to the NTLP (section 4.6.2). The implication is
that most key aspects of mobility support (section 5.2) are now
NSLP responsibilities.
5. Both peer-peer and end-to-end addressing modes are assumed to be
needed for the NTLP, and any choice between them is a protocol
design issue (not visible externally).
References
[Editor's note: in a future version, these will be split as Normative
and Informative.]
1 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource Normative References
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997
2 Brunner, M., "Requirements for Signaling Protocols", draft-ietf- 1 Brunner, M., "Requirements for Signaling Protocols", draft-ietf-
nsis-req-09.txt (work in progress), August 2003 nsis-req-09.txt (work in progress), August 2003
3 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-02.txt (work in progress), June 2003 draft-ietf-nsis-threats-02.txt (work in progress), June 2003
4 Chaskar, H. (editor), " Requirements of a Quality of Service (QoS) 3 Chaskar, H. (editor), " Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003 Solution for Mobile IP", RFC 3583, September 2003
5 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 4 Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M. Shore,
Communications (midcom) Protocol Requirements", RFC 3304, August "Middlebox Communications (midcom) Protocol Requirements", RFC
2002 3304, August 2002
6 Manner, J., X. Fu, P. Pan, "Analysis of Existing Quality of Informative References
5 Manner, J., Fu, X. and P. Pan, "Analysis of Existing Quality of
Service Signaling Protocols", draft-ietf-nsis-signalling-analysis- Service Signaling Protocols", draft-ietf-nsis-signalling-analysis-
02.txt (work in progress), June 2003 02.txt (work in progress), June 2003
7 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp- 6 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp-
sec-properties-02.txt (work in progress), June 2003 sec-properties-02.txt (work in progress), June 2003
7 Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997
8 Katz, D., "IP Router Alert Option", RFC2113, February 1997 8 Katz, D., "IP Router Alert Option", RFC2113, February 1997
9 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 9 Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
October 1999 2711, October 1999
10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 10 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001
11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, July 2003 Security Considerations", BCP 72, RFC 3552, July 2003
12 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, 12 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne,
"NSIS Authentication, Authorization and Accounting Issues", draft- "NSIS Authentication, Authorization and Accounting Issues", draft-
tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003 tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003
13 Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC2961,
April 2001
13 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, 14 Ji, P., Ge, Z., Kurose, J. and D. Townsley, "A Comparison of Hard-
"RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001 State and Soft-State Signaling Protocols", Computer Communication
14 Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State
and Soft-State Signaling Protocols", Computer Communication
Review, Volume 33, Number 4, October 2003 Review, Volume 33, Number 4, October 2003
15 Floyd, S., "Congestion Control Principles", RFC 2914, September 15 Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
2000 September 2000
16 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 16 Apostolopoulos, G., Williams, D., Kamat, S., Guerin, R., Orda, A.
T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions",
2676, August 1999 RFC 2676, August 1999
17 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, 17 Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt,
P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy P., Higginson, P., Shand, M. and A. Lindem, "Virtual Router
Protocol", RFC2338, April 1998 Redundancy Protocol", RFC2338, April 1998
18 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ 18 Heijenk, G., Karagiannis, G., Rexhepi, V. and L. Westberg,
Resource Management in IP-based Radio Access Networks", "DiffServ Resource Management in IP-based Radio Access Networks",
Proceedings of 4th International Symposium on Wireless Personal Proceedings of 4th International Symposium on Wireless Personal
Multimedia Communications-WPMC'01, September 9 - 12, 2001 Multimedia Communications-WPMC'01, September 9 - 12, 2001
19 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y. 19 Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E.
Khouaja, "Evaluation of Mobility and QoS Interaction", Computer and Y. Khouaja, "Evaluation of Mobility and QoS Interaction",
Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163 Computer Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163
20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6", 20 Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003 draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003
21 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 21 Trossen, D., Krishnamurthi, G., Chaskar, H. and J. Kempf, "Issues
candidate access router discovery for seamless IP-level handoffs", in candidate access router discovery for seamless IP-level
draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt (work in
October 2002 progress), October 2002
22 Kempf, J., "Problem Description: Reasons For Performing Context 22 Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC3374, Transfers Between Nodes in an IP Access Network", RFC3374,
September 2002 September 2002
23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999 (NAT) Terminology and Considerations", RFC2663, August 1999
24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC2765, February 2000 RFC2765, February 2000
25 Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC3489, March 2003
25 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 26 Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Traversal of User Datagram Protocol (UDP) Through Network Address Operation Over IP Tunnels", RFC 2746, January 2000
Translators (NATs)", RFC3489, March 2003
26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation
Over IP Tunnels", RFC 2746, January 2000
27 Braden, R., D. Clark, S. Shenker, "Integrated Services in the 27 Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of- -
Service Signaling", draft ietf-nsis-qos-nslp-00.txt
(work in progress), September 2003
28 Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-
nsis-nslp-natfw-00 (work in progress), October 2003
29 Braden, R., Clark, D. and S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994 Internet Architecture: an Overview", RFC 1633, June 1994
28 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 30 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Partain, D., Pop, O., Rexhepi, V., Szabo, R., Takacs, A., Partain, D., Pop, O., Rexhepi, V., Szabo, R. and A. Takacs,
"Resource Management in Diffserv (RMD): A Functionality and "Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop on Performance Behavior Overview", Seventh International Workshop on
Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002
29 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for 31 Ferrari, D., Banerjea, A. and H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
072, November 1992 072, November 1992
30 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated 32 Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet", RFC 2638, July 1999 Services Architecture for the Internet", RFC 2638, July 1999
31 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.
Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and Framework",
draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003
32 Aoun, C., "NSIS Network Address Translator implications", draft-
aoun-nsis-nat-imps-01.txt (work in progress), March 2003
Acknowledgments Acknowledgments
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for
significant contributions in particular areas of this draft. In significant contributions in particular areas of this draft. In
addition, the authors would like to acknowledge Cedric Aoun, Attila addition, the authors would like to acknowledge Cedric Aoun, Attila
Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung
Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve,
 End of changes. 

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