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