draft-ietf-nsis-fw-06.txt   draft-ietf-nsis-fw-07.txt 
Next Steps in Signaling R. Hancock Next Steps in Signaling R. Hancock
Internet-Draft Siemens/RMR Internet-Draft Siemens/RMR
Expires: January 3, 2005 G. Karagiannis Expires: May 2, 2005 G. Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
J. Loughney J. Loughney
Nokia Nokia
S. van den Bosch S. van den Bosch
Alcatel Alcatel
July 5, 2004 November 1, 2004
Next Steps in Signaling: Framework Next Steps in Signaling: Framework
draft-ietf-nsis-fw-06 draft-ietf-nsis-fw-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2005. This Internet-Draft will expire on May 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
The Next Steps in Signaling working group is considering protocols The Next Steps in Signaling working group is considering protocols
for signaling information about a data flow along its path in the for signaling information about a data flow along its path in the
network. Based on existing work on signaling requirements, this network. The NSIS suite of protocols is envisioned to support
document proposes an architectural framework for such signaling various signaling applications that need to install and/or manipulate
protocols. such state in the network. Based on on existing work on signaling
requirements, this document proposes an architectural framework for
these signaling protocols.
This document provides a model for the network entities that take This document provides a model for the network entities that take
part in such signaling, and the relationship between signaling and part in such signaling, and the relationship between signaling and
the rest of network operation. We decompose the overall signaling the rest of network operation. We decompose the overall signaling
protocol suite into a generic (lower) layer, with separate upper protocol suite into a generic (lower) layer, with separate upper
layers for each specific signaling application. An initial proposal layers for each specific signaling application.
for the split between these layers is given, describing the overall
functionality of the lower layer, and discussing the ways that upper
layer behavior can be adapted to specific signaling application
requirements.
This framework also considers the general interactions between
signaling and other network layer functions, specifically routing,
mobility, and address translators. The different events that impact
signaling operation are described, along with how their handling
should be divided between the generic and application-specific
layers. Finally, an example signaling application (for Quality of
Service) is described in more detail.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definition of the Signaling Problem . . . . . . . . . . . 5 1.1 Definition of the Signaling Problem . . . . . . . . . . . 4
1.2 Scope and Structure of the NSIS Framework . . . . . . . . 5 1.2 Scope and Structure of the NSIS Framework . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Signaling Scenarios and Protocol Structure . . . . 9 3. Overview of Signaling Scenarios and Protocol Structure . . . . 8
3.1 Fundamental Signaling Concepts . . . . . . . . . . . . . . 9 3.1 Fundamental Signaling Concepts . . . . . . . . . . . . . . 8
3.1.1 Simple Network and Signaling Topology . . . . . . . . 9 3.1.1 Simple Network and Signaling Topology . . . . . . . . 8
3.1.2 Path-Coupled and Path-Decoupled Signaling . . . . . . 10 3.1.2 Path-Coupled and Path-Decoupled Signaling . . . . . . 9
3.1.3 Signaling to Hosts, Networks and Proxies . . . . . . . 10 3.1.3 Signaling to Hosts, Networks and Proxies . . . . . . . 9
3.1.4 Signaling Messages and Network Control State . . . . . 13 3.1.4 Signaling Messages and Network Control State . . . . . 12
3.1.5 Data Flows and Sessions . . . . . . . . . . . . . . . 14 3.1.5 Data Flows and Sessions . . . . . . . . . . . . . . . 13
3.2 Layer Model for the Protocol Suite . . . . . . . . . . . . 14 3.2 Layer Model for the Protocol Suite . . . . . . . . . . . . 13
3.2.1 Layer Model Overview . . . . . . . . . . . . . . . . . 14 3.2.1 Layer Model Overview . . . . . . . . . . . . . . . . . 13
3.2.2 Layer Split Concept . . . . . . . . . . . . . . . . . 15 3.2.2 Layer Split Concept . . . . . . . . . . . . . . . . . 15
3.2.3 Bypassing Intermediate Nodes . . . . . . . . . . . . . 16 3.2.3 Bypassing Intermediate Nodes . . . . . . . . . . . . . 16
3.2.4 Core NSIS Transport Layer Functionality . . . . . . . 18 3.2.4 Core NSIS Transport Layer Functionality . . . . . . . 17
3.2.5 State Management Functionality . . . . . . . . . . . . 18 3.2.5 State Management Functionality . . . . . . . . . . . . 18
3.2.6 Path De-Coupled Operation . . . . . . . . . . . . . . 20 3.2.6 Path De-Coupled Operation . . . . . . . . . . . . . . 19
3.3 Signaling Application Properties . . . . . . . . . . . . . 21 3.3 Signaling Application Properties . . . . . . . . . . . . . 20
3.3.1 Sender/Receiver Orientation . . . . . . . . . . . . . 21 3.3.1 Sender/Receiver Orientation . . . . . . . . . . . . . 20
3.3.2 Uni- and Bi-Directional Operation . . . . . . . . . . 22 3.3.2 Uni- and Bi-Directional Operation . . . . . . . . . . 21
3.3.3 Heterogeneous Operation . . . . . . . . . . . . . . . 22 3.3.3 Heterogeneous Operation . . . . . . . . . . . . . . . 21
3.3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . 23 3.3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . 22
3.3.5 Peer-Peer and End-End Relationships . . . . . . . . . 23 3.3.5 Peer-Peer and End-End Relationships . . . . . . . . . 22
3.3.6 Acknowledgements and Notifications . . . . . . . . . . 24 3.3.6 Acknowledgements and Notifications . . . . . . . . . . 23
3.3.7 Security and Other AAA Issues . . . . . . . . . . . . 24 3.3.7 Security and Other AAA Issues . . . . . . . . . . . . 24
4. The NSIS Transport Layer Protocol . . . . . . . . . . . . . . 26 4. The NSIS Transport Layer Protocol . . . . . . . . . . . . . . 25
4.1 Internal Protocol Components . . . . . . . . . . . . . . . 26 4.1 Internal Protocol Components . . . . . . . . . . . . . . . 25
4.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Classical Transport Functions . . . . . . . . . . . . . . 28 4.3 Classical Transport Functions . . . . . . . . . . . . . . 27
4.4 Lower Layer Interfaces . . . . . . . . . . . . . . . . . . 29 4.4 Lower Layer Interfaces . . . . . . . . . . . . . . . . . . 28
4.5 Upper Layer Services . . . . . . . . . . . . . . . . . . . 30 4.5 Upper Layer Services . . . . . . . . . . . . . . . . . . . 29
4.6 Identity Elements . . . . . . . . . . . . . . . . . . . . 31 4.6 Identity Elements . . . . . . . . . . . . . . . . . . . . 30
4.6.1 Flow Identification . . . . . . . . . . . . . . . . . 31 4.6.1 Flow Identification . . . . . . . . . . . . . . . . . 30
4.6.2 Session Identification . . . . . . . . . . . . . . . . 32 4.6.2 Session Identification . . . . . . . . . . . . . . . . 31
4.6.3 Signaling Application Identification . . . . . . . . . 32 4.6.3 Signaling Application Identification . . . . . . . . . 31
4.7 Security Properties . . . . . . . . . . . . . . . . . . . 33 4.7 Security Properties . . . . . . . . . . . . . . . . . . . 32
5. Interactions with Other Protocols . . . . . . . . . . . . . . 34 5. Interactions with Other Protocols . . . . . . . . . . . . . . 33
5.1 IP Routing Interactions . . . . . . . . . . . . . . . . . 34 5.1 IP Routing Interactions . . . . . . . . . . . . . . . . . 33
5.1.1 Load Sharing and Policy-Based Forwarding . . . . . . . 34 5.1.1 Load Sharing and Policy-Based Forwarding . . . . . . . 33
5.1.2 Route Changes . . . . . . . . . . . . . . . . . . . . 35 5.1.2 Route Changes . . . . . . . . . . . . . . . . . . . . 34
5.2 Mobility and Multihoming Interactions . . . . . . . . . . 37 5.2 Mobility and Multihoming Interactions . . . . . . . . . . 36
5.3 Interactions with NATs . . . . . . . . . . . . . . . . . . 39 5.3 Interactions with NATs . . . . . . . . . . . . . . . . . . 38
5.4 Interactions with IP Tunneling . . . . . . . . . . . . . . 39 5.4 Interactions with IP Tunneling . . . . . . . . . . . . . . 38
6. Signaling Applications . . . . . . . . . . . . . . . . . . . . 41 6. Signaling Applications . . . . . . . . . . . . . . . . . . . . 40
6.1 Signaling for Quality of Service . . . . . . . . . . . . . 41 6.1 Signaling for Quality of Service . . . . . . . . . . . . . 40
6.1.1 Protocol Message Semantics . . . . . . . . . . . . . . 41 6.1.1 Protocol Message Semantics . . . . . . . . . . . . . . 40
6.1.2 State Management . . . . . . . . . . . . . . . . . . . 42 6.1.2 State Management . . . . . . . . . . . . . . . . . . . 41
6.1.3 Route Changes and QoS Reservations . . . . . . . . . . 43 6.1.3 Route Changes and QoS Reservations . . . . . . . . . . 42
6.1.4 Resource Management Interactions . . . . . . . . . . . 44 6.1.4 Resource Management Interactions . . . . . . . . . . . 43
6.2 Other Signaling Applications . . . . . . . . . . . . . . . 45 6.2 Other Signaling Applications . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47
8.2 Informative References . . . . . . . . . . . . . . . . . . . 47 8.2 Informative References . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . 53 Intellectual Property and Copyright Statements . . . . . . . . 53
1. Introduction 1. Introduction
skipping to change at page 8, line 7 skipping to change at page 7, line 7
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 Receiver: the node in the network which is receiving the data packets
in a flow. in a flow.
Sender: the node in the network which is sending the data packets in Sender: the node in the network which is sending the data packets in
a flow. a flow.
Session: application layer flow of information for which some network Session: application layer flow of information for which some network
control state information is to be manipulated or monitored (see control state information is to be manipulated or monitored (see
Section 4.6.2). Section 3.1.5).
Signaling application: the purpose of the NSIS signaling: a service Signaling application: the purpose of the NSIS signaling: a signaling
could be QoS management, firewall control, and so on. Totally application could be QoS management, firewall control, and so on.
distinct from any specific user application. Totally distinct from any specific user application.
3. Overview of Signaling Scenarios and Protocol Structure 3. Overview of Signaling Scenarios and Protocol Structure
3.1 Fundamental Signaling Concepts 3.1 Fundamental Signaling Concepts
3.1.1 Simple Network and Signaling Topology 3.1.1 Simple Network and Signaling Topology
The NSIS suite of protocols is envisioned to support various The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state signaling applications that need to install and/or manipulate state
in the network. This state is related to a data flow and is in the network. This state is related to a data flow and is
skipping to change at page 14, line 17 skipping to change at page 13, line 17
Formally, a data flow is a (unidirectional) sequence of packets Formally, a data flow is a (unidirectional) sequence of packets
between the same endpoints which all follow a unique path through the between the same endpoints which all follow a unique path through the
network (determined by IP routing and other network configuration). network (determined by IP routing and other network configuration).
A flow is defined by a packet classifier (in the simplest cases, just A flow is defined by a packet classifier (in the simplest cases, just
the destination address and topological origin are needed). In the destination address and topological origin are needed). In
general we assume that when discussing only the data flow path, we general we assume that when discussing only the data flow path, we
only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple
or equivalent). or equivalent).
A session is an application layer concept for a (unidirectional) flow A session is an application layer concept for an exchange of packets
of information between two endpoints, for which some network state is between two endpoints, for which some network state is to be
to be allocated or monitored. (Note that this use of the term allocated or monitored. In simple cases, a session may map to a
'session' is not identical to the usage in RSVP. It is closer to the specific flow; however, signaling applications are allowed to create
session concept of, for example, the Session Initiation Protocol.) more flexible flow:session relationships. (Note that this concept of
'session' is different from RSVP, which defines a session as a flow
with a specific destination address and transport protocol. The NSIS
usage is closer to the session concepts of higher layer protocols.)
The simplest service provided by NSIS signaling protocols is The simplest service provided by NSIS signaling protocols is
management of network control state at the level of a specific flow, management of network control state at the level of a specific flow,
as described in the previous subsection. In particular, it should be as described in the previous subsection. In particular, it should be
possible to monitor routing updates as they change the path taken by possible to monitor routing updates as they change the path taken by
a flow and, for example, update network state appropriately. This is a flow and, for example, update network state appropriately. This is
no different from the case for RSVP (local path repair). Where there no different from the case for RSVP (local path repair). Where there
is a 1:1 flow:session relationship, this is all that is required. is a 1:1 flow:session relationship, this is all that is required.
However, for some more complex scenarios (especially mobility and However, for some more complex scenarios (especially mobility and
skipping to change at page 20, line 8 skipping to change at page 19, line 14
triggers, the NTLP takes no action itself on such events, other triggers, the NTLP takes no action itself on such events, other
than to ensure that subsequent signaling messages are correctly than to ensure that subsequent signaling messages are correctly
routed. routed.
5. The existence of these triggers doesn't replace NSLP refreshes as 5. The existence of these triggers doesn't replace NSLP refreshes as
the mechanism for maintaining liveness at the signaling the mechanism for maintaining liveness at the signaling
application level. In this sense, up/down notifications are application level. In this sense, up/down notifications are
advisories which allow faster reaction to events in the network, advisories which allow faster reaction to events in the network,
but shouldn't be built into NSLP semantics. (This is essentially but shouldn't be built into NSLP semantics. (This is essentially
the same distinction - with the same rationale - as SNMP makes the same distinction - with the same rationale - as SNMP makes
between traps and normal message exchanges.) between notifications and normal message exchanges.)
3.2.6 Path De-Coupled Operation 3.2.6 Path De-Coupled Operation
Path-decoupled signaling is defined as signaling for state Path-decoupled signaling is defined as signaling for state
installation along the data path, without the restriction of passing installation along the data path, without the restriction of passing
only through nodes that are located on the data path. Signaling only through nodes that are located on the data path. Signaling
messages can be routed to nodes off the data path, but which are messages can be routed to nodes off the data path, but which are
(presumably) aware of it. This allows a looser coupling between (presumably) aware of it. This allows a looser coupling between
signaling and data plane nodes, e.g. at the autonomous system level. signaling and data plane nodes, e.g. at the autonomous system level.
Although support for path-decoupled operation is not one of the
initial goals of the NSIS work, this section is included for
completeness and to capture some initial considerations for future
reference.
The main advantages of path-decoupled signaling are ease of The main advantages of path-decoupled signaling are ease of
deployment and support of additional functionality. The ease of deployment and support of additional functionality. The ease of
deployment comes from a restriction of the number of impacted nodes deployment comes from a restriction of the number of impacted nodes
in case of deployment and/or upgrade of an NSLP. It would allow, for in case of deployment and/or upgrade of an NSLP. It would allow, for
instance, deploying a solution without upgrading any of the routers instance, deploying a solution without upgrading any of the routers
in the data plane. Additional functionality that can be supported in the data plane. Additional functionality that can be supported
includes the use of off-path proxies to support authorization or includes the use of off-path proxies to support authorization or
accounting architectures. accounting architectures.
skipping to change at page 36, line 48 skipping to change at page 35, line 48
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 state management with high-availability flow or per class state management with high-availability
characteristics, i.e. with rapid transparent recovery even in the characteristics, i.e. with rapid transparent recovery even in the
presence of route changes. This may need interactions with protocols presence of route changes. This may need interactions with protocols
which are used to manage the routing in this case, such as VRRP [18]. which are used to manage the routing in this case, such as VRRP [18].
Our basic assumption about such interactions is that the NTLP would Our basic assumption about such interactions is that the NTLP would
be responsible for detecting the route change and ensuring that be responsible for detecting the route change and ensuring that
signaling messages were re-routed consistently (in the same way as signaling messages were re-routed consistently (in the same way as
the data traffic)); but that the further state re-synchronization the data traffic); but that the further state re-synchronization
(including failover between 'main' and 'standby' nodes in the high (including failover between 'main' and 'standby' nodes in the high
availability case) would be the responsibility of the signaling availability case) would be the responsibility of the signaling
application and its NSLP, possibly triggered by the NTLP. application and its NSLP, possibly triggered by the NTLP.
5.2 Mobility and Multihoming Interactions 5.2 Mobility and Multihoming Interactions
The issues associated with mobility and multihoming are a The issues associated with mobility and multihoming are a
generalization of the basic route change case of the previous generalization of the basic route change case of the previous
section. As well as the fact that packets for a given session are no section. As well as the fact that packets for a given session are no
longer traveling over a single topological path, the following extra longer traveling over a single topological path, the following extra
skipping to change at page 42, line 12 skipping to change at page 41, line 12
it. Note that it is left open if the responder can release or modify it. Note that it is left open if the responder can release or modify
a reservation, during or after setup. This seems mainly a matter of a reservation, during or after setup. This seems mainly a matter of
assumptions about authorization, and the possibilities might depend assumptions about authorization, and the possibilities might depend
on resource type specifics. on resource type specifics.
The table also explicitly includes a refresh operation. This does The table also explicitly includes a refresh operation. This does
nothing to a reservation except extend its lifetime, and is one nothing to a reservation except extend its lifetime, and is one
possible state management mechanism (see next section). possible state management mechanism (see next section).
+-----------+-----------+-------------------------------------------+ +-----------+-----------+-------------------------------------------+
| | | Operation | | Operation | Direction | Operation |
| Operation | Direction | |
+-----------+-----------+-------------------------------------------+ +-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow | | Request | I-->R | Create a new reservation for a flow |
| | | | | | | |
| Modify | I-->R | Modify an existing reservation | | Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | | | | (&R-->I?) | |
| | | | | | | |
| Release | I-->R | Delete (tear down) an existing | | Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation | | | (&R-->I?) | reservation |
| | | | | | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a | | Accept/ | R-->I | Confirm (possibly modified?) or reject a |
skipping to change at page 46, line 15 skipping to change at page 45, line 15
7. Security Considerations 7. Security Considerations
This document describes a framework for signaling protocols which This document describes a framework for signaling protocols which
assumes a two-layer decomposition, with a common lower layer (NTLP) assumes a two-layer decomposition, with a common lower layer (NTLP)
supporting a family of signaling application specific upper layer supporting a family of signaling application specific upper layer
protocols (NSLPs). The overall security considerations for the protocols (NSLPs). The overall security considerations for the
signaling therefore depend on the joint security properties assumed signaling therefore depend on the joint security properties assumed
or demanded for each layer. or demanded for each layer.
Security for the NTLP is discussed in Section 4.7. We have assumed Security for the NTLP is discussed in Section 4.7. We have assumed
that the role of the NTLP will be to provide message protection over that, apart from being resistant to denial of service attacks against
the scope of a single peer relationship, between adjacent signaling itself, the main role of the NTLP will be to provide message
application entities (see Section 3.2.3 for a discussion of the case protection over the scope of a single peer relationship, between
where these entities are separated by more than one NTLP hop). These adjacent signaling application entities. (See Section 3.2.3 for a
functions can most likely be provided by some kind of channel discussion of the case where these entities are separated by more
security mechanism using an external key management mechanism based than one NTLP hop.) These functions can ideally be provided by an
on mutual authentication. In addition, the NTLP should be resilient existing channel security mechanism, preferably using an external key
against denial of service attacks on the protocol itself. management mechanism based on mutual authentication. Examples of
possible mechanisms are TLS, IPsec and SSH. However, there are
interactions between the actual choice of security protocol and the
rest of the NTLP design. Primarily, most existing channel security
mechanisms require explicit identification of the peers involved at
the network and/or transport level. This conflicts with those
aspects of path-coupled signaling operation (e.g. discovery) where
this information is not even implicitly available because peer
identities are unknown; the impact of this 'next-hop problem' on RSVP
design is discussed in the security properties document [6] and also
influences many parts of the threat analysis [2]. Therefore, this
framework does not mandate the use of any specific channel security
protocol; instead, this has to be integrated with the design of the
NTLP as a whole.
Security for the NSLPs is entirely dependent on signaling application Security for the NSLPs is entirely dependent on signaling application
requirements. In some cases, no additional protection may be requirements. In some cases, no additional protection may be
required compared to what is provided by the NTLP. In other cases, required compared to what is provided by the NTLP. In other cases,
more sophisticated object-level protection and the use of public key more sophisticated object-level protection and the use of public key
based solutions may be required. In addition, the NSLP needs to based solutions may be required. In addition, the NSLP needs to
consider the authorisation requirements of the signaling application. consider the authorisation requirements of the signaling application.
Authorisation is a complex topic, for which a very brief overview is Authorisation is a complex topic, for which a very brief overview is
provided in Section 3.3.7. provided in Section 3.3.7.
skipping to change at page 47, line 13 skipping to change at page 47, line 13
refinement of the NSIS threats work begun in [2]. refinement of the NSIS threats work begun in [2].
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004. April 2004.
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-05 (work in progress), June 2004. draft-ietf-nsis-threats-06 (work in progress), October 2004.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS) [3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003. Solution for Mobile IP", RFC 3583, September 2003.
[4] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore, [4] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements", RFC "Middlebox Communications (midcom) Protocol Requirements", RFC
3304, August 2002. 3304, August 2002.
8.2 Informative References 8.2 Informative References
[5] Manner, J., "Analysis of Existing Quality of Service Signaling [5] Manner, J., "Analysis of Existing Quality of Service Signaling
Protocols", draft-ietf-nsis-signalling-analysis-04 (work in Protocols", draft-ietf-nsis-signalling-analysis-04 (work in
progress), May 2004. progress), May 2004.
[6] Tschofenig, H., "RSVP Security Properties", [6] Tschofenig, H., "RSVP Security Properties",
draft-ietf-nsis-rsvp-sec-properties-04 (work in progress), draft-ietf-nsis-rsvp-sec-properties-05 (work in progress),
February 2004. September 2004.
[7] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [7] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC [9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
2711, October 1999. 2711, October 1999.
skipping to change at page 48, line 40 skipping to change at page 48, line 40
9 - 12 2001. 9 - 12 2001.
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, [20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth,
E. and Y. Khouaja, "Evaluation of Mobility and QoS E. and Y. Khouaja, "Evaluation of Mobility and QoS
Interaction", Computer Networks Volume 38, Issue 2, pp 137-163, Interaction", Computer Networks Volume 38, Issue 2, pp 137-163,
5 February 2002. 5 February 2002.
[21] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [21] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[22] Trossen, D., Krishnamurthi, G., Chaskar, H. and J. Kempf, [22] Liebsch, M., "Candidate Access Router Discovery",
"Issues in candidate access router discovery for seamless draft-ietf-seamoby-card-protocol-08 (work in progress),
IP-level handoffs", draft-ietf-seamoby-cardiscovery-issues-04 September 2004.
(work in progress), October 2002.
[23] Kempf, J., "Problem Description: Reasons For Performing Context [23] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374, Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002. September 2002.
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", [25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000. RFC 2765, February 2000.
[26] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - [26] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP [27] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000. Operation Over IP Tunnels", RFC 2746, January 2000.
[28] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for [28] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-05
(work in progress), May 2004. (work in progress), October 2004.
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol [29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May (NSLP)", draft-ietf-nsis-nslp-natfw-04 (work in progress),
2004. October 2004.
[30] Braden, B., Clark, D. and S. Shenker, "Integrated Services in [30] Braden, B., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994. the Internet Architecture: an Overview", RFC 1633, June 1994.
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., [31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
Partain, D., Pop, O., Rexhepi, V., Szabo, R. and A. Takacs, Partain, D., Pop, O., Rexhepi, V., Szabo, R. and A. Takacs,
"Resource Management in Diffserv (RMD): A Functionality and "Resource Management in Diffserv (RMD): A Functionality and
Performance Behavior Overview", Seventh International Workshop Performance Behavior Overview", Seventh International Workshop
on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April
2002. 2002.
 End of changes. 

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