draft-ietf-nsis-fw-00.txt   draft-ietf-nsis-fw-01.txt 
NSIS Working Group NSIS Working Group
Internet Draft Ilya Freytsis Internet Draft Robert Hancock (editor)
Cetacean Networks
Robert Hancock
Siemens/Roke Manor Research Siemens/Roke Manor Research
Ilya Freytsis
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-00.txt Document: draft-ietf-nsis-fw-01.txt
Expires: April 2003 October 2002 Expires: May 2003 November 2002
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 48 skipping to change at page 1, line 48
Abstract Abstract
The NSIS working group is considering protocols for signaling for The NSIS working group is considering protocols for signaling for
resources for a traffic flow along its path in the network. The resources for a traffic flow along its path in the network. The
requirements for such signaling are being developed in [2]; this requirements for such signaling are being developed in [2]; this
Internet Draft will propose a framework for such signaling. Internet Draft will propose a framework for such signaling.
This initial version provides a model of the entities that take part This initial version provides a model of the entities that take part
in the signaling. It discusses the considerations that must be taken in the signaling. It discusses the considerations that must be taken
into account in developing the framework, particularly the structural into account in developing the framework, particularly the options
options for the structure of such a protocol, and the interactions for the structure of such a protocol, and the interactions between
between NSIS and other protocols and functions, including security NSIS and other protocols and functions, including security issues.
issues. Finally, it includes background material on how NSIS could
support particular signaling applications. Finally, it includes background material on how NSIS could support
particular signaling applications.
It is expected that future versions of this document will distill It is expected that future versions of this document will distill
these structural options into a concrete technical framework, and these structural options into a concrete technical framework, and
material on particular signaling applications and deployment material on particular signaling applications and deployment
scenarios will be moved into separate NSIS applicability statements. scenarios will be moved into separate NSIS applicability statements.
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 [3].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1 Scope of this Document .....................................4 1.1 Scope of the NSIS Framework ................................4
2. Terminology....................................................4 2. Terminology....................................................5
3. Overall Framework Structure....................................6 3. Overall Framework Structure....................................6
3.1 Basic Signaling Entities and Interfaces ....................6 3.1 Basic Signaling Entities and Interfaces ....................6
3.1.1 NSIS Entities ..........................................6 3.1.1 NSIS Entities ..........................................6
3.1.2 Placement of NSIS entities .............................7 3.1.2 Placement of NSIS Entities .............................8
3.2 Modes of Operation .........................................8 3.1.3 NSIS Protocol Components ...............................9
3.2.1 Path-Coupled and Path-Decoupled Signaling ..............8 3.2 Options for Modes of NSIS Operation .......................10
3.2.2 Inter-domain and Intra-domain Signaling ................9 3.2.1 Path-Coupled and Path-Decoupled Signaling .............10
3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge .............10 3.2.2 Inter-domain and Intra-domain Signaling ...............11
3.2.4 Global and Local Operation ............................10 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge .............12
3.2.5 Multicast versus Unicast ..............................11 3.2.4 Global and Local Operation ............................12
3.2.6 Sender versus Receiver Initiated Signaling ............11 3.2.5 Multicast versus Unicast ..............................13
3.2.7 Uni-Directional and Bi-Directional Reservations .......12 3.2.6 Sender versus Receiver Initiated Signaling ............13
3.3 Basic Assumptions and Conceptual Issues ...................13 3.2.7 Uni-Directional and Bi-Directional Reservations .......14
3.3.1 Basic Assumptions .....................................13 3.3 Basic Assumptions and Conceptual Issues ...................15
3.3.2 NI, NF, NR functionality ..............................13 3.3.1 Basic Assumptions .....................................15
3.3.3 NI, NF, NR relationship ...............................13 3.3.2 NI, NF, NR functionality ..............................15
3.3.4 NSIS Addressing .......................................14 3.3.3 NI, NF, NR relationship ...............................16
3.3.5 Service description ...................................15 3.3.4 NSIS Addressing .......................................16
3.3.6 NSIS Acknowledgement and Notification Semantics .......15 3.3.5 NSIS Layer Boundaries .................................17
4. Protocol Components...........................................15 3.3.6 NSIS Acknowledgement and Notification Semantics .......17
4.1 Lower Layer Interfaces ....................................15 4. Protocol Components...........................................18
4.2 Upper Layer Services ......................................16 4.1 Lower Layer Interfaces ....................................18
4.3 Protocol Structure ........................................18 4.2 Upper Layer Services ......................................18
4.3.1 Internal Layering .....................................18 4.3 Protocol Structure ........................................20
4.3.2 Protocol Messages .....................................19 4.3.1 Internal Layering .....................................20
4.4 State Management ..........................................20 4.3.2 Protocol Messages .....................................21
4.5 Identity Elements .........................................21 4.4 State Management ..........................................22
4.5.1 Flow Identification ...................................21 4.5 Identity Elements .........................................24
4.5.2 Reservation Identification ............................22 4.5.1 Flow Identification ...................................24
4.5.3 Signaling Application Identification ..................23 4.5.2 Reservation Identification ............................24
5. NSIS Protocol Interactions....................................23 4.5.3 NSLP Identification ...................................25
5.1 Resource Management Interactions ..........................23 5. NSIS Protocol Interactions....................................25
5.2 IP Routing Interactions ...................................24 5.1 Resource Management Interactions ..........................25
5.2.1 Load Sharing ..........................................25 5.2 IP Routing Interactions ...................................27
5.2.2 QoS Routing ...........................................25 5.2.1 Load Sharing ..........................................27
5.2.3 Route pinning .........................................26 5.2.2 QoS Routing ...........................................28
5.2.4 Route Changes .........................................26 5.2.3 Route pinning .........................................28
5.2.5 Router Redundancy .....................................28 5.2.4 Route Changes .........................................28
5.3 Mobility Interactions .....................................28 5.2.5 Router Redundancy .....................................30
5.3.1 Addressing and Encapsulation ..........................28 5.3 Mobility Interactions .....................................30
5.3.2 Localized Path Repair .................................29 5.3.1 Addressing and Encapsulation ..........................30
5.3.3 Reservation Update on the Unchanged Path ..............30 5.3.2 Localized Path Repair .................................31
5.3.4 Interaction with Mobility Signaling ...................30 5.3.3 Reservation Update on the Unchanged Path ..............32
5.3.5 Interaction with Fast Handoff Support Protocols .......32 5.3.4 Interaction with Mobility Signaling ...................32
5.4 NSIS Interacting with NATs ................................33 5.3.5 Interaction with Fast Handoff Support Protocols .......34
6. Security and AAA Considerations...............................34 5.4 NSIS Interacting with NATs ................................35
6.1 Authentication ............................................34 6. Security and AAA Considerations...............................36
6.2 Authorization .............................................35 6.1 Authentication ............................................36
6.3 Accounting ................................................36 6.2 Authorization .............................................37
6.4 End-to-End vs. Peer-Session Protection ....................37 6.3 Accounting ................................................38
7. NSIS Application Scenarios....................................38 6.4 End-to-End vs. Peer Relationship Protection ...............39
7.1 NSIS and Existing Resource Signaling Protocols ............38 7. NSIS Application Scenarios....................................40
7.2 NSIS Supporting Centralized QoS Resource Management .......39 7.1 NSIS and Existing Resource Signaling Protocols ............40
7.3 NSIS Supporting Distributed Resource Management ...........41 7.2 NSIS Supporting Centralized QoS Resource Management .......41
7.4 NSIS for Middlebox Signaling ..............................41 7.3 NSIS Supporting Distributed Resource Management ...........43
7.5 Multi-Level NSIS Signaling ................................42 7.4 NSIS for Middlebox Signaling ..............................43
8. Open Issues...................................................43 7.5 Multi-Level NSIS Signaling ................................44
9. Change History................................................45 8. Open Issues...................................................45
9.1 Changes from draft-hancock-nsis-fw-00.txt .................45 9. Change History................................................47
Acknowledgments..................................................48 9.1 Changes from draft-ietf-nsis-fw-00.txt ....................47
Author's Addresses...............................................48 9.2 Changes from draft-hancock-nsis-fw-00.txt .................47
Full Copyright Statement.........................................49 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 NSIS will work on signaling from an end point that follows a path
through the net that is determined by layer 3 routing and is used to through the net that is determined by layer 3 routing and is used to
convey information to the devices the signals pass through - the convey information to the devices the signals pass through - the
signaling can, for example, install soft state in the devices it signaling can, for example, install soft state in the devices it
passes through. A signaling end point could be a device along the passes through. A signaling end point could be a device along the
path, which signals for a data flow that passes through it. path, which signals for a data flow that passes through it.
skipping to change at page 4, line 25 skipping to change at page 4, line 29
will define an over-arching architecture for carrying out resource will define an over-arching architecture for carrying out resource
management in the Internet, nor is this intended to be used as a management in the Internet, nor is this intended to be used as a
detailed protocol design document. detailed protocol design document.
The framework is not about what NSIS should do but how it should do The framework is not about what NSIS should do but how it should do
it. It is not intended that this places requirements on a future NSIS it. It is not intended that this places requirements on a future NSIS
protocol, since requirements are already defined in [2]. The document protocol, since requirements are already defined in [2]. The document
discusses important protocol considerations, such as mobility, discusses important protocol considerations, such as mobility,
security, and interworking with resource management (in a broad security, and interworking with resource management (in a broad
sense). Discussions about lessons to be learned from existing sense). Discussions about lessons to be learned from existing
signaling and resource protocols are assumed to be contained in a signaling and resource protocols are contained in a separate analysis
separate analysis document. document [4].
This initial version provides a model of the entities that take part This initial version provides a model of the entities that take part
in the signaling. It discusses the considerations that must be taken in the signaling. It discusses the considerations that must be taken
into account in developing the framework, particularly the structural into account in developing the framework, particularly the options
options for the structure of such a protocol, and the interactions for the structure of such a protocol, and the interactions between
between NSIS and other protocols and functions, including security NSIS and other protocols and functions, including security issues.
issues. Finally, it includes background material on how NSIS could Finally, it includes background material on how NSIS could support
support particular signaling applications. particular signaling applications.
It is expected that future versions of this document will distill It is expected that future versions of this document will distill
these structural options into a concrete technical framework, and these structural options into a concrete technical framework, and
material on particular signaling applications and deployment material on particular signaling applications and deployment
scenarios will be moved into separate NSIS applicability statements. scenarios will be moved into separate NSIS applicability statements.
The purpose of this document is to develop the realms, domains and The purpose of this document is to develop the realms, domains and
modes of operation where an NSIS protocol can be used; identify the modes of operation where an NSIS protocol can be used; identify the
relationship of an NSIS protocol to other protocols; and identify relationship of an NSIS protocol to other protocols; and identify
areas for future work. areas for future work.
2. Terminology 2. Terminology
Classifier - an entity which selects packets based on the content of Classifier - an entity which selects packets based on their contents
packet headers according to defined rules. according to defined rules.
Interdomain traffic - Traffic that passes from one NSIS domain to Interdomain traffic - Traffic that passes from one NSIS domain to
another. another.
NSIS Domain (ND) - Administrative domain where an NSIS protocol NSIS Domain (ND) - Administrative domain where an NSIS protocol
signals for a resource or set of resources. signals for a resource or set of resources.
NSIS Entity (NE) - the function within a node which implements an NSIS Entity (NE) - the function within a node which implements an
NSIS protocol. NSIS protocol. In the case of path-coupled signaling, the NE will
always be on the data path.
NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR NSIS Forwarder (NF) - NSIS Entity between a NI and NR which may
which may interact with local resource management function (RMF). interact with local resource management function (RMF). It also
NSIS Forwarder also propagates NSIS signaling further through the propagates NSIS signaling further through the network.
network.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
network resource. network resource.
NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well. can optionally interact with applications as well.
NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS
protocol component that supports a specific signaling application.
See also section 3.1.3.
NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS
protocol component that will support lower layer (signaling
application independent) functions. See also section 3.1.3.
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. See also
section 3.2.1. section 3.2.1.
Path-decoupled signaling - signaling with independent data and Path-decoupled signaling - signaling with independent data and
signaling paths. signaling paths.
Peer session - signaling relationship between two adjacent NSIS Peer determination - the act of locating and/or selecting which NSIS
peer to carry out signaling exchanges with for a specific data flow.
Peer relationship - signaling relationship between two adjacent NSIS
entities (i.e. NEs with no other NEs between them). entities (i.e. NEs with no other NEs between them).
Receiver - the node in the network which is receiving the data
packets in a flow.
Resource - something of value in a network infrastructure to which Resource - something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted. rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth Examples of resources include the buffers in a router and bandwidth
on an interface. on an interface.
Resource Management Function (RMF) - an abstract concept, Resource Management Function (RMF) - an abstract concept,
representing the management of resources in a domain or a node. representing the management of resources in a domain or a node.
Sender - the node in the network which is sending the data packets in
a flow.
Service Level Agreement (SLA) - a service contract between a customer Service Level Agreement (SLA) - a service contract between a customer
and a service provider that specifies the forwarding service a and a service provider that specifies the forwarding service a
customer should receive. customer should receive.
[NSIS] Signaling application - the purpose of the NSIS signaling: a [NSIS] Signaling application - the purpose of the NSIS signaling: a
service could be QoS management, firewall control, and so on (see service could be QoS management, firewall control, and so on. Totally
also [7]). Totally distinct from any specific user application. distinct from any specific user application.
Traffic characteristic - a description of the temporal behavior or a Traffic characteristic - a description of the temporal behavior or a
description of the attributes of a given traffic flow or traffic description of the attributes of a given traffic flow or traffic
aggregate. aggregate.
Traffic flow - a stream of packets between two end-points that can be Traffic flow - a stream of packets between two end-points that can be
characterized in a certain way. characterized in a certain way.
3. Overall Framework Structure 3. Overall Framework Structure
skipping to change at page 6, line 50 skipping to change at page 7, line 24
interact with local resource management function (RMF). How and if interact with local resource management function (RMF). How and if
this interaction takes place depends on the deployed resource this interaction takes place depends on the deployed resource
management mechanism and the specific role of the NF. The NSIS management mechanism and the specific role of the NF. The NSIS
forwarder propagates NSIS signaling further through the network. forwarder propagates NSIS signaling further through the network.
The NSIS Responder (NR) is an entity that terminates NSIS signaling The NSIS Responder (NR) is an entity that terminates NSIS signaling
and can optionally interact with local applications as well e.g. for and can optionally interact with local applications as well e.g. for
the purpose of notification when network resources get allocated etc. the purpose of notification when network resources get allocated etc.
The signaling relationship between two NSIS entities (with no other The signaling relationship between two NSIS entities (with no other
NSIS entities between them) is called a 'Peer-session'. This concept NSIS entities between them) is called simply a 'peer relationship'.
might loosely be described as an 'NSIS hop'; however, there is no This concept might loosely be described as an 'NSIS hop'; however,
implication that it corresponds to a single IP hop. 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 Figure 1 depicts simplified interactions/interfaces between NI, NFs
and NR as well as local applications and RMFs. Note that the NI and and NR as well as local applications and RMFs. Note that the NI and
NR could also interact with an RMF; additionally, this could be NR could also interact with an RMF; additionally, this could be
modeled as co-location of NI&NF and NR&NF. This distinction should modeled as co-location of NI&NF and NR&NF. This distinction should
have no impact on the operation of the protocol. Also, there is no have no impact on the operation of the protocol. Also, there is no
bar on placing an NI or NR in the interior of the network, to bar on placing an NI or NR in the interior of the network, to
initiate and terminate NSIS signaling independently of the ultimate initiate and terminate NSIS signaling independently of the ultimate
endpoints of the end to end flow, and NI and NR do not have to talk 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 via intervening NFs. An example of NSIS being used in this way is
given in section 7.5. given in section 7.5.
+-----------+ +-----------+ +-----------+ +-----------+
|Application| |Application| |Application| |Application|
+-----------+ +-----------+ +-----------+ +-----------+
^ ^ ^ ^
| | | |
| | | |____________| |____________| |
V V V | | | | V
+----+ NSIS +----+ NSIS +----+ NSIS +----+ +----+ +----+ +----+ +----+
| NI |<========>| NF |<===...===>| NF |<========>| NR | | NI |==========| NF |=====....=====| NF |==========| NR |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
^ ^ ^ ^
| | | |
| |
V V V V
+-----+ +-----+ +----+ +----+
| RMF | | RMF | | RMF | | RMF |
+-----+ +-----+ +----+ +----+
<========> = NSIS Peer-session =========== = NSIS signaling messages
|_________| = Scope of single NSIS
| | "peer relationship"
Figure 1: Basic NI/NF/NR Relationships Figure 1: Basic NI/NF/NR Relationships
3.1.2 Placement of NSIS entities 3.1.2 Placement of NSIS Entities
The NI, NF and NR definitions do not make any assumptions about The NI, NF and NR definitions do not make any assumptions about
placements of NSIS signaling entities in respect to the particular placements of NSIS signaling entities in respect to the particular
part of the network or data-forwarding path. part of the network or data-forwarding path.
They can be located along the data path (hosts generating and They can be located along the data path (hosts generating and
receiving data flows, edge routers, intermediate routers etc.) but it receiving data flows, edge routers, intermediate routers etc.) but it
may not be the only one desirable location. may not be the only one desirable location.
In some cases it is desired to be able to initiate and/or terminate In some cases it is desired to be able to initiate and/or terminate
skipping to change at page 8, line 15 skipping to change at page 9, line 7
reasons for this: signaling on behalf of the end hosts that are not reasons for this: signaling on behalf of the end hosts that are not
enabled with NSIS, consolidation of the customer accounting enabled with NSIS, consolidation of the customer accounting
(authentication, authorization) in respect to consumed application (authentication, authorization) in respect to consumed application
and transport resources, security considerations, limitation of the and transport resources, security considerations, limitation of the
physical connection between host and network etc. The proxy can physical connection between host and network etc. The proxy can
communicate the relevant information to the host in the application communicate the relevant information to the host in the application
specific, maybe compressed, form. specific, maybe compressed, form.
Support for NSIS proxies affects the protocol in the following way: Support for NSIS proxies affects the protocol in the following way:
*) The protocol should accommodate signaling with the scope of a *) The protocol should accommodate signaling with the scope of a
single NSIS peer-session; the signaling could be propagated over single NSIS peer relationship; the signaling could be propagated over
multiple peer-sessions all the way toward the destination (end-to- multiple peer relationships all the way toward the destination (end-
end). to-end).
*) In the particular case where the proxy is not on the data path, *) 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 NSIS might have to be extended to allow separated data and signaling
paths, although this analysis is not initially in scope. paths, although this analysis is not initially in scope.
Further discussion of these issues is given in sections 3.2.1 and Further discussion of these issues is given in sections 3.2.1 and
3.3.3. 3.3.3.
As it can be seen from the usage cases presented in the NSIS As it can be seen from the usage cases presented in the NSIS
requirements draft [2] the NSIS signaling procedures may depend on requirements draft [2] the NSIS signaling procedures may depend on
the part/type of the network where NSIS is used. In fact to satisfy the part/type of the network where NSIS is used. In fact to satisfy
sometimes-conflicting requirements in [2], different procedures and sometimes-conflicting requirements in [2], different procedures and
possibly different kinds of the NSIS protocol can be used on possibly different kinds of the NSIS protocol can be used on
different parts/types of the network. Sections 3.2 and 7.5 provide different parts/types of the network. Sections 3.2 and 7.5 provide
more details on this topic. more details on this topic.
3.2 Modes of Operation 3.1.3 NSIS Protocol Components
This section discusses several modes of NSIS protocol operation. Each In order to achieve a modular solution for the NSIS requirements, it
is proposed to structure what we refer to overall as 'the NSIS
protocol' into 2 layers, similarly to the original proposal in [8]:
*) a 'signaling transport' layer, responsible for moving signaling
messages around, which should be independent of any particular
signaling application; and
*) a 'signaling application' layer, which contains functionality
such as message formats and sequences, specific to a particular
signaling application.
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
the transport layer; it may or may not be based on the use of
existing transport protocols. We also use the term 'NSIS Signaling
Layer Protocol' (NSLP) to refer generically to any protocol component
within the signaling application layer; in the end, there will be
several NSLPs. These relationships are illustrated in Figure 2.
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| | | | for something |
| +-----------------+ | else |
V +-----------------+
=============================================
^ +--------------------------------+
| | NSIS Transport Layer Protocol |
NSIS | | .................... |
Transport | | .Standard transport. |
Layer | | . protocol (maybe) . |
| | .................... |
V +--------------------------------+
Figure 2: NSIS Protocol Components
The precise boundary between these layers is not defined at this
stage; see section 3.3.5 for some initial discussion of this point.
3.2 Options for Modes of NSIS Operation
This section discusses several possible modes of NSIS operation. Each
mode of NSIS operation is briefly introduced and where needed mode of NSIS operation is briefly introduced and where needed
analyzed and compared with other modes of NSIS operation. 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 3.2.1 Path-Coupled and Path-Decoupled Signaling
We can consider two basic paradigms for resource reservation We can consider two basic paradigms for resource reservation
signaling, which we refer to as "path-coupled" and "path-decoupled". signaling, which we refer to as "path-coupled" and "path-decoupled".
In the path-coupled case, signaling messages are routed only through In the path-coupled case, signaling messages are routed only through
nodes (NEs) that are in the data path. They do not have to reach all nodes (NEs) that are in the data path. They do not have to reach all
the nodes on the data path (for example, there could be proxies the nodes on the data path (for example, there could be proxies
distinct from the sender and receiver as described in section 3.1.2, distinct from the sender and receiver as described in section 3.1.2,
skipping to change at page 9, line 18 skipping to change at page 11, line 17
In the path-decoupled case, signaling messages are routed to nodes In the path-decoupled case, signaling messages are routed to nodes
(NEs) which are not assumed to be on the data path, but which are (NEs) which are not assumed to be on the data path, but which are
(presumably) aware of it. Signaling messages will always be directly (presumably) aware of it. Signaling messages will always be directly
addressed to the neighbor NE, and the NI/NR may have no relation at addressed to the neighbor NE, and the NI/NR may have no relation at
all with the ultimate data sender or receiver. all with the ultimate data sender or receiver.
There are potentially significant differences in the way that the two There are potentially significant differences in the way that the two
signaling paradigms should be analyzed, for example in terms of signaling paradigms should be analyzed, for example in terms of
scaling behavior, failure recovery, security properties, mechanism scaling behavior, failure recovery, security properties, mechanism
for NSIS peer discovery, and so on. These differences might or might for NSIS peer determination, and so on. These differences might or
not cause changes in the way that the NSIS protocol operates. might not cause changes in the way that the NSIS protocol operates.
The initial goal of NSIS and this framework is to concentrate mainly The initial goal of NSIS and this framework is to concentrate mainly
on the path-coupled case. on the path-coupled case.
3.2.2 Inter-domain and Intra-domain Signaling 3.2.2 Inter-domain and Intra-domain Signaling
Inter-domain NSIS signaling is where the NSIS signaling messages are Inter-domain NSIS signaling is where the NSIS signaling messages are
originated in one NSIS domain and are terminated in another NSIS originated in one NSIS domain and are terminated in another NSIS
domain. domain.
skipping to change at page 11, line 8 skipping to change at page 13, line 6
3.2.4 Global and Local Operation 3.2.4 Global and Local Operation
It is likely that the appropriate way to describe the resources NSIS It is likely that the appropriate way to describe the resources NSIS
is signaling for will vary from one part of the network to another. is signaling for will vary from one part of the network to another.
In particular, resource descriptions that are valid for inter-domain In particular, resource descriptions that are valid for inter-domain
links will probably be different from those useful for intra-domain links will probably be different from those useful for intra-domain
operation (and the latter will differ from one NSIS domain to operation (and the latter will differ from one NSIS domain to
another). another).
One way to describe this issue is to consider the resource One way to describe this issue is to consider the resource
description objects carried by NSIS as divided in globally-understood description objects carried by NSIS (typically within the signaling
objects ("global objects") and locally-understood objects ("local application layer) as divided in globally-understood objects ("global
objects"). The local objects are only applicable for intra-domain objects") and locally-understood objects ("local objects"). The local
signaling, while the global objects are mainly used in inter-domain objects are only applicable for intra-domain signaling, while the
signaling. global objects are mainly used in inter-domain signaling. Note that
such local objects are still part of the NSIS protocol, unlike opaque
data which would be invisible to the protocol; local objects can be
inserted, used and removed by one single domain.
The purpose of this division is to provide additional flexibility in The purpose of this division is to provide additional flexibility in
defining the objects carried by the NSIS protocol such that only defining the objects carried by the NSIS protocol such that only
those objects that are applicable in a particular setting are used. those objects that are applicable in a particular setting are used.
An example approach for reflecting the distinction in the signaling An example approach for reflecting the distinction in the signaling
is that local objects could be put into separate local messages that is that local objects could be put into separate local messages that
are initiated and terminated within one single NSIS domain and/or are initiated and terminated within one single NSIS domain and/or
they could be "stacked" within the NSIS messages that are used for they could be "stacked" within the NSIS messages that are used for
inter-domain signaling. These possibilities will be considered inter-domain signaling. These possibilities will be considered
further during the protocol design activity. further during the protocol design activity.
skipping to change at page 12, line 23 skipping to change at page 14, line 23
*) In a receiver-initiated approach, the signaling messages *) In a receiver-initiated approach, the signaling messages
traveling from the receiver to the sender must be backward routed traveling from the receiver to the sender must be backward routed
such that they follow exactly the same path as was followed by the such that they follow exactly the same path as was followed by the
signaling messages belonging to the same flow traveling from the signaling messages belonging to the same flow traveling from the
sender to the receiver. This implies that a backward routing state sender to the receiver. This implies that a backward routing state
per flow must be maintained. When using a sender-initiated approach, per flow must be maintained. When using a sender-initiated approach,
provided acknowledgements and notifications can be securely delivered provided acknowledgements and notifications can be securely delivered
to the sending node, backward routing is not necessary, and nodes do to the sending node, backward routing is not necessary, and nodes do
not have to maintain backward routing states. 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 incoming 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. allowing the receiver to initiate a reservation for these flows.
*) Where the signaling is looking for the last (nearest to receiver)
NE on the data path, receiver oriented signaling is most efficient;
sender orientation would be possible, but take more messages.
3.2.7 Uni-Directional and Bi-Directional Reservations 3.2.7 Uni-Directional and Bi-Directional Reservations
It is possible that a resource will only be required for one It is possible that a resource will only be required for one
direction of traffic, for example for a media stream with no feedback direction of traffic, for example for a media stream with no feedback
channel. Reservations for both directions of traffic may be required channel. Reservations for both directions of traffic may be required
for other applications, for example a voice call. Therefore, the NSIS for other applications, for example a voice call. Therefore, the NSIS
signaling protocol must allow for both uni- and bi-directional signaling protocol must allow for both uni- and bi-directional
resource reservations. resource reservations.
The most basic method for bi-directional reservations is based on The most basic method for bi-directional reservations is based on
combining two uni-directional reservations. This means that the combining two uni-directional reservations. This allows that the
signaling messages from the sender of the bi-directional reservation signaling messages for one direction of the bi-directional
towards a receiver are able to follow a different path from messages reservation are able to follow a different path from messages
traveling in the opposite direction, which is necessary for path- traveling in the opposite direction, which is necessary for path-
coupled signaling in the presence of asymmetric routing. (Other more coupled signaling in the presence of asymmetric routing. (Other more
integrated approaches may be possible in constrained network integrated approaches may be possible in constrained network
topologies.) The bi-directional reservations can, for example, be topologies where parts of the route are symmetric.) The bi-
used to make the NSIS signaling procedure required after a handover directional reservations can, for example, be used to make the NSIS
procedure more efficient. signaling procedure required after a handover procedure more
efficient.
3.3 Basic Assumptions and Conceptual Issues 3.3 Basic Assumptions and Conceptual Issues
3.3.1 Basic Assumptions 3.3.1 Basic Assumptions
The following assumptions have been made during prior NSIS The following assumptions have been made during prior NSIS
requirements work and initial framework discussions. They are requirements work and initial framework discussions. They are
summarized here for completeness. The subsequent subsections describe summarized here for completeness. The subsequent subsections describe
more generic conceptual assumptions and issues. Note that a complete more generic conceptual assumptions and issues. Note that a complete
overview of current open issues is contained in section 8. overview of current open issues is contained in section 8.
skipping to change at page 13, line 27 skipping to change at page 15, line 27
functionality appropriate to the part/type of the network. (Sections functionality appropriate to the part/type of the network. (Sections
3.2.2 and 3.2.3.) 3.2.2 and 3.2.3.)
*) The protocol developed by the NSIS working group will be path- *) The protocol developed by the NSIS working group will be path-
coupled. Considerations related to a potential path-decoupled coupled. Considerations related to a potential path-decoupled
solution are part of this framework, because they are also needed in solution are part of this framework, because they are also needed in
order to co-exist with existing solutions; however, the NSIS working order to co-exist with existing solutions; however, the NSIS working
group currently has no plans to develop path-decoupled signaling group currently has no plans to develop path-decoupled signaling
protocol. (Section 3.2.1.) 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 *) Multicast support introduces a level of complexity into the NSIS
protocol that is not needed in support of unicast applications. protocol that is not needed in support of unicast applications.
Therefore, a working assumption is be that the NSIS protocol should Therefore, a working assumption is be that the NSIS protocol should
be optimized for unicast. (Section 3.2.5.) be optimized for unicast. (Section 3.2.5.)
*) The NSIS protocol can be used for setup of both uni-directional *) The NSIS protocol can be used for setup of both uni-directional
and bi-directional reservations. (Section 3.2.7.) and bi-directional reservations. (Section 3.2.7.)
3.3.2 NI, NF, NR functionality 3.3.2 NI, NF, NR functionality
skipping to change at page 14, line 21 skipping to change at page 16, line 28
each NSIS entity will establish and maintain a security relation with each NSIS entity will establish and maintain a security relation with
each of its peers and accept only messages from these peers. each of its peers and accept only messages from these peers.
Conversely, there may exist larger domains of NSIS entities that have Conversely, there may exist larger domains of NSIS entities that have
a trust relationship (trusted domains). This may be the case for a trust relationship (trusted domains). This may be the case for
intra-domain signaling. In this case, an NE may accept messages from intra-domain signaling. In this case, an NE may accept messages from
all other NSIS entities in the domain. Both alternatives need not be all other NSIS entities in the domain. Both alternatives need not be
mutually exclusive. It is conceivable that different instances of the mutually exclusive. It is conceivable that different instances of the
NSIS protocol (or different NSIS protocols) use the NSIS security NSIS protocol (or different NSIS protocols) use the NSIS security
model to a larger or lesser extent, provided that overall security is model to a larger or lesser extent, provided that overall security is
not impacted. An analysis of NSIS threats is available from [4]. not impacted. An analysis of NSIS threats is available from [5].
The NSIS peering relations may also have an impact on the required The NSIS peering relations may also have an impact on the required
amount of state at each NSIS entity. When direct interaction with 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 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 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 can be achieved by keeping per-flow state at the NSIS entities or by
maintaining a record route object in the NSIS messages. maintaining a record route object in the NSIS messages.
An initial working assumption is that the NTLP will operate
'locally', that is, just over the scope of a single peer
relationship. End-to-end operation is built up by simply
concatenating these relationships. Any non-local operation (if any)
will take place only in particular NSLPs.
3.3.4 NSIS Addressing 3.3.4 NSIS Addressing
The are potentially two ways to establish a signaling connection by The are potentially two ways to establish a signaling connection by
means of the NSIS protocol. On the one hand, the NSIS message could means of the NSIS protocol. On the one hand, the NSIS message could
be addressed to a neighboring NSIS entity (NE) that is known to be be addressed to a neighboring NSIS entity (NE) that is known to be
closer to the destination NE. On the other hand, the NSIS message closer to the destination NE. On the other hand, the NSIS message
could be addressed to the destination directly, and intercepted by an could be addressed to the destination directly, and intercepted by an
intervening NE. We denote the latter approach as end-to-end intervening NE. We denote the latter approach as end-to-end
addressing and the former as peer-session addressing. addressing and the former as peer-peer addressing.
With peer-session addressing, an NE will determine the address of the With peer-peer addressing, an NE will determine the address of the
next NE based on the payload of the NSIS message (and potentially next NE based on the payload of the NSIS message (and potentially
also on the previous NE). This requires the address of the also on the previous NE). This requires the address of the
destination NE to be derivable from information present in the destination NE to be derivable from information present in the
payload. This can be achieved through the availability of a local payload. This can be achieved through the availability of a local
routing table or through participation in the routing protocol. Peer- routing table or through participation in the routing protocol. Peer-
session addressing inherently supports tunneling of NSIS signaling peer addressing inherently supports tunneling of NSIS signaling
messages between NEs, and is equally applicable to the path-coupled messages between NEs, and is equally applicable to the path-coupled
and path-decoupled cases. and path-decoupled cases.
In case of end-to-end addressing, the NSIS message will be sent with In case of end-to-end addressing, the NSIS message will be sent with
the address of the NR, which then necessarily needs to be on the data the address of the NR, which then necessarily needs to be on the data
path. This requires (some of) the data-path entities to be upgraded path. This requires (some of) the data-path entities to be upgraded
(NSIS-aware) in order to be able to intercept the NSIS messages. The (NSIS-aware) in order to be able to intercept the NSIS messages. The
routing of the NSIS signaling should follow exactly the same path as routing of the NSIS signaling should follow exactly the same path as
the data flow for which the reservation is requested. the data flow for which the reservation is requested.
3.3.5 Service description 3.3.5 NSIS Layer Boundaries
The detailed boundary between the NTLP and NSLPs is an area for
(considerable) further analysis. In particular, it is not clear how
the key issues described earlier (such as sender/receiver
orientation) are allocated to the different layers. However, some
initial assumptions have been made about the functionality in
different layers.
Although the service part of the NSIS message (the part that depends
on the specific signaling application) is outside of the scope of the
NSIS working group, it may be necessary to make some assumptions
about its content in order to determine whether similar functionality
needs to be foreseen in the NSIS-specific part of the message:
*) It is assumed that the service description will handle pre-
emption and survivability issues. These are seen as a part of the
offered service and need not be present in the NSIS control layer.
*) It is assumed that some flow description information is part of *) It is assumed that some flow description information is part of
the NSIS control layer (see section 4.3.1 and 4.5.1). This might be the NTLP (see section 4.3.1 and 4.5.1). This might be needed by
needed by signaling application unaware entities located at address signaling application unaware entities located at address boundaries.
boundaries. It is not clear to which level of complexity, the flow It is not clear to which level of complexity the flow description
description needs to be available at this level. needs to be available at this level.
*) It is not assumed that the content of the service description is *) It is not assumed that the operation of an NSLP is totally
independent of the NSIS control layer. It seems appropriate to allow independent of the NTLP; for example, the appropriate interpretation
the content of the service description to be dependent on the type of of an NSLP message might depend on the local status of the NTLP.
message that is sent (request/response/refresh).
3.3.6 NSIS Acknowledgement and Notification Semantics 3.3.6 NSIS Acknowledgement and Notification Semantics
The semantics of the acknowledgement and notification messages are of The semantics of the acknowledgement and notification messages are of
particular importance. An NE sending a message can assume particular importance. An NE sending a message can assume
responsibility for the entire downstream chain of NEs, indicating for responsibility for the entire downstream chain of NEs, indicating for
instance the availability of reserved resources for the entire instance the availability of reserved resources for the entire
downstream path. Alternatively, the message could have a more local downstream path. Alternatively, the message could have a more local
meaning, indicating for instance that a certain failure or meaning, indicating for instance that a certain failure or
degradation occurred at a particular NSIS entity. degradation occurred at a particular NSIS entity.
skipping to change at page 15, line 49 skipping to change at page 18, line 15
4. Protocol Components 4. Protocol Components
4.1 Lower Layer Interfaces 4.1 Lower Layer Interfaces
Within a signaling entity, NSIS interacts with the 'lower layers' of Within a signaling entity, NSIS interacts with the 'lower layers' of
the protocol stack for two nearly independent purposes: sending and the protocol stack for two nearly independent purposes: sending and
receiving signaling messages; and configuring the operation of the receiving signaling messages; and configuring the operation of the
lower layers themselves. lower layers themselves.
For sending and receiving messages, this framework places the lower For sending and receiving messages, this framework places the lower
boundary of the NSIS protocol at the IP layer. (It is possible that boundary of the NTLP at the IP layer. (It is possible that NSIS could
NSIS could use a standard transport protocol above the IP layer to use a standard transport protocol above the IP layer to provide some
provide some of its functionality; this is discussed in section of its functionality; this is discussed in section 4.3.1.) The
4.3.1.) The interface with the lower layers is therefore very simple: interface with the lower layers is therefore very simple:
*) NSIS sends raw IP packets *) The NTLP sends raw IP packets
*) NSIS receives raw IP packets. In the case of peer-session *) The NTLP receives raw IP packets. In the case of peer-peer
addressing, they have been addressed directly to it. In the case of addressing, they have been addressed directly to it. In the case of
end-to-end addressing, this will be by intercepting packets that have end-to-end addressing, this will be by intercepting packets that have
been marked in some special way (by special protocol number or by been marked in some special way (by special protocol number or by
some option interpreted within the IP layer, such as the Router Alert some option interpreted within the IP layer, such as the Router Alert
option [5] and [6].) option [6] and [7].)
NSIS needs to have some information about the link and IP layer For correct message routing, the NTLP needs to have some information
configuration of the local networking stack. For example, NSIS needs about the link and IP layer configuration of the local networking
to know about: stack. For example, it needs to know:
*) [in general] how to select the outgoing interface for a signaling *) [in general] how to select the outgoing interface for a signaling
message, in case this needs to match the interface that will be used 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 by the corresponding flow. This might be as simple as just allowing
the IP layer to handle the message using its own routing table. the IP layer to handle the message using its own routing table.
*) [in the case of IPv6] what address scopes are associated with the *) [in the case of IPv6] what address scopes are associated with the
interfaces that messages are sent and received on (to interpret interfaces that messages are sent and received on (to interpret
scoped addresses in flow identification, if these are to be allowed). scoped addresses in flow identification, if these are to be allowed).
The way in which NSIS actually configures the lower layers to handle The way in which the lower layers are actually configured to handle
the flow depends on the particular NSIS signaling application; for the flow depends on the particular NSIS signaling application; for
example, if NSIS is being used for QoS signaling, this might involve example, if NSIS is being used for QoS signaling, this might involve
configuration of traffic classification and conditioning parameters, configuration of traffic classification and conditioning parameters,
for example local packet queues, type of filters, type of scheduling, for example local packet queues, type of filters, type of scheduling,
and so on. However, none of this is directly related to the NSIS and so on. However, none of this is directly related to the NTLP or
protocol itself; therefore, this interaction is handled indirectly indeed any NSLP; therefore, this interaction is handled indirectly
via a resource management function, as described in section 5.1. via a resource management function, as described in section 5.1.
4.2 Upper Layer Services 4.2 Upper Layer Services
NSIS provides a signaling service, which can be used by multiple The combination of the NTLP and an NSLP provides a signaling service,
upper layers, or signaling applications. We describe this service appropriate for a particular signaling application. We can describe
here as an abstract set of capabilities. A later version of this such a signaling service as an abstract set of capabilities, provided
framework could illustrate the use of these capabilities within a at a service interface, defined from three perspectives:
broader context (e.g. how NSIS signaling could be used within a
complete set of message flows that signal a voice over IP call).
We can loosely define the boundary between NSIS and these signaling
applications from three views:
*) What basic control primitives are available at the interface; *) What basic control primitives are available at the interface;
*) What information is exchanged within these primitives; *) What information is exchanged within these primitives;
*) What assumptions NSIS makes about operations carried out above *) What assumptions are made about operations carried out above the
the interface. interface.
The set of control primitives required is quite small. The set of control primitives required is quite small.
At the initiating (NI) end: At the initiating (NI) end:
*) Signaling application requests signaling for a new resource; *) Signaling application requests signaling for a new resource;
*) Signaling application requests modification or removal of an *) Signaling application requests modification or removal of an
existing resource. existing resource.
*) Signaling application receives progress indications (minimally, *) Signaling application receives progress indications (minimally,
success or failure). success or failure).
At the responding (NR) end: At the responding (NR) end:
*) Notification to signaling application that a resource has been *) Notification to signaling application that a resource has been
set up. set up.
At either end: At either end:
*) Notification to signaling application that something has changed *) Notification to signaling application that something has changed
skipping to change at page 17, line 19 skipping to change at page 19, line 26
success or failure). success or failure).
At the responding (NR) end: At the responding (NR) end:
*) Notification to signaling application that a resource has been *) Notification to signaling application that a resource has been
set up. set up.
At either end: At either end:
*) Notification to signaling application that something has changed *) Notification to signaling application that something has changed
about the available resource and other error conditions. about the available resource and other error conditions.
This description is in terms of a 'hard state' interface, without This description is in terms of a 'hard state' interface, without
explicit refresh messages between the signaling application and NSIS, explicit refresh messages between the signaling application and NSIS,
although this is an implementation issue. In any case, NSIS although this is an implementation issue. In any case,
implementations will need to be able to detect conditions when implementations will need to be able to detect conditions when
instances of signaling applications fail without issuing explicit instances of signaling applications fail without issuing explicit
resource removal requests. resource removal requests.
The information in the control primitives consists essentially of two The information in the control primitives consists essentially of two
parts. The first is the definition of the data flow for which the 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 resource is being signaled. The format (e.g. socket id or packet
fields or whatever) is an implementation issue; it has to be fields or whatever) is an implementation issue; it has to be
interpreted into a 'wire format' (as in section 4.5). Since NSIS interpreted into a 'wire format' (as in section 4.5). Since NSIS
could support both sender and receiver initiation, the flow could support both sender and receiver initiation, the flow
definition must also state whether it is incoming or outgoing over a definition must also state whether it is incoming or outgoing over a
particular interface (this can be inferred when the initiator is particular interface (this can be inferred when the initiator is
colocated with the flow endpoint). The second part of the information colocated with the flow endpoint). The second part of the information
exchanged is the service definition (e.g. QoS description in the case exchanged is the service definition (e.g. QoS description in the case
of a QoS request). This is opaque to NSIS, with the possible of a QoS request). This will be opaque at least to the NTLP, which
exception of identifying the signaling application in use (i.e. the only knows the specific NSLP being used.
resource type being signaled.)
We have a basic design goal not to duplicate functionality that is We have a basic design goal not to duplicate functionality that is
already present in (or most naturally part of) existing signaling already present in (or most naturally part of) existing signaling
protocols which could be used by the upper layers. Therefore NSIS protocols which could be used by the upper layers. Therefore NSIS
(implicitly) assumes that certain procedures are carried out (implicitly) assumes that certain procedures are carried out
'externally'. The main aspects of this are: 'externally'. The main aspects of this are:
*) Negotiation of service configuration (e.g. discovering what *) Negotiation of service configuration (e.g. discovering what
services are available to be requested); services are available to be requested);
*) Agreement to use NSIS for signaling, and coordination of which *) Agreement to use NSIS for signaling, and coordination of which
end will be the initiator; end will be the initiator.
*) (Potentially) discovery of the NSIS peer to be signaled with,
especially if this is not directly on the data path. See also the In addition, as well as NSIS (presumably the NTLP) providing a
security discussion in section 6. 'native' capability to determine the peer to carry out signaling
with, it is possible that this information could be provided from
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 Actually providing these functions might require enhancements to
these other protocols. These are still to be identified. these other protocols. These are still to be identified.
4.3 Protocol Structure 4.3 Protocol Structure
4.3.1 Internal Layering 4.3.1 Internal Layering
We can model NSIS in three layers, as shown in Figure 2. This is We can model NSIS in two layers, as shown in Figure 3. This is
initially just a way of grouping associated functionality, and does initially just a way of grouping associated functionality, and does
not mean that all these layers could necessarily operate or even be not mean that all these layers could necessarily operate or even be
implemented independently. implemented independently.
..................................
. Signaling Application .
. (section 4.2) .
. .
+--------------------------------+ +--------------------------------+
|////////////////////////////////| | NSIS Signaling Layer Protocol |
|///// Service Description //////| | (for some specific signaling |
|///// (Opaque to NSIS) //////| | application) |
|///// (Section 4.2) //////|
|////////////////////////////////|
+--------------------------------+
| |
| NSIS Control Layer |
| | | |
+--------------------------------+ +--------------------------------+
| | | NSIS Transport Layer Protocol |
| Generic Signaling Transport | | .................... |
| Protocol | | .Standard transport. |
| | | . protocol (maybe) . |
| .................... |
+--------------------------------+ +--------------------------------+
. Interface to IP Layer . . Interface to IP layer .
. (Section 4.1) . . (section 4.1) .
. .
.................................. ..................................
Figure 2: NSIS Layer Structure Figure 3: NSIS Layer Structure
The lower layer interface (to IP) has been described in section 4.1. The lower layer interface (to IP) has been described in section 4.1.
The service description information is essentially the same as The support of the signaling application is as described in section
provided by the signaling application, as described in section 4.2. 4.2. The degree of independence between the NTLP and NSLP is unclear
It isn't clear if the service description can be independent of the and might depend on the particular signaling application. To make the
lower parts of the protocol or whether different descriptions would NTLP independent of the signaling application, we must allow that
be valid at different stages of protocol operation. This depends on NSLPs could be explicitly dependent on the layer below. This is
the particular signaling application, and therefore to make NSIS similar to the ALSP/CSTP coupling described in [8].
signaling application independent we must allow that the service
description part may be explicitly dependent on the 'NSIS' fields
which lie below. This is similar to the ALSP/CSTP coupling described
in [7].
The distinction between the 'NSIS layer' and the 'Generic Signaling' The distinction between the NTLP and any 'Standard Transport
layer is not functionally clear cut, but one of convenience. In Protocol' is not functionally clear cut, but one of convenience. In
outline: outline:
*) The 'generic' layer provides (at most) functionality which might *) The 'standard' protocol could provide (at most) functionality
be available from existing protocols, such as SCTP [8] or IPSec [9]. which might be available from existing protocols, such as SCTP [9] or
IPSec [10]. An extreme case could be the binding update messages of
An extreme case could be the binding update messages of mobility mobility signaling (section 5.3.4).
signaling (section 5.3.4). *) The NTLP provides (at least) functionality which is somehow
*) The 'NSIS' layer provides (at least) functionality which is specific to path-coupled signaling.
somehow specific to path-coupled signaling.
Functionality reasonable to re-use from existing protocols might Functionality reasonable to re-use from existing protocols might
include reliability and re-ordering protection, dead peer detection include reliability and re-ordering protection, dead peer detection
(keepalive), multihoming support, payload multiplexing (keepalive), multihoming support, payload multiplexing
(piggybacking), and security services, such as establish a security (piggybacking), and security services, such as establishment of
context and carrying out key exchange. security contexts and carrying out key exchange.
Functionality which would probably have to be in the NSIS layer would Functionality which would probably have to be in the NTLP would
include flow and reservation identification, some error handling, include flow and reservation identification, some error handling,
demultiplexing between different signaling applications, as well as demultiplexing between different NSLPs, as well as possibly the basic
the basic NSIS messages. More details on the messages are in section NSIS messages. More details on the messages are in section 4.3.2 and
4.3.2 and the identifier aspects in section 4.5. the identifier aspects in section 4.5.
The choice of using functionality from an existing protocol or re- The choice of using functionality from an existing protocol or re-
specifying it as part of NSIS is for further analysis. It probably specifying it as part of the NTLP is for further analysis. It
depends on the function in question, and in the end might be left probably depends on the function in question, and in the end might be
flexible to allow optimization to local circumstances. (For example, left flexible to allow optimization to local circumstances. (For
Diameter allows the use of IPSec for security services, but also example, Diameter allows the use of IPSec for security services, but
includes its own CMS application as an alternative.) Whichever also includes its own CMS application as an alternative.) Whichever
approach is taken, the combination of NSIS and supporting transport approach is taken, the combination of NTLP and supporting transport
protocol must provide a uniform protocol capability to the upper protocol must provide a uniform protocol capability to the NSLPs
layers which contain the actual signaling application. which support the actual signaling applications.
4.3.2 Protocol Messages 4.3.2 Protocol Messages
The NSIS specific part will include a set of messages to carry out The NSIS protocols will include a set of messages to carry out
particular operations along the signaling path. Initial work for RSVP particular operations along the signaling path. Initial work for RSVP
concentrated on the particular case of QoS signaling, although in concentrated on the particular case of QoS signaling, although the
principle, the necessary basic messages could depend on the signaling implication of the analysis in [8] is that this message set
application NSIS is being used for. However, the implication of the generalizes to a wide variety of signaling applications and so we use
analysis in [7] is that this message set generalizes to a wide it as a starting point. (A very similar set of messages was generated
variety of scenarios, and so we use it as a starting point. A very in [11].) However, in principle, the necessary basic messages could
similar set was generated in [10]. 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 Note that the 'direction' column in the table below only indicates
the 'orientation' of the message. The messages can be originated and the 'orientation' of the message. The messages can be originated and
absorbed at NF nodes as well as the NI or NR; an example might be NFs absorbed at NF nodes as well as the NI or NR; an example might be NFs
at the edge of a domain exchanging NSIS messages to set up resources at the edge of a domain exchanging NSIS messages to set up resources
for a flow across a it. for a flow across a it.
Note the working assumption that responder as well as the initiator Note the working assumption that responder as well as the initiator
can release a reservation (comparable to rejecting it in the first can release a reservation (comparable to rejecting it in the first
place). It is left open if the responder can modify a reservation, place). It is left open if the responder can modify a reservation,
skipping to change at page 21, line 8 skipping to change at page 23, line 19
and on the specific signaling application in use. The signaling and on the specific signaling application in use. The signaling
application might require per flow or lower granularity state; application might require per flow or lower granularity state;
examples of each for the case of QoS would be IntServ or RMD (per examples of each for the case of QoS would be IntServ or RMD (per
'class' state) respectively. The NSIS protocol should not overburden 'class' state) respectively. The NSIS protocol should not overburden
an application that was otherwise lightweight in state requirement. an application that was otherwise lightweight in state requirement.
However, depending on design details, it might require storage of However, depending on design details, it might require storage of
per-flow state including reverse path peer addressing, simply for per-flow state including reverse path peer addressing, simply for
sending NSIS messages themselves. sending NSIS messages themselves.
There are several robustness problems, which roughly align with the There are several robustness problems, which roughly align with the
'layers' of the NSIS protocols of Figure 2, that can be handled by 'layers' of the NSIS protocols of Figure 3, that can be handled by
the soft state principle. (Independence of these layers therefore the soft state principle. (Independence of these layers therefore
implies the danger of duplication of functionality.) This relies on implies the danger of duplication of functionality.) This relies on
periodic refresh of the state information with the current context, periodic refresh of the state information with the current context,
relying on invalid state being timed out. Soft state can be used relying on invalid state being timed out. Soft state can be used
either as the primary mechanism to handle the problem, or sometimes either as the primary mechanism to handle the problem, or sometimes
as a backup to some other approach. as a backup to some other approach.
*) At the lowest level, soft state can be used to detect dead NSIS *) At the lowest level, soft state can be used to detect dead NSIS
peers - loss of several periodic messages implies termination of the peers - loss of several periodic messages implies termination of the
signaling. (The same inference can be made e.g. if failure is signaling. (The same inference can be made e.g. if failure is
skipping to change at page 21, line 42 skipping to change at page 24, line 4
*) At the highest level, a particular signaling application might *) At the highest level, a particular signaling application might
have timing limits associated with a particular reservation (e.g. have timing limits associated with a particular reservation (e.g.
credit limited network access). Periodic re-authorized requests can credit limited network access). Periodic re-authorized requests can
be used as part of the time control. be used as part of the time control.
All of these can be handled with a single soft state mechanism, All of these can be handled with a single soft state mechanism,
although it may be hard to choose a single refresh interval and although it may be hard to choose a single refresh interval and
message loss threshold appropriate for all of them. Even where message loss threshold appropriate for all of them. Even where
alternative approaches are possible, for example using knowledge of alternative approaches are possible, for example using knowledge of
the fact that a routing change has occurred to trigger an explicit the fact that a routing change has occurred to trigger an explicit
NSIS release message, it seems that a soft state mechanism is always release message, it seems that a soft state mechanism is always
necessary as a backup. necessary as a backup.
4.5 Identity Elements 4.5 Identity Elements
NSIS will carry certain identifiers within the NSIS layer. The most NSIS will carry certain identifiers within the NTLP. The most
significant identifier needs seem to be the following. 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 and/or messages that are associated with the same
flow will be identified by the same flow identifier. In principle, it flow will be identified by the same flow identifier. In principle, it
could be a combination of the following information (note that this could be a combination of the following information (note that this
is not an exclusive list of information that could be used for flow is not an exclusive list of information that could be used for flow
identification): identification):
*) 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);
skipping to change at page 22, line 18 skipping to change at page 24, line 28
is not an exclusive list of information that could be used for flow is not an exclusive list of information that could be used for flow
identification): identification):
*) 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 traffic;
*) DSCP/TOS field *) DSCP/TOS field
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 service definition, but is explicit as part of the basic NSIS the NSLP, but is explicitly part of the NTLP. The justification for
protocol. The justification for this is that it might be valuable to this is that it might be valuable to be able to do NSIS processing
be able to do NSIS processing even at a node which was unaware of the even at a node which was unaware of the specific signaling
specific signaling application; this would be a case of an NSIS application; this would be a case of an NSIS forwarder with no
forwarder with no interface to any resource management function. An interface to any resource management function. An example scenario
example scenario would be NSIS messages passing through an addressing would be NSIS messages passing through an addressing boundary where
boundary where the flow identification had to be re-written. the flow identification had to be re-written.
The very flexibility possible in flow classification is a possible The very flexibility possible in flow classification is a possible
source of difficulties: when wildcards or ranges are included, it is source of difficulties: when wildcards or ranges are included, it is
probably unreasonable to assume a standard classification capability probably unreasonable to assume a standard classification capability
in routers; on the other hand, negotiating this capability would be a in routers; on the other hand, negotiating this capability would be a
significant protocol complexity. significant protocol complexity.
4.5.2 Reservation Identification 4.5.2 Reservation Identification
There are several circumstances where it is important to be able to There are several circumstances where it is important to be able to
skipping to change at page 23, line 5 skipping to change at page 25, line 15
(where both sender and receiver initiate for the same flow). (where both sender and receiver initiate for the same flow).
A reservation identifier performs these roles. It is open how the A reservation identifier performs these roles. It is open how the
reservation identifier space should be defined and managed, and what reservation identifier space should be defined and managed, and what
the scope of the identifier should be (only peer-peer, or end-end, the scope of the identifier should be (only peer-peer, or end-end,
when interpreted in conjunction with some of the addressing when interpreted in conjunction with some of the addressing
information). Some of the necessary identifier functions, especially information). Some of the necessary identifier functions, especially
to do with local operation of NSIS, may also be provided by lower to do with local operation of NSIS, may also be provided by lower
layer signaling transport protocols. layer signaling transport protocols.
4.5.3 Signaling Application Identification 4.5.3 NSLP Identification
Since NSIS can be used to support several signaling applications, Since the NTLP can be used to support several NSLPs, there is a need
there is a need to identify which one a particular NSIS invocation is to identify which one a particular NSIS message is being used for:
being used for, and this needs to be done outside the (opaque) *) processing incoming messages at a responder - the NTLP should be
service description: able to demultiplex these towards the appropriate signaling
*) processing incoming request messages at a responder - the NSIS
layer should be able to demultiplex these towards the appropriate
application; application;
*) processing general NSIS messages at an NSIS aware intermediate *) processing general NSIS messages at an NSIS aware intermediate
node - if the node does not handle the specific signaling node - if the node does not handle the specific signaling
application, it should be able to make a forwarding decision without application, it should be able to make a forwarding decision without
having to parse the service description. having to parse the upper layer information.
Signaling application identifiers would probably require an IANA Signaling application identifiers would probably require an IANA
registry. registry.
5. NSIS Protocol Interactions 5. NSIS Protocol Interactions
So far as possible, the NSIS protocol(s) should be usable in So far as possible, the NSIS protocol should be usable in isolation,
isolation, without explicitly depending on other protocols to without explicitly depending on other protocols to operate. However,
operate. However, in many cases, NSIS functionality overlaps with the in many cases, NSIS functionality overlaps with the problem spaces of
problem spaces of other protocols. In order to determine the other protocols. In order to determine the boundaries which minimize
boundaries which minimize any explicit interdependencies, these any explicit interdependencies, these protocol interactions must be
protocol interactions must be analyzed. analyzed.
This is different from considering the use of NSIS protocols to This is different from considering the use of NSIS protocols to
support a particular signaling application, or example configurations support a particular signaling application, or example configurations
in which NSIS might be deployed. These subjects are discussed in in which NSIS might be deployed. These subjects are discussed in
section 7. section 7.
5.1 Resource Management Interactions 5.1 Resource Management Interactions
The NSIS protocol is used for signaling resource requests from an The NSIS protocol is used for signaling resource requests from an
NSIS Initiator to an NSIS Responder. The NSIS protocol should be NSIS Initiator to an NSIS Responder. The NSIS protocol should be
skipping to change at page 24, line 14 skipping to change at page 26, line 22
network. This is a special case of general NSIS triggering and will network. This is a special case of general NSIS triggering and will
not be elaborated here. This case could for instance apply with not be elaborated here. This case could for instance apply with
multi-level NSIS signaling (section 7.5). multi-level NSIS signaling (section 7.5).
Second, the RMF can act as a server towards the NSIS protocol. In Second, the RMF can act as a server towards the NSIS protocol. In
that case, the signaling decision taken by the NF may depend on the that case, the signaling decision taken by the NF may depend on the
content or processing of the NSIS payload. content or processing of the NSIS payload.
The RMF may or may not be co-located with the NSIS protocol The RMF may or may not be co-located with the NSIS protocol
processing. To cater for both cases, we define a (possibly logical) processing. To cater for both cases, we define a (possibly logical)
NF-RMF interface, see Figure 3. (As mentioned in section 3.1.1, the NF-RMF interface, see Figure 4. (As mentioned in section 3.1.1, the
NI and NR could also interact with an RMF. Note that this could also NI and NR could also interact with an RMF. Note that this could also
be modeled as co-location of the NI&NF and NR&NF. This distinction be modeled as co-location of the NI&NF and NR&NF. This distinction
should have no impact on the operation of the protocol.) Over this should have no impact on the operation of the protocol.) Over this
interface, information may be provided from the RMF about monitoring, interface, information may be provided from the RMF about monitoring,
resource availability, topology, configuration, and so on. resource availability, topology, configuration, and so on.
Additionally, resource provisioning requests may be issued towards Additionally, resource provisioning requests may be issued towards
the RMF. Note that the actual implications for NSIS as a protocol are the RMF. Note that the actual implications for NSIS as a protocol are
the same, regardless of whether the RMF is centralized or the same, regardless of whether the RMF is centralized or
distributed, since NSIS sees the same interface towards the RMF in distributed, since NSIS sees the same interface towards the RMF in
each case. each case.
+----+ NSIS +----+ NSIS +----+ NSIS +----+ +----+ NSIS +----+ NSIS +----+ NSIS +----+
| NI |<========>| NF |<===...===>| NF |<========>| NR | | NI |==========| NF |====...====| NF |==========| NR |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
^ ^ ^ ^
| | | |
V V V V
+----+ +----+ +----+ +----+
| RMF| | RMF| | RMF| | RMF|
+----+ +----+ +----+ +----+
Figure 3: Basic NSIS-RMF Relationship Figure 4: Basic NSIS-RMF Relationship
One way to formalize the interface between the NF and the RMF is via 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 a Service Level Agreement (SLA). The SLA may be static or it may be
dynamically updated by means of a negotiation protocol. Such a dynamically updated by means of a negotiation protocol. Such a
protocol is outside the scope of NSIS. protocol is outside the scope of NSIS.
5.2 IP Routing Interactions 5.2 IP Routing Interactions
Several situations may occur when routing diverges from standard Several situations may occur when routing diverges from standard
layer 3 routing. These are summarized in the sections below. layer 3 routing. These are summarized in the sections below.
skipping to change at page 25, line 18 skipping to change at page 27, line 23
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 source and destination
address, routing of NSIS messages using end-to-end addressing does address, routing of NSIS messages using end-to-end addressing does
not guarantee that the messages will follow the data path. In this not guarantee that the messages will follow the data path. In this
section, we briefly survey what standard methods have been used for section, we briefly survey what standard methods have been used for
load sharing within standard routing protocols. load sharing within standard routing protocols.
In OSPF, load balancing can be used between equal cost paths [11] or In OSPF, load balancing can be used between equal cost paths [12] or
unequal cost paths. An example of the latter approach is Optimized unequal cost paths. An example of the latter approach is Optimized
Multi Path (OMP). OMP discovers multiple paths, not necessarily equal Multi Path (OMP). OMP discovers multiple paths, not necessarily equal
cost paths, to any destinations in the network, but based on the load cost paths, to any destinations in the network, but based on the load
reported from a particular path, it determines which fraction of the reported from a particular path, it determines which fraction of the
traffic to direct to the given path. Incoming packets are subject to traffic to direct to the given path. Incoming packets are subject to
a (source, destination address) hash computation, and effective load a (source, destination address) hash computation, and effective load
sharing is accomplished by means of adjusting the hash thresholds. sharing is accomplished by means of adjusting the hash thresholds.
BGP [12][13] advertises the routes chosen by the BGP decision process BGP [13][14] advertises the routes chosen by the BGP decision process
to other BGP speakers. In the basic specification, routes with the to other BGP speakers. In the basic specification, routes with the
same Network Layer reachability information (NLRI) as previously same Network Layer reachability information (NLRI) as previously
advertised routes implicitly replace the original advertisement, advertised routes implicitly replace the original advertisement,
which means that multiple paths for the same prefix cannot exist. which means that multiple paths for the same prefix cannot exist.
Recently, however, a new mechanism was defined that will allow the Recently, however, a new mechanism was defined that will allow the
advertisement of multiple paths for the same prefix without the new advertisement of multiple paths for the same prefix without the new
paths implicitly replacing any previous ones [14]. The essence of the paths implicitly replacing any previous ones [15]. The essence of the
mechanism is that each path is identified by an arbitrary identifier mechanism is that each path is identified by an arbitrary identifier
in addition to its prefix. in addition to its prefix.
The distribution of traffic over the available path may be done per The distribution of traffic over the available path may be done per
destination, per message in a round-robin fashion or with a destination, per message in a round-robin fashion or with a
predefined hashing function. The determination of the hashing image predefined hashing function. The determination of the hashing image
may take into account the source/destination IP address, QoS may take into account the source/destination IP address, QoS
information such as the DSCP or protocol ID. When the routing information such as the DSCP or protocol ID. When the routing
decision is no longer based on the destination address only, however, decision is no longer based on the destination address only, however,
there is a risk that data plane messages and control plane messages there is a risk that data plane messages and control plane messages
skipping to change at page 26, line 4 skipping to change at page 28, line 10
information such as the DSCP or protocol ID. When the routing information such as the DSCP or protocol ID. When the routing
decision is no longer based on the destination address only, however, decision is no longer based on the destination address only, however,
there is a risk that data plane messages and control plane messages there is a risk that data plane messages and control plane messages
will not follow the same route. will not follow the same route.
5.2.2 QoS Routing 5.2.2 QoS Routing
The are several proposals for the introduction of QoS awareness in The are several proposals for the introduction of QoS awareness in
the routing protocols. All of these essentially lead to the existence the routing protocols. All of these essentially lead to the existence
of multiple paths (with different QoS) towards the same destination. of multiple paths (with different QoS) towards the same destination.
As such, they also contain an inherent risk for a divergence between As such, they also contain an inherent risk for a divergence between
control plane and data plane, similar to the load sharing case. control plane and data plane, similar to the load sharing case.
For intra-domain traffic, the difference in routing may result from a For intra-domain traffic, the difference in routing may result from a
QoS-aware traffic engineering scheme, that e.g. maps incoming traffic QoS-aware traffic engineering scheme, that e.g. maps incoming traffic
to LSPs based on multi-field classification. In BGP, several to LSPs based on multi-field classification. In BGP, several
techniques for including QoS information in the routing decision are techniques for including QoS information in the routing decision are
currently proposed. A first proposal is based on a newly defined currently proposed. A first proposal is based on a newly defined
BGP-4 attribute, the QoS_NLRI attribute [15]. The QoS_NLRI attribute BGP-4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute
is an optional transitive attribute that can be used to advertise a 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 QoS route to a peer or to provide QoS information in along with the
Network Layer Reachability Information (NLRI) in a single BGP update. Network Layer Reachability Information (NLRI) in a single BGP update.
A second proposal is based on controlled redistribution of AS routes A second proposal is based on controlled redistribution of AS routes
[16]. It defines a new extended community (the redistribution [17]. It defines a new extended community (the redistribution
extended community) that allows a router to influence how a specific extended community) that allows a router to influence how a specific
route should be redistributed towards a specified set of eBGP route should be redistributed towards a specified set of eBGP
speakers. The types of redistribution communities may result in a speakers. The types of redistribution communities may result in a
specific route not being announced to a specified set of eBGP specific route not being announced to a specified set of eBGP
speakers, that it should not be exported or that the route should be speakers, that it should not be exported or that the route should be
prepended n times. prepended n times.
5.2.3 Route pinning 5.2.3 Route pinning
Route pinning refers to the independence of the path taken by certain Route pinning refers to the independence of the path taken by certain
skipping to change at page 26, line 45 skipping to change at page 28, line 50
cause a divergence between control plane and data plane. If cause a divergence between control plane and data plane. If
reservations are made on the control plane, this may result in reservations are made on the control plane, this may result in
sending data along an unreserved path while maintaining a reservation sending data along an unreserved path while maintaining a reservation
on a path that is not used. on a path that is not used.
5.2.4 Route Changes 5.2.4 Route Changes
In this section, we will explore the expected interworking between a In this section, we will explore the expected interworking between a
signaling for resource BGP routing updates, although the same applies signaling for resource BGP routing updates, although the same applies
for any source of routing updates. The normal operation of the NSIS for any source of routing updates. The normal operation of the NSIS
protocol will lead to the situation depicted in Figure 4, where the protocol will lead to the situation depicted in Figure 5, where the
reserved resources match the data path. reserved resources match the data path.
reserved +----+ reserved +----+ reserved +----+ reserved +----+
------->| NF |----------->| NF | ------->| NF |----------->| NF |
+----+ +----+ +----+ +----+
===================================== =====================================
data path data path
Figure 4: Normal NSIS protocol operation Figure 5: Normal NSIS protocol operation
A route change (triggered by a BGP routing update for instance) can A route change (triggered by a BGP routing update for instance) can
occur while such a reservation is in place. In case of RSVP, the occur while such a reservation is in place. In case of RSVP, the
route change will be installed immediately and any data that is sent route change will be installed immediately and any data that is sent
will be forwarded on the new path. This situation is depicted will be forwarded on the new path. This situation is depicted
Figure 5. Figure 6.
Route update Route update
| |
v v
reserved +----+ reserved +----+ reserved +----+ reserved +----+
------->| NF |----------->| NF | ------->| NF |----------->| NF |
+----+ +----+ +----+ +----+
========== | ========== |
|| | +----+ || | +----+
|| +---------->| NF | || +---------->| NF |
|| +----+ || +----+
============================ ============================
data path data path
Figure 5: Route Change Figure 6: 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 [17] has several techniques could be considered. As an example, RSVP [18] 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 for NSIS if no per-flow state is kept in option may not be available for NSIS if no per-flow state is kept in
the NF. the NF.
It is not guaranteed that the new path will be able to provide the It is not guaranteed that the new path will be able to provide the
same guarantees that were available on the old path. Therefore, in a same guarantees that were available on the old path. Therefore, in a
more desirable scenario, the NF should wait until resources have been more desirable scenario, the NF should wait until resources have been
reserved on the new path before installing the route change. The reserved on the new path before installing the route change. The
route change procedure then consists of the following steps: route change procedure then consists of the following steps:
1. NF receives a route announcement, 1. NF receives a route announcement,
2. Refresh messages are forwarded along the current path, 2. Refresh messages are forwarded along the current path,
3. A copy of the refresh message is remarked as request and send 3. A copy of the refresh message is remarked as request and send
along the new path that was announced, along the new path that was announced,
4. When the NF has been acknowledged about the reservations on the 4. When the NF has been acknowledged about the reservations on the
new path the route will be installed and the traffic will flow along new path the route will be installed and the traffic will flow along
the new path. the new path.
Another example related to route changes is denoted as severe Another example related to route changes is denoted as severe
congestion and is explained in [18]. This solution adapts to a route congestion and is explained in [19]. This solution adapts to a route
change, when a route change creates a congestion on the new routed change, when a route change creates a congestion on the new routed
path. path.
5.2.5 Router Redundancy 5.2.5 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 resource 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 [19]. A future version of this document may consider such as VRRP [20]. 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.3 Mobility Interactions
The interactions between mobility and resource signaling protocols The interactions between mobility and resource signaling protocols
have been quite extensively analyzed in recent years, primarily in have been extensively analyzed in recent years, primarily in the
the context of RSVP and Mobile IP interaction (e.g. [20]), but also context of RSVP and Mobile IP interaction (e.g. [21]), but also in
in the context of other types of network (e.g. [21]). This analysis the context of other types of network (e.g. [22]). This analysis work
work has shown that some difficulties in the interactions are quite has shown that some difficulties in the interactions are quite deep
deep seated in the detailed design of these protocols; however, the seated in the detailed design of these protocols; however, the
problems and their possible solutions fall under five broad headings. problems and their possible solutions fall under five broad headings.
The main issue is to limit the period after handovers during which 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 resource state has not been installed on the path, in particular
the new part of the path. the new part of the path.
We can use this work as the starting point for considering the We can use this work as the starting point for considering the
framework aspects of a new signaling protocol like NSIS, which will framework aspects of a new signaling protocol like NSIS, which will
need to interwork with mobility signaling, from Mobile IP to mobility need to interwork with mobility signaling, from Mobile IP to mobility
paradigms based on micromobility or application layer approaches. paradigms based on micromobility or application layer approaches.
5.3.1 Addressing and Encapsulation 5.3.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 handover (unless a network supports per host routing) and may involve
involve special packet formats (e.g. the routing header and Home special packet formats (e.g. the routing header and Home Address
Address option of MIPv6). Since NSIS may depend on end system option of MIPv6). Since NSIS may depend on end system addresses for
addresses for forwarding signaling messages and defining flows forwarding signaling messages and defining flows (section 4.5.1), the
(section 4.5.1), the special implications of mobility for addressing special implications of mobility for addressing need to be
need to be considered. Examples of possible approaches that could be considered. Examples of possible approaches that could be used to
used to solve the addressing and encapsulation problem are as solve the addressing and encapsulation problem are as follows:
follows: *) Use a flow identification based on low level IP addresses (e.g.
*) Use a filter definition based on low level IP addresses (e.g. the the Care of Address) and other 'standard' fields in the IP header.
Care of Address) and other 'standard' fields in the IP header. This This makes least demands on the packet classification engines within
makes least demands on the packet classification engines within the the network. However, it means that even on a part of the flow path
network. However, it means that even on a part of the flow path
which is unchanged, the reservation will need to be modified to which is unchanged, the reservation will need to be modified to
reflect the changed flow identification (see section 5.3.3). reflect the changed flow identification (see section 5.3.3).
*) Use a flow definition that does not change (e.g. based on Home *) Use a flow identification that does not change (e.g. based on
Address); this is the approach assumed in [22]. This simplifies the Home Address); this is the approach assumed in [23]. This simplifies
problem of reservation update, at the likely cost of considerably the problem of reservation 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 nodes need
to be able to recognize that a reservation with the new flow to be able to recognize that a reservation with the new flow
identifier is to be correlated with an existing one. The reservation identifier is to be correlated with an existing one. The reservation
identifier (section 4.5.2) was introduced for exactly this purpose. identifier (section 4.5.2) was introduced for exactly this purpose.
Note that this would require the reservation identifier to have Note that this would require the reservation identifier to have
(secure) end to end significance. (An additional optimization here (secure) end to end significance. (An additional optimization here
would be use a local mobility management scheme to localize the would be use a local mobility management scheme to localize the
visibility of the address change.) visibility of the address change.)
skipping to change at page 29, line 41 skipping to change at page 31, line 40
plausible than the second approach. This implies that the NSIS plausible than the second approach. This implies that the NSIS
initiator should define flows in terms of real (care of) addresses initiator should define flows in terms of real (care of) addresses
rather than virtual (home) addresses. Thus, it would have detailed rather than virtual (home) addresses. Thus, it would have detailed
access to lower layer interface configuration (cf. section 4.1), access to lower layer interface configuration (cf. section 4.1),
rather than operating as a pure application level daemon as is rather than operating as a pure application level daemon as is
commonplace with current RSVP implementations. commonplace with current RSVP implementations.
5.3.2 Localized Path Repair 5.3.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 in the path of upstream and downstream packets. NSIS needs to install
install new state on the new path, and remove it on the old. new state on the new path, and remove it on the old. Provided that
Provided that some NSIS node on the joined path - the crossover some NSIS node on the joined path - the crossover router - can
router - can recognize this situation (which again depends on recognize this situation (which again depends on reservation
reservation identification), state installation and teardown can be identification), state installation and teardown can be done locally
done locally between it and the mobile node. (This may have between it and the mobile node. (This may have implications for which
implications for which entities are allowed to generate which entities are allowed to generate which message types, see section
message types, see section 4.3.2). It seems that the basic NSIS 4.3.2). It seems that the basic NSIS framework already contains the
framework already contains the fundamental components necessary for fundamental components necessary for this.
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 router. This is a generalization of the problem of finding
next-NSIS-hop nodes: it requires extending the new path over several next-NSIS-hop nodes: it requires extending the new path over several
hops until it intersects the old one. This is easy for uplink traffic hops until it intersects the old one. This is easy for uplink traffic
(where the mobile is the sender), but much harder for downlink (where the mobile is the sender), but much harder for downlink
traffic without signaling via the correspondent. There is no reason traffic without signaling via the correspondent. There is no reason
for the crossover routers for uplink and downlink flows to be the for the crossover routers for uplink and downlink flows to be the
same, even for the same correspondent. The problem is discussed same, even for the same correspondent. The problem is discussed
further in [23]. further in [24].
5.3.3 Reservation Update on the Unchanged Path 5.3.3 Reservation Update on the Unchanged Path
On the path between the crossover router(s) and the correspondent, it On the path between the crossover router(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 reservation state to reflect new flow identification
(if this is needed, which is the default assumption of section (if this is needed, which is the default assumption of section
5.3.1). Examples of approaches that could be used to solve this 5.3.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 *) Use a reservation state definition that does not change even if
skipping to change at page 31, line 7 skipping to change at page 33, line 4
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 (e.g. binding updates or local micromobility signals) and
NSIS. The discussion so far considered how NSIS should operate. There NSIS. The discussion so far considered how NSIS should operate. There
is still a question of how the interactions between the NSIS and is still a question of how the interactions between the NSIS and
mobility signaling should be considered. mobility signaling should be 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 [22]). At least, the addressing and interoperability problems (see [23]). 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 NSIS to send
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 modification consider the closer interaction of making
the RSVP implementation mobility-routing aware, e.g. so it is able to the RSVP implementation mobility-routing aware, e.g. so it is able to
localize refresh signaling; this would be a self contained aspect of localize refresh signaling; this would be a self contained aspect of
NSIS.) This information could be developed for NSIS by analyzing NSIS.) This information could be developed for NSIS by analyzing
message flows for various mobility signaling scenarios as was done message flows for various mobility signaling scenarios as was done
in [20]. in [21].
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 resource information. Logically, there are
two cases: 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 [22]. (The prime purpose in this resource messages, as is done in [23]. (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 2. Carry resource signaling in the mobility messages, typically as a
new extension header. This was proposed in [24] and followed up new extension header. This was proposed in [25] and followed up
in [25]; [26] also anticipates this approach. In our framework, we in [26]; [27] also anticipates this approach. In our framework, we
could consider this a special case of NSIS layering, with the could consider this a special case of NSIS layering, with the
mobility protocol playing the role of the signaling transport (as mobility protocol playing the role of the signaling transport (as
in 4.3.1). in 4.3.1).
The usefulness of this class of approach depends on a tradeoff The usefulness of this class of approach depends on a tradeoff
between specification simplicity and performance. Simulation work is between specification simplicity and performance. Simulation work is
under way to compare the performance of the two approaches in the under way to compare the performance of the two approaches in the
case of RSVP and micromobility protocols. 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
skipping to change at page 32, line 13 skipping to change at page 34, line 13
it can be localized within a particular part of the network. it can be localized within a particular part of the network.
5.3.5 Interaction with Fast Handoff Support Protocols 5.3.5 Interaction with Fast Handoff Support Protocols
In the context of mobility between different access routers, it is In the context of mobility between different access routers, it is
common to consider performance optimizations in two areas: selection common to consider performance optimizations in two areas: selection
of the optimal access router to handover to, and transfer of state of the optimal access router to handover to, and transfer of state
information between the access routers to avoid having to regenerate information between the access routers to avoid having to regenerate
it in the new access router after handover. The seamoby working group it in the new access router after handover. The seamoby working group
is developing solutions for these protocols for pure IP based is developing solutions for these protocols for pure IP based
networks (CARD and CT respectively); other networks, which use NSIS networks (CARD[28] and CT[29] respectively); other networks, which
for resource signaling within the network, may use different types of use NSIS for resource signaling within the network, may use different
solution. types of solution.
In this section, we consider how NSIS should interact with these In this section, we consider how NSIS should interact with these
functions, however they are implemented. Detailed solutions are not functions, however they are implemented. Detailed solutions are not
proposed, but the way in which interaction these functions is seen proposed, but the way in which interaction these functions is seen
within the NSIS framework is described. NSIS should be able to within the NSIS framework is described. NSIS should be able to
operate independently of these protocols. However, significant operate independently of these protocols. However, significant
performance gains could be achieved if they could be made to performance gains could be achieved if they could be made to
cooperate. In addition, the resource signaling aspects of these cooperate. In addition, the resource signaling aspects of these
protocols could profitably use a common set of resource types and protocols could profitably use a common set of resource types and
definitions, since they will probably be supporting the same overall definitions, since they will probably be supporting the same overall
skipping to change at page 32, line 41 skipping to change at page 34, line 41
to be independent. to be independent.
For access router discovery, a typical model of operation is that the For access router discovery, a typical model of operation is that the
mobile carries out an information gathering exercise about a range of mobile carries out an information gathering exercise about a range of
capabilities. In addition, where those capabilities relate purely to capabilities. In addition, where those capabilities relate purely to
the AR and mobile, there is no role for NSIS (its special the AR and mobile, there is no role for NSIS (its special
functionality is not relevant). However, considering resource functionality is not relevant). However, considering resource
aspects, one aspect of the AR 'capability' is resource availability aspects, one aspect of the AR 'capability' is resource availability
on the path between it and the correspondent, and NSIS should be able on the path between it and the correspondent, and NSIS should be able
to fulfill this part. Indeed, this is effectively precisely the to fulfill this part. Indeed, this is effectively precisely the
application considered in [25], where it is a sort of special case of application considered in [26], where it is a sort of special case of
resource signaling during handover. resource signaling during handover.
Therefore, a possible model of access router discovery/NSIS Therefore, a possible model of access router discovery/NSIS
relationship is that some entity in a candidate AR triggers NSIS relationship is that some entity in a candidate AR triggers NSIS
using resource and reservation information (including reservation id) using resource and reservation information (including reservation id)
from the current AR to find out about what would be available on the 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 new path. Note that this should be a query rather than an actual
reservation; this semantic could be included either in the service reservation; this semantic could be included either in the NTLP or
definition or NSIS itself. NSLP.
The case of state transfer is more complex. There are two obvious The case of state transfer is more complex. There are two obvious
options, corresponding to whether one transfers just signaling options, corresponding to whether one transfers just signaling
application state or NSIS state as well: application state or NSIS state as well:
1. "State transfer triggering NSIS": A state transfer process passes 1. "State transfer triggering NSIS": A state transfer process passes
the 'raw' resource state to the new AR. This triggers a new instance the 'raw' resource state to the new AR. This triggers a new instance
of NSIS to request that resource. of NSIS to request that resource.
2. "NSIS using state transfer": NSIS transfers its own state 2. "NSIS using state transfer": NSIS transfers its own state
information from the old to the new AR. It can then carry out the 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 same update signaling as though it was a single 'virtual AR' which
had just had a topology change towards the correspondent. (This is had just had a topology change towards the correspondent. (This is
essentially the conceptual model of [20].) essentially the conceptual model of [21].)
The first model is simpler, and maybe more in line with the basic The first model is simpler, and maybe more in line with the basic
state transfer expectation; however, it seems hard to avoid double state transfer expectation; however, it seems hard to avoid double
reservations since the two NSIS protocol instances are not reservations since the two NSIS protocol instances are not
coordinated. Therefore, the second model seems more appropriate. An coordinated. Therefore, the second model seems more appropriate. An
advantage of the 'virtual AR' model is that it ensures that the advantage of the 'virtual AR' model is that it ensures that the
impact of the interaction is limited to the NSIS instances at ARs 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 themselves, since the rest of the network must be able to handle a
topology change anyway. topology change anyway.
skipping to change at page 33, line 40 skipping to change at page 35, line 40
reservations promptly. It appears this has to be an NSIS reservations promptly. It appears this has to be an NSIS
responsibility in the AR, and probably requires a custom notification responsibility in the AR, and probably requires a custom notification
message for this circumstance. message for this circumstance.
5.4 NSIS Interacting with NATs 5.4 NSIS Interacting with NATs
Because at least some NSIS messages will almost inevitably contain Because at least some NSIS messages will almost inevitably contain
address and possibly higher layer information as payload (see section address and possibly higher layer information as payload (see section
4.5.1), we must consider the interaction between NSIS and address 4.5.1), we must consider the interaction between NSIS and address
translation devices (NATs). As well as 'traditional' NATs of various translation devices (NATs). As well as 'traditional' NATs of various
types (as defined in [27]) very similar considerations would apply to types (as defined in [30]) very similar considerations would apply to
some IPv4/v6 transition mechanisms such as SIIT [28]. some IPv4/v6 transition mechanisms such as SIIT [31].
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 [29] or incorrect flow. Applications could attempt to use STUN [32] 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 would have to use a well known encapsulation
(TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end (TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end
NAT devices. 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 NSIS 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 security
skipping to change at page 34, line 29 skipping to change at page 36, line 29
Security issues usually turn out to have impacts in the interaction Security issues usually turn out to have impacts in the interaction
of these protocols and must therefore be appropriately addressed in of these protocols and must therefore be appropriately addressed in
such a framework. This section describes these general security such a framework. This section describes these general security
issues, and in particular considers the interactions between NSIS and issues, and in particular considers the interactions between NSIS and
authentication, authorization and accounting. Together with authentication, authorization and accounting. Together with
authentication the protection of the signaling messages is addressed authentication the protection of the signaling messages is addressed
- namely replay and integrity protection. - namely replay and integrity protection.
An initial analysis of the major security threats that apply in the 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 typical of scenario where NSIS is expected to be used is given in
[4]; these threats are described at the overall scenario level, in [5]; these threats are described at the overall scenario level, in
terms of the impact on users and networks. However, in any given terms of the impact on users and networks. However, in any given
scenario, NSIS will be just one protocol or component of the overall scenario, NSIS will be just one part of the overall solution.
solution. Ultimately, the framework will need to define which of Ultimately, the framework will need to define which of these threats
these threats need to be handled by NSIS and which by the other need to be handled by NSIS (and which parts of NSIS) and which by the
components. Currently, we can only make initial scoping assumptions other components. Currently, we can only make initial scoping
of this sort. assumptions of this sort.
6.1 Authentication 6.1 Authentication
Authentication and key establishment for a signaling protocol should Authentication and key establishment for a signaling protocol should
be seen as a two-phase process. The first-phase is usually more be seen as a two-phase process. The first-phase is usually more
performance intensive because of a larger number of roundtrips, performance intensive because of a larger number of roundtrips,
denial of service protection, cross-realm handling, interaction with denial of service protection, cross-realm handling, interaction with
other protocols and the likely larger cryptographic computation other protocols and the likely larger cryptographic computation
associated with it. As stated in section 4.3, this functionality associated with it. As stated in section 4.3, this functionality
could be provided externally to NSIS, e.g. by reusing a standard could be provided externally to NSIS, e.g. by reusing a standard
skipping to change at page 37, line 23 skipping to change at page 39, line 23
Therefore, NSIS plays no further part in this activity; the Therefore, NSIS plays no further part in this activity; the
accounting records are transmitted using the AAA infrastructure, and accounting records are transmitted using the AAA infrastructure, and
charging and billing for the overall service is carried out at some charging and billing for the overall service is carried out at some
higher layer. This would include feedback to applications (and users) higher layer. This would include feedback to applications (and users)
about total session cost (of which the network resource cost might be about total session cost (of which the network resource cost might be
only a part). An open issue is whether a query (without actually only a part). An open issue is whether a query (without actually
making a reservation) to the network should also generate a making a reservation) to the network should also generate a
chargeable event; this could be considered as an aspect of the chargeable event; this could be considered as an aspect of the
service definition. service definition.
6.4 End-to-End vs. Peer-Session Protection 6.4 End-to-End vs. Peer Relationship Protection
It is reasonable to assume that peer-session security (with chain-of- It is reasonable to assume that peer relationship security (with
trust) is used for most signaling environments relevant to NSIS. chain-of-trust) is used for most signaling environments relevant to
Especially the separation of signaling into different network parts NSIS. Especially the separation of signaling into different network
(intra-domain within the access network, end-node to access network, parts (intra-domain within the access network, end-node to access
intra-domain, and so on) and new proposals regarding mobility and network, intra-domain, and so on) and new proposals regarding
proxy support show that traditional end-to-end signaling is not mobility and proxy support show that traditional end-to-end signaling
applicable in every environment (or possibly only in a minor number is not applicable in every environment (or possibly only in a minor
of environments). End-to-end security in a signaling protocol is number of environments). End-to-end security in a signaling protocol
actually problematic for two reasons: is actually problematic for two reasons:
1. Even if the messages use the address of the end-host (to support 1. Even if the messages use the address of the end-host (to support
routing), the messages still have to be interpreted and modified routing), the messages still have to be interpreted and modified
along the path. along the path.
2. The only property that can be achieved by using end-to-end 2. The only property that can be achieved by using end-to-end
security is that one end-host can be assured that the other end-host security is that one end-host can be assured that the other end-host
included some parameters (possibly resource parameters) that have not included some parameters (possibly resource parameters) that have not
been modified along the path. Nodes along the path usually do not been modified along the path. Nodes along the path usually do not
have the possibility to cryptographically verify the protected have the possibility to cryptographically verify the protected
skipping to change at page 38, line 20 skipping to change at page 40, line 20
configurations for NSIS. Our goal is that an NSIS protocol designed configurations for NSIS. Our goal is that an NSIS protocol designed
according to the framework presented in the previous sections should according to the framework presented in the previous sections should
be able to support these scenarios if implemented appropriately; be able to support these scenarios if implemented appropriately;
therefore, this section does not form part of the framework therefore, this section does not form part of the framework
definition, but rather provides examples of how NSIS can be used to definition, but rather provides examples of how NSIS can be used to
do something interesting. In the long term, some of this material may do something interesting. In the long term, some of this material may
be contained in specific NSIS applicability statements. be contained in specific NSIS applicability statements.
7.1 NSIS and Existing Resource Signaling Protocols 7.1 NSIS and Existing Resource Signaling Protocols
It is hoped that an NSIS protocol could eventually achieve widespread It is hoped that NSIS could eventually achieve widespread use for
use for resource signaling. However, it is bound to have to inter- resource signaling. However, it is bound to have to inter-operate
operate with existing resource signaling protocols at least during with existing resource signaling protocols at least during transition
transition and possibly long term. The prime example for QoS is RSVP, and possibly long term. The prime example for QoS is RSVP, although
although other proprietary or domain specific protocols (e.g. other proprietary or domain specific protocols (e.g. bandwidth broker
bandwidth broker related) may also be considered. A related issue is related) may also be considered. A related issue is that NSIS will be
that NSIS will be only one part of the solution: it will always need only one part of the solution: it will always need to interwork with
to interwork with other resource-related protocols (e.g. COPS). other resource-related protocols (e.g. COPS).
Analyzing the constraints on NSIS that come from these requirements Analyzing the constraints on NSIS that come from these requirements
is hard before further refinement of the framework has been carried is hard before further refinement of the framework has been carried
out and critical assumptions pinned down. However, we can identify out and critical assumptions pinned down. However, we can identify
various modes of interoperation, and the attributes of the framework various modes of interoperation, and the attributes of the framework
that will make them easy. that will make them easy.
Firstly, we allow for NSIS use over a 'long range', in conjunction Firstly, we allow for NSIS use over a 'long range', in conjunction
with a different protocol locally (e.g. intra-domain); or, the two with a different protocol locally (e.g. intra-domain); or, the two
roles could be reversed. This is actually very similar to the case of roles could be reversed. This is actually very similar to the case of
skipping to change at page 39, line 26 skipping to change at page 41, line 26
reservation and provisioning. The NSIS protocol may be used to reservation and provisioning. The NSIS protocol may be used to
provide intra-domain or inter-domain QoS bandwidth reservation setup provide intra-domain or inter-domain QoS bandwidth reservation setup
by means of its interaction with the RMF. In what follows we assume 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 that the NEs are colocated with an admission control entity that has
a logical (abstract) view on the resources managed by the RMF, as a logical (abstract) view on the resources managed by the RMF, as
described in section 5.1. described in section 5.1.
The NEs in a domain can interface with an RMF managing the complete The NEs in a domain can interface with an RMF managing the complete
domain, in which case, the abstract topology view provided between domain, in which case, the abstract topology view provided between
NSIS and RMF can be formalized as a Service Level Agreement (SLA). NSIS and RMF can be formalized as a Service Level Agreement (SLA).
This situation is depicted schematically in Figure 6. This situation is depicted schematically in Figure 7.
+----+ NSIS +-----+ NSIS +----+ +----+ NSIS +-----+ NSIS +----+
| NI |------------| NF |-------------| NR | | NI |============| NF |=============| NR |
+----+ +-----+ +----+ +----+ +-----+ +----+
| |
| SLA | SLA
| |
+------+ +------+
| RMF | | RMF |
+------+ +------+
Figure 6: Resource Reservation using RMF as a Server to NSIS Figure 7: Resource Reservation using RMF as a Server to NSIS
In case of centralized RMF, the SLA or its technical part, the In case of centralized RMF, the SLA or its technical part, the
Service Level Specification (SLS) [30] specifies the resource Service Level Specification (SLS) [33] specifies the resource
guarantees that the RMF needs to provide to the NF. These guarantees guarantees that the RMF needs to provide to the NF. These guarantees
apply between one or more ingress and egress points of the network. apply between one or more ingress and egress points of the network.
The SLS also specifies the availability and reliability of the The SLS also specifies the availability and reliability of the
service. In the case of QoS signaling, it may refer to a bandwidth service. In the case of QoS signaling, it may refer to a bandwidth
service with certain performance guarantees regarding delay, jitter service with certain performance guarantees regarding delay, jitter
or packet loss. The SLS interface can be automated by means of an SLS or packet loss. The SLS interface can be automated by means of an SLS
negotiation protocol. This allows for more dynamical SLS negotiation protocol. This allows for more dynamical SLS
modifications and the exchange of notification messages with the NF. modifications and the exchange of notification messages with the NF.
These can for instance be used to provide monitoring feedback from These can for instance be used to provide monitoring feedback from
the RFM to the NF. the RFM to the NF.
skipping to change at page 40, line 45 skipping to change at page 42, line 45
follow up on the delivered performance. In more complex scenarios, it follow up on the delivered performance. In more complex scenarios, it
may use a whole array of network optimization tools in order to may use a whole array of network optimization tools in order to
deliver and maintain service quality according to the SLS. This may deliver and maintain service quality according to the SLS. This may
require network monitoring, the installation and use of appropriate require network monitoring, the installation and use of appropriate
protection mechanisms and providing feedback regarding actual traffic protection mechanisms and providing feedback regarding actual traffic
performance to the NSIS entity. performance to the NSIS entity.
Alternatively, the NSIS protocol may be used for resource Alternatively, the NSIS protocol may be used for resource
provisioning. In that case, the RMF acts as a client towards the NSIS provisioning. In that case, the RMF acts as a client towards the NSIS
protocol, as a particular "application" triggering an NI for protocol, as a particular "application" triggering an NI for
resources in the network. This situation is depicted in Figure 7. resources in the network. This situation is depicted in Figure 8.
+------+ +------+
+----------| RMF |----------+ +----------| RMF |----------+
/ +------+ \ / +------+ \
/ \ / \
/ \ / \
/ \ / \
+----+ NSIS +-----+ NSIS +----+ +----+ NSIS +-----+ NSIS +----+
| NI |------------| NF |-------------| NR | | NI |============| NF |=============| NR |
+----+ +-----+ +----+ +----+ +-----+ +----+
Figure 7: NSIS for Resource Provisioning Figure 8: NSIS for Resource Provisioning
In this case the RMF is providing traffic classification and In this case the RMF is providing traffic classification and
conditioning functions. An example of such functionality is described conditioning functions. An example of such functionality is described
in [31]. The packet "classifiers" select the packets in a traffic in [34]. The packet "classifiers" select the packets in a traffic
stream based on the content of some portion of the packet header. The stream based on the content of some portion of the packet header. The
traffic "conditioner" performs metering, shaping, policing, traffic "conditioner" performs metering, shaping, policing,
scheduling and/or re- marking of packets to ensure that the traffic scheduling and/or re- marking of packets to ensure that the traffic
entering a node conforms to a certain predefined policy. entering a node conforms to a certain predefined policy.
7.3 NSIS Supporting Distributed Resource Management 7.3 NSIS Supporting Distributed Resource Management
Section 7.2 described the situation where NSIS is supporting a Section 7.2 described the situation where NSIS is supporting a
centralized RMF. This section introduces the situation where NSIS is centralized RMF. This section introduces the situation where NSIS is
supporting a distributed RMF. When the RMF is distributed in the supporting a distributed RMF. When the RMF is distributed in the
network, a protocol for communication with the NI, NF, NR may not be network, a protocol for communication with the NI, NF, NR may not be
required. In this case the RMF is providing traffic classification required. In this case the RMF is providing traffic classification
and conditioning functions; an example of such functionality is and conditioning functions; an example of such functionality is
described in [31]. Figure 8 shows how a distributed RMF could described in [34]. Figure 9 shows how a distributed RMF could
interact with the NSIS protocol. interact with the NSIS protocol.
+----+ NSIS +-----+ NSIS +-----+ NSIS +----+ +----+ NSIS +-----+ NSIS +-----+ NSIS +----+
| NI |<========>| NF |<===...===>| NF |<========>| NR | | NI |==========| NF |====...====| NF |==========| NR |
+----+ +-----+ +-----+ +----+ +----+ +-----+ +-----+ +----+
+----+ +-----+ +-----+ +----+ +----+ +-----+ +-----+ +----+
|RMF | | RMF | | RMF | |RMF | |RMF | | RMF | | RMF | |RMF |
+----+ +-----+ +-----+ +----+ +----+ +-----+ +-----+ +----+
Figure 8: Distributed RMF as a server for NSIS Figure 9: Distributed RMF as a server for NSIS
7.4 NSIS for Middlebox Signaling 7.4 NSIS for Middlebox Signaling
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 NSIS to set up flow-related state in middleboxes
(firewalls, NATs, and so on). Requirements for such communication are (firewalls, NATs, and so on). Requirements for such communication are
given in [32], and initial discussions of NSIS-like solutions are given in [35], and initial discussions of NSIS-like solutions are
contained in [33] and [34]. A future version of this document may contained in [36], [37] and [38]. A future version of this document
contain more details on how an NSIS should be used for this type of may contain more details on how an NSIS should be used for this type
signaling application. of signaling application.
7.5 Multi-Level NSIS Signaling 7.5 Multi-Level NSIS Signaling
This section describes a way of separating the NSIS signaling This section describes a way of separating the NSIS signaling
protocol into more than one hierarchical level. In this section three protocol into more than one hierarchical level. In this section three
levels of hierarchy are considered (see Figure 9); however, the levels of hierarchy are considered (see Figure 10); however, the
approach is quite general to more (or fewer) levels: the important approach is quite general to more (or fewer) levels: the important
issue is the use of NSIS at more than one level at all. issue is the use of NSIS at more than one level at all.
The lowest hierarchical level ("level 1") provides basic resource The lowest hierarchical level ("level 1") provides basic resource
management functionality related to scalable, simple and fast soft management functionality related to scalable, simple and fast soft
state maintenance and to transport functions, such as reliable state maintenance and to transport functions, such as reliable
delivery of signaling messages, congestion control notification and delivery of signaling messages, congestion control notification and
load sharing adaptation. Soft state that is maintained by this level load sharing adaptation. Soft state that is maintained by this level
is usually per traffic class based. is usually per traffic class based.
skipping to change at page 42, line 35 skipping to change at page 44, line 35
level 1, also supports transport functions. When an NSIS edge-to-edge level 1, also supports transport functions. When an NSIS edge-to-edge
multi-domain protocol is used, level 2 stretches beyond domain multi-domain protocol is used, level 2 stretches beyond domain
boundaries and is applied on all the edges of the domains that are boundaries and is applied on all the edges of the domains that are
included in the multidomain region. included in the multidomain region.
The third hierarchical level ("level 3") includes a set of upper- The third hierarchical level ("level 3") includes a set of upper-
level signaling functions that are specific to particular signaling level signaling functions that are specific to particular signaling
applications. Such functions could, for example, be security, policy, applications. Such functions could, for example, be security, policy,
billing, etc. billing, etc.
As shown in Figure 9, the three hierarchical levels might be applied As shown in Figure 10, the three hierarchical levels might be applied
on different NSIS entities. on different NSIS entities.
This three-level architecture for NSIS signaling can be provided by This three-level architecture for NSIS signaling can be provided by
using: using:
*) a single end-to-end NSIS protocol that supports all three *) a single end-to-end NSIS protocol that supports all three
hierarchical levels hierarchical levels
*) two independent NSIS protocols: Level 3 is supported by an end- *) two independent NSIS protocols: Level 3 is supported by an end-
to-end NSIS protocol, and levels 1 and 2 are supported by another to-end NSIS protocol, and levels 1 and 2 are supported by another
edge-to-edge NSIS protocol. edge-to-edge NSIS protocol.
|-----| |-------| |-------| |-----| |-----| |-------| |-------| |-----|
|level|<--| level |<--------------------------| level |<->|level| |level|<--| level |<--------------------------| level |<->|level|
| 3 |<--| 3 | | 3 |<->| 3 | | 3 |<--| 3 | | 3 |<->| 3 |
|-----| |-------| |-------| |-----| |-----| |-------| |-------| |-----|
| | | | | | | | | | | | | | | |
| | |-------| |-------| | | | | |-------| |-------| | |
| | | level |<------------------------->| level | | | | | | level |<------------------------->| level | | |
| | | 2 | | 2 | | | | | | 2 | | 2 | | |
| | |-------| |-------| | | | | |-------| |-------| | |
| | | | | | | | | | | | | | | |
|-----| |-------| |-------| |-------| |-------| |-----| |-----| | | |
------- -------| |-------| |-------| |-----|
|level|<->| level |<->| level |<->| level |<->| level |<->|level| |level|<->| level |<->| level |<->| level |<->| level |<->|level|
| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 | | 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |
|-----| |-------| |-------| |-------| |-------| |-----| |-----| |-------| |-------| |-------| |-------| |-----|
NI NF NF NF NF NR NI NF NF NF NF NR
(edge) (interior) (interior) (edge) (edge) (interior) (interior) (edge)
Figure 9: Three level architecture for NSIS signaling Figure 10: Three level architecture for NSIS signaling
The components in the scenario are as follows: The components in the scenario are as follows:
*) NI (NSIS Initiator): can be an end-host or a proxy and can *) NI (NSIS Initiator): can be an end-host or a proxy and can
process and use the "level 1" and "level 3" protocol components process and use the "level 1" and "level 3" protocol components
*) NR (NSIS Responder): can be an end-host or a proxy and can *) NR (NSIS Responder): can be an end-host or a proxy and can
process and use the "level 1" and "level 3" protocol components process and use the "level 1" and "level 3" protocol components
*) NF (NSIS Forwarder) (edge): can be a Diffserv edge, MPLS edge, *) 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" etc. It can process and use the "level 3", "level 2" and "level 1"
protocol components. Usually, "level 2" provides an interworking protocol components. Usually, "level 2" provides an interworking
between "level 1" and "level 3" protocol components. between "level 1" and "level 3" protocol components.
skipping to change at page 44, line 13 skipping to change at page 46, line 13
(Section 3.3.2.) (Section 3.3.2.)
2. It is not clear whether NSIS entities relate to each other only 2. It is not clear whether NSIS entities relate to each other only
locally (peer-peer) or whether longer distance, non-local locally (peer-peer) or whether longer distance, non-local
interactions and state have to be managed and stored. (Section interactions and state have to be managed and stored. (Section
3.3.3.) 3.3.3.)
3. NSIS messages could be addressed either explicitly (to the 3. NSIS messages could be addressed either explicitly (to the
neighboring peer) or implicitly, using the flow endpoint addresses. neighboring peer) or implicitly, using the flow endpoint addresses.
(Section 3.3.4.) (Section 3.3.4.)
4. It is not clear whether the service description semantics (in 4. It is not clear where to draw the boundaries between the NTLP and
theory, opaque to NSIS) need to be analysed in more detail to NSIS signaling layer, and how to establish the extent to which the
determine requirements on the protocol. (Section 3.3.5.) 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, 5. If NSIS has explicit acknowledgement and notification messages,
it is open whether they should relate to anything beyond the it is open whether they should relate to anything beyond the
immediate peer-session. (Section 3.3.6.) immediate peer relationship. (Section 3.3.6.)
6. To function as part of a complete system, the NSIS protocol may 6. To function as part of a complete system, the NSIS protocol may
need to be supported by extensions to other protocols. These need to be supported by extensions to other protocols. These
extensions are still to be identified. (Section 4.2.) extensions are still to be identified. (Section 4.2.)
7. The NSIS protocol could be constructed on the services offered by 7. The NSIS protocol could be constructed on the services offered by
lower layer protocols, but the dividing line between NSIS and these lower layer protocols, but the dividing line between NSIS and these
lower layers is not fixed. Use of standard lower layer protocols may 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. be difficult if 'end-to-end addressing' (see section 3.3.4) is used.
(Section 4.3.1.) (Section 4.3.1.)
skipping to change at page 45, line 7 skipping to change at page 47, line 7
10. The correct flow identification semantics need to be defined in 10. The correct flow identification semantics need to be defined in
the case where mobility encapsulations might make it ambiguous which the case where mobility encapsulations might make it ambiguous which
addresses to use. (Section 5.3.1.) addresses to use. (Section 5.3.1.)
11. The interactions between mobility and resource signaling during 11. The interactions between mobility and resource signaling during
path updating need to be further analyzed, especially from the point path updating need to be further analyzed, especially from the point
of view of combined overall latency. (Section 5.3.2 and 5.3.3.) of view of combined overall latency. (Section 5.3.2 and 5.3.3.)
9. Change History 9. Change History
9.1 Changes from draft-hancock-nsis-fw-00.txt 9.1 Changes from draft-ietf-nsis-fw-00.txt
1. Editorial fix in 'classifier' definition (section 2).
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
1. Changed title, document name and dates. 1. Changed title, document name and dates.
2. Updated references. 2. Updated references.
3. Editorial fix in NSIS Forwarder definition (section 2). 3. Editorial fix in NSIS Forwarder definition (section 2).
4. Revised section 3.2.1 (path-coupled terminology), now used 4. Revised section 3.2.1 (path-coupled terminology), now used
consistently in the rest of the document. Likewise, 'signaling consistently in the rest of the document. Likewise, 'signaling
application' terminology used consistently in remainder of document. application' terminology used consistently in remainder of document.
5. Split old section 5 into new sections (new 5 "real interactions", 5. Split old section 5 into new sections (new 5 "real interactions",
new 7 "how to use NSIS to do something useful"). new 7 "how to use NSIS to do something useful").
6. Added new resource management text for section 5.1; slight 6. Added new resource management text for section 5.1; slight
smoothing to balance centralized and distributed, and comment on smoothing to balance centralized and distributed, and comment on
NI/NF/NR distinction. NI/NF/NR distinction.
7. Added VRRP placeholder in routing section of section 5 (5.2.5). 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 8. Added section 5.4 on NSIS/NAT interactions based on Melinda's
email. email.
9. Added new text for resource management in section 7.2; slightly 9. Added new text for resource management in section 7.2; slightly
trimmed and made clearer that it is mainly discussing the centralized 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 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 OK to use the Q-word here since we aren't talking about the NSIS
skipping to change at page 45, line 43 skipping to change at page 48, line 31
12. Moved open issues from section 3.3.1 to new section 8 (left 12. Moved open issues from section 3.3.1 to new section 8 (left
assumptions behind). assumptions behind).
13. Added this changes section 9. 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 Brunner, M., "Requirements for QoS Signaling Protocols", draft-
ietf-nsis-req-04.txt (work in progress), August 2002 ietf-nsis-req-05.txt (work in progress), November 2002
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
4 Tschofenig, H., "NSIS Threats", draft-tschofenig-nsis-threats- 4 Manner, J. and X. Fu, "Analysis of Existing Quality of Service
01.txt (work in progress), July 2002 Signaling Protocols", draft-ietf-nsis-signalling-analysis-00.txt
5 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 (work in progress), October 2002
6 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 5 Tschofenig, H., "NSIS Threats", draft-ietf-nsis-threats-00.txt
October 1999 (work in progress), October 2002
7 Braden, R., "A Two-Level Architecture for Internet Signaling", 6 Katz, D., "IP Router Alert Option", RFC 2113, February 1997
draft-braden-2level-signal-arch-00.txt (work in progress),
November 2001 (expired)
8 Stewart, R. et al., "Stream Control Transmission Protocol", RFC 7 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,
2960, October 2000 October 1999
9 Kent, S., R. Atkinson, "Security Architecture for the Internet 8 Braden, R., and B. Lindell, "A Two-Level Architecture for Internet
Signaling", draft-braden-2level-signaling-01.txt (work in
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
Protocol", RFC 2401, November 1998 Protocol", RFC 2401, November 1998
10 Westberg, L., et al., "Framework for Edge-to-Edge NSIS Signaling", 11 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework
draft-westberg-nsis-edge-edge-framework-00.txt (work in progress), for Edge-to Edge NSIS Signaling", draft
May 2002 - -westberg-nsis-edge-edge-
framework-00.txt (work in progress), May 2002
11 Apostolopoulos, G., et al., "QoS Routing Mechanisms and OSPF 12 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda,
Extensions", RFC 2676, August 1999 T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC
2676, August 1999
12 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 13 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995 1771, March 1995
13 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 14 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)
14 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of 15 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-00.txt (work in
progress), May 2002 progress), May 2002
15 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service 16 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service
Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft- Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft-
jacquenet-qos-nlri-04.txt (work in progress), March 2002 jacquenet-qos-nlri-04.txt (work in progress), March 2002 (expired)
16 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White, 17 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White,
"Controlling the redistribution of BGP Routes", draft-bonaventure- "Controlling the redistribution of BGP Routes", draft-bonaventure-
bgp-redistribution-02.txt (work in progress), February 2002 bgp-redistribution-02.txt (work in progress), February 2002
(expired)
17 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 18 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
Version 1 Functional Specification", RFC 2205, September 1997 ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997
18 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D. 19 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D.
Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management
in Diffserv (RMD) Framework", draft-westberg-rmd-framework-01.txt in Diffserv (RMD) Framework", draft-westberg-rmd-framework-02.txt
(work in progress), February 2002 (work in progress), October 2002
20 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,
19 Knight, S. et al., "Virtual Router Redundancy Protocol", RFC2338, P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy
April 1998 Protocol", RFC2338, April 1998
20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 21 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-
thomas-seamoby-rsvp-analysis-00.txt (work in progress), February thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002
2001 (expired)
21 Partain, D. et al., "Resource Reservation Issues in Cellular Radio 22 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource
Access Networks", draft-westberg-rmd-cellular-issues-01.txt (work Reservation Issues in Cellular Radio Access Networks", draft-
in progress), June 2002 westberg-rmd-cellular-issues-01.txt (work in progress), June 2002
22 Shen, C. et al., "An Interoperation Framework for Using RSVP in 23 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)
23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt 24 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt
(work in progress), May 2002 (work in progress), May 2002
24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 25 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 January 2002 (expired)
26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6 27 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6
Networks", draft-kan-qos-framework-00.txt (work in progress), Networks", draft-kan-qos-framework-01.txt (work in progress), July
April 2002 2002
27 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 28 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in
candidate access router discovery for seamless IP-level handoffs",
draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress),
October 2002
29 Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC3374,
September 2002
30 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999 (NAT) Terminology and Considerations", RFC2663, August 1999
28 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 31 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
Traversal of UDP Through Network Address Translators", draft-ietf-
midcom-stun-03.txt (work in progress), October 2002
29 Rosenberg, J. et al., "STUN - Simple Traversal of UDP Through 33 Danny Goderis, et al. "Service Level Specification Semantics and
Network Address Translators", draft-ietf-midcom-stun-02.txt (work
in progress), August 2002
30 Danny Goderis, et al. "Service Level Specification Semantics and
Parameters", draft-tequila-sls-02.txt (work in progress), February Parameters", draft-tequila-sls-02.txt (work in progress), February
2002 (expired)
34 Blake, S., D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services", RFC2475, December 1998
35 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
Communications (midcom) Protocol Requirements", RFC3304, August
2002 2002
31 Blake, S. et al, "An Architecture for Differentiated Services",
RFC2475, December 1998
32 Swale, R. P. et al., "Middlebox Communications (midcom) Protocol 36 Shore, M., "Towards a Network-friendlier Midcom", draft-shore-
Requirements", RFC3304, August 2002 friendly-midcom-01.txt (work in progress), June 2002
33 Shore, M., "The TIST (Topology-Insensitive Service Traversal) 37 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
34 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS 38 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, Maarten Buchli, The authors would like to thank Anders Bergsten, Bob Braden, Maarten
Melinda Shore and Hannes Tschofenig for significant contributions in Buchli, Melinda Shore and Hannes Tschofenig for significant
particular areas of this draft. In addition, the authors would like contributions in particular areas of this draft. In addition, the
to acknowledge Marcus Brunner, Danny Goderis, Eleanor Hepworth, authors would like to acknowledge Marcus Brunner, Danny Goderis,
Cornelia Kappler, Hans De Neve, David Partain, Vlora Rexhepi, and Eleanor Hepworth, Cornelia Kappler, Hans De Neve, David Partain,
Lars Westberg for insights and inputs during this and previous Vlora Rexhepi, and Lars Westberg for insights and inputs during this
framework activities. and previous framework activities.
Author's Addresses Author's 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 49, line 28 skipping to change at page 52, line 37
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
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This "Copyright (C) The Internet Society (2002). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
 End of changes. 

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