< draft-ietf-nsis-qos-nslp-00.txt		draft-ietf-nsis-qos-nslp-01.txt >
	NSIS Working Group		NSIS Working Group
	Internet Draft Sven Van den Bosch (Editor)		Internet Draft Sven Van den Bosch (Editor)
	Alcatel		Alcatel
	Georgios Karagiannis		Georgios Karagiannis
	Univ. of Twente/Ericsson		Univ. of Twente/Ericsson
	Andrew McDonald		Andrew McDonald
	Siemens/Roke Manor Research		Siemens/Roke Manor Research
	Document: draft-ietf-nsis-qos-nslp-00.txt		Document: draft-ietf-nsis-qos-nslp-01.txt
	Expires: March 2004 September 2003		Expires: April 2004 October 2003
	NSLP for Quality-of-Service signaling		NSLP for Quality-of-Service signaling
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		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.
	Abstract		Abstract
	This draft describes an NSIS Signaling Layer Protocol (NSLP) for		This draft describes an NSIS Signaling Layer Protocol (NSLP) for
	signaling QoS reservations in the Internet. It is in accordance with		signaling QoS reservations in the Internet. It is in accordance with
	the framework and requirements developed in NSIS.		the framework and requirements developed in NSIS.
	Together with the NTLP, it provides functionality similar to RSVP and		Together with the NTLP, it provides functionality similar to RSVP and
	extends it. The QoS-NSLP is independent of the underlying QoS		extends it. The QoS-NSLP is independent of the underlying QoS
	specification or architecture and provides support for different		specification or architecture and provides support for different
	reservation models. It is simplified by the elimination of support		reservation models. It is simplified by the elimination of support
	for multicast flows.		for multicast flows.
	NSLP for Quality-of-Service signaling September 2003		NSLP for Quality-of-Service signaling October 2003
	This version of the draft focuses on the basic protocol structure. It		This version of the draft focuses on the basic protocol structure. It
	identifies the different message types and describes the basic		identifies the different message types and describes the basic
	operation of the protocol to create, refresh, modify and teardown a		operation of the protocol to create, refresh, modify and teardown a
	reservation or to obtain information on the characteristics of the		reservation or to obtain information on the characteristics of the
	associated data path.		associated data path.
	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 [1].		document are to be interpreted as described in RFC-2119 [1].
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1 Scope and background.......................................3		1.1 Scope and background........................................3
	1.2 Model of operation.........................................3		1.2 Model of operation..........................................3
	1.3 Terminology................................................6		1.3 Terminology.................................................6
	2. Protocol design principles.....................................7		2. Protocol design principles.....................................7
	2.1 Basic protocol structure...................................7		2.1 Basic protocol structure....................................7
	2.2 QoS model..................................................8		2.2 QoS model...................................................8
	2.3 Authentication and authorization...........................9		2.3 Authentication and authorization............................9
	2.4 Control Information........................................9		2.4 Control Information.........................................9
	2.5 Nested protocol operation.................................10		2.5 Nested protocol operation..................................10
	2.6 Protocol extensibility....................................11		2.6 Protocol extensibility.....................................11
	2.7 Implementation flexibility for scalability................11		2.7 Implementation flexibility for scalability.................11
	3. Basic message types...........................................12		3. Basic message types...........................................12
	3.1 RESERVE...................................................12		3.1 RESERVE....................................................12
	3.2 QUERY.....................................................14		3.2 QUERY......................................................14
	3.3 RESPONSE..................................................14		3.3 RESPONSE...................................................15
	3.4 NOTIFY....................................................15		3.4 NOTIFY.....................................................15
	4. Basic outline of operation....................................15		4. Basic outline of operation....................................16
	4.1 Making a reservation......................................15		4.1 Making a reservation.......................................16
	4.2 Refreshing a reservation..................................17		4.2 Refreshing a reservation...................................17
	4.3 Sending a response........................................18		4.3 Sending a response.........................................18
	4.4 Performing a query........................................19		4.4 Performing a query.........................................19
	4.5 Tearing down a reservation................................19		4.5 Tearing down a reservation.................................20
	5. IANA section..................................................20		5. IANA section..................................................20
	6. Requirements for the NSIS Transport Layer Protocol (NTLP).....20		6. Requirements for the NSIS Transport Layer Protocol (NTLP).....21
	6.1 Support for stateless operation...........................20		6.1 Support for stateless operation............................21
	6.2 Support for Source Identification Information (SII).......21		6.2 Support for Source Identification Information (SII)........21
	6.3 Last node detection.......................................21		6.3 Last node detection........................................22
	6.4 Re-routing detection......................................22		6.4 Re-routing detection.......................................22
	6.5 Performance requirements..................................22		6.5 Performance requirements...................................22
	7. Open issues...................................................22		7. Open issues...................................................23
	7.1 Refinements of this version...............................22		7.1 Refinements of this version................................23
	7.2 Content for next (-01) version............................23		7.2 Content for next (-01) version.............................23
	7.3 Content for future (-0x) versions.........................23		7.3 Content for future (-0x) versions..........................24
	NSLP for Quality-of-Service signaling September 2003		NSLP for Quality-of-Service signaling October 2003
	8. Security Considerations.......................................26		8. Security Considerations.......................................26
	9. Change History................................................26		9. Change History................................................26
	10. Appendix A: A strawman QSpec template........................26		10. Appendix A: A strawman QSpec template........................26
	References.......................................................27		References.......................................................27
	Acknowledgments..................................................29		Acknowledgments..................................................30
	Contributors.....................................................29		Contributors.....................................................30
	Contact information..............................................29		Contact information..............................................30
	Full Copyright Statement.........................................29		Full Copyright Statement.........................................30
	1. Introduction		1. Introduction
	1.1 Scope and background		1.1 Scope and background
	This document defines a Quality of Service (QoS) NSIS Signaling Layer		This document defines a Quality of Service (QoS) NSIS Signaling Layer
	Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This		Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This
	protocol establishes and maintains state at nodes along the path of a		protocol establishes and maintains state at nodes along the path of a
	data flow for the purpose of providing some forwarding resources for		data flow for the purpose of providing some forwarding resources for
	that flow. It is intended to satisfy the QoS-related requirements of		that flow. It is intended to satisfy the QoS-related requirements of
	[2]. This QoS-NSLP is part of a larger suite of signaling protocols,		[2]. This QoS-NSLP is part of a larger suite of signaling protocols,
	whose structure is outlined in [3]; this defines a common NSIS		whose structure is outlined in [3]; this defines a common NSIS
	Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many		Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many
	aspects of signaling message delivery.		aspects of signaling message delivery.
	The design of QoS-NSLP is conceptually similar to RSVP [4], and uses		The design of QoS-NSLP is conceptually similar to RSVP [4], and uses
	soft-state peer-to-peer refresh messages as the primary state		soft-state peer-to-peer refresh messages as the primary state
	management mechanism. Although there is no backwards compatibility at		management mechanism. Although there is no backwards compatibility at
	the level of protocol messages, interworking with RSVP at a signaling		the level of protocol messages, interworking with RSVP at a signaling
	application gateway would be possible in some circumstances. QoS-NSLP		application gateway would be possible in some circumstances. QoS-NSLP
	extends the set of reservation mechanisms to meet the requirements of		extends the set of reservation mechanisms to meet the requirements of
	[2], in particular support of sender or receiver-initiated		[2], in particular support of sender or receiver-initiated
	reservations, as well as a type of bi-directional reservation and		reservations, as well as a type of bi-directional reservation and
	support of reservations between arbitrary nodes, e.g. edge-to-edge,		support of reservations between arbitrary nodes, e.g. edge-to-edge,
	end-to-access, etc. On the other hand, there is no support for IP		end-to-access, etc. On the other hand, there is no support for IP
	multicast.		multicast.
	QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular		QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular
	QoS provisioning method or QoS architecture; this is similar to (but		QoS provisioning method or QoS architecture; this is similar to (but
	stronger than) the decoupling between RSVP and the IntServ		stronger than) the decoupling between RSVP and the IntServ
	architecture [5]. It should be able to carry information for various		architecture [5]. It should be able to carry information for various
	QoS models; the specification of Integrated Services for use with		QoS models; the specification of Integrated Services for use with
	RSVP given in [6] could form the basis of one QoS model.		RSVP given in [6] could form the basis of one QoS model.
	1.2 Model of operation		1.2 Model of operation
	NSLP for Quality-of-Service signaling September 2003		NSLP for Quality-of-Service signaling October 2003
	This section presents a logical model for the operation of the QoS-		This section presents a logical model for the operation of the QoS-
	NSLP and associated provisioning mechanisms within a single node. It		NSLP and associated provisioning mechanisms within a single node. It
	is adapted from the discussion in section 1 of [4]. The model is		is adapted from the discussion in section 1 of [4]. The model is
	shown in Figure 1.		shown in Figure 1.
	+---------------+		+---------------+
	| Local |		| Local |
	|Applications or|		|Applications or|
	|Management (e.g|		|Management (e.g|
	|for aggregates)|		|for aggregates)|
	+---------------+		+---------------+
	^		^
	^		^
	V		V
	V		V
	+----------+ +----------+ +---------+		+----------+ +----------+ +---------+
	| QoS-NSLP | | Resource | | Policy |		| QoS-NSLP | | Resource | | Policy |
	|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |		|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
	+----------+ +----------+ +---------+		+----------+ +----------+ +---------+
	. ^ | * ^		. ^ | * ^
	| V . * ^		| V . * ^
	+----------+ * ^		+----------+ * ^
	| NTLP | * ^		| NTLP | * ^
	|Processing| * V		|Processing| * V
	+----------+ * V		+----------+ * V
	| | * V		| | * V
	++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++		++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	. . * V		. . * V
	| | * .............................		| | * .............................
	. . * . Traffic Control .		. . * . Traffic Control .
	| | * . +---------+.		| | * . +---------+.
	. . * . |Admission|.		. . * . |Admission|.
	| | * . | Control |.		| | * . | Control |.
	+----------+ +------------+ . +---------+.		+----------+ +------------+ . +---------+.
	<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->		<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
	| Packet | | Interface | .+----------+ +---------+.		| Packet | | Interface | .+----------+ +---------+.
	===>|Processing|====| Selection |===.| Packet |====| Packet |.==>		===>|Processing|====| Selection |===.| Packet |====| Packet |.==>
	| | |(Forwarding)| .|Classifier| Scheduler|.		| | |(Forwarding)| .|Classifier| Scheduler|.
	+----------+ +------------+ .+----------+ +---------+.		+----------+ +------------+ .+----------+ +---------+.
	.............................		.............................
	<.-.-> = signaling flow		<.-.-> = signaling flow
	=====> = data flow (sender -->receiver)		=====> = data flow (sender -->receiver)
	<<<>>> = control and configuration operations		<<<>>> = control and configuration operations
	****** = routing table manipulation		****** = routing table manipulation
	Figure 1: QoS-NSLP in a Node		Figure 1: QoS-NSLP in a Node
	NSLP for Quality-of-Service signaling September 2003		This diagram shows an example implementation scenario where QoS
			conditioning is performed on the output interface. However, this does
			NSLP for Quality-of-Service signaling October 2003
	From the perspective of a single node, the request for QoS may result		not limit the possible implementations. For example, in some cases
	from a local application request, or from processing an incoming QoS-		traffic conditioning may be performed on the incoming interface, or
	NSLP message.		it may be split over the input and output interfaces.
	- The 'local application case' includes not only user		From the perspective of a single node, the request for QoS may result
	applications (e.g. multimedia applications) but also network		from a local application request, or from processing an incoming QoS-
	management (e.g. initiating a tunnel to handle an aggregate,		NSLP message.
	or interworking with some other reservation protocol - such as
	RSVP). In this sense, the model does not distinguish between
	hosts and routers.
	- The 'incoming message' case requires NSIS messages to be		- The 'local application case' includes not only user
	captured during input packet processing and handled by the		applications (e.g. multimedia applications) but also network
	NTLP. Only messages related to QoS are passed to the QoS-NSLP.		management (e.g. initiating a tunnel to handle an aggregate,
	The NTLP may also generate triggers to the QoS-NSLP (e.g.		or interworking with some other reservation protocol - such as
	indications that a route change has occurred).		RSVP). In this sense, the model does not distinguish between
			hosts and routers.
	The QoS request is handled by a local 'resource management' function,		- The 'incoming message' case requires NSIS messages to be
	which coordinates the activities required to grant and configure the		captured during input packet processing and handled by the
	resource.		NTLP. Only messages related to QoS are passed to the QoS-NSLP.
			The NTLP may also generate triggers to the QoS-NSLP (e.g.
			indications that a route change has occurred).
	- The grant processing involves two local decision modules,		The QoS request is handled by a local 'resource management' function,
	'policy control' and 'admission control'. Policy control		which coordinates the activities required to grant and configure the
	determines whether the user has administrative permission to		resource.
	make the reservation. Admission control determines whether the
	node has sufficient available resources to supply the
	requested QoS.
	- If both checks succeed, parameters are set in the packet		- The grant processing involves two local decision modules,
	classifier and in the link layer interface (e.g., in the		'policy control' and 'admission control'. Policy control
	packet scheduler) to obtain the desired QoS. Error		determines whether the user has administrative permission to
	notifications are passed back to the request originator. The		make the reservation. Admission control determines whether the
	resource management function may also manipulate the		node has sufficient available resources to supply the
	forwarding tables at this stage, to select (or at least pin) a		requested QoS.
	route; this must be done before interface-dependent actions
	are carried out (including forwarding outgoing messages over
	any new route), and is in any case invisible to the operation
	of the protocol.
	Policy control is expected to make use of a AAA service external to		- If both checks succeed, parameters are set in the packet
	the node itself. Some discussion can be found in [7] and [8]. More		classifier and in the link layer interface (e.g., in the
	generally, the processing of policy and resource management functions		packet scheduler) to obtain the desired QoS. Error
	may be outsourced to an external node leaving only 'stubs' co-located		notifications are passed back to the request originator. The
	with the NSLP; this is not visible to the protocol operation,		resource management function may also manipulate the
	although it may have some influence on the detailed design of		forwarding tables at this stage, to select (or at least pin) a
	protocol messages to allow the stub to be minimally complex.		route; this must be done before interface-dependent actions
			are carried out (including forwarding outgoing messages over
			any new route), and is in any case invisible to the operation
			of the protocol.
	NSLP for Quality-of-Service signaling September 2003		Policy control is expected to make use of a AAA service external to
			the node itself. Some discussion can be found in [7] and [8]. More
			generally, the processing of policy and resource management functions
			may be outsourced to an external node leaving only 'stubs' co-located
			with the NSLP; this is not visible to the protocol operation,
			NSLP for Quality-of-Service signaling October 2003
	The group of user plane functions, which implement QoS for a flow		although it may have some influence on the detailed design of
	(admission control, packet classification, and scheduling) is		protocol messages to allow the stub to be minimally complex.
	sometimes known as 'traffic control'.
	Admission control, packet scheduling, and any part of policy control		The group of user plane functions, which implement QoS for a flow
	beyond simple authentication have to be implemented using specific		(admission control, packet classification, and scheduling) is
	definitions for types and levels of QoS; we refer to this as a QoS		sometimes known as 'traffic control'.
	model. Our assumption is that the QoS-NSLP is independent of the QoS
	model, that is, QoS parameters (e.g. IntServ service elements) are
	interpreted only by the resource management and associated functions,
	and are opaque to the QoS-NSLP itself. QoS Models are discussed
	further in section 2.2.
	The final stage of processing for a resource request is to indicate		Admission control, packet scheduling, and any part of policy control
	to the QoS-NSLP protocol processing that the required resources have		beyond simple authentication have to be implemented using specific
	been configured. The QoS-NSLP may generate an acknowledgement message		definitions for types and levels of QoS; we refer to this as a QoS
	in one direction, and may propagate the resource request forwards in		model. Our assumption is that the QoS-NSLP is independent of the QoS
	the other. Message routing is (by default) carried out by the NTLP		model, that is, QoS parameters (e.g. IntServ service elements) are
	module. Note that while Figure 1 shows a unidirectional data flow,		interpreted only by the resource management and associated functions,
	the signaling messages can pass in both directions through the node,		and are opaque to the QoS-NSLP itself. QoS Models are discussed
	depending on the particular message and orientation of the		further in section 2.2.
	reservation.
	1.3 Terminology		The final stage of processing for a resource request is to indicate
			to the QoS-NSLP protocol processing that the required resources have
			been configured. The QoS-NSLP may generate an acknowledgement message
			in one direction, and may propagate the resource request forwards in
			the other. Message routing is (by default) carried out by the NTLP
			module. Note that while Figure 1 shows a unidirectional data flow,
			the signaling messages can pass in both directions through the node,
			depending on the particular message and orientation of the
			reservation.
	The terminology defined in [3] applies to this draft. In addition,		1.3 Terminology
	the following terms are used:
	- edge QNE - a QNE that is located at the boundary of an		The terminology defined in [3] applies to this draft. In addition,
	administrative domain, e.g., Diffserv.		the following terms are used:
	- egress QNE - an edge QNE that handles the traffic as it leaves		- edge QNE - a QNE that is located at the boundary of an
	the domain.		administrative domain, e.g., Diffserv.
	- ingress QNE - an edge QNE that handles the traffic as it		- egress QNE - an edge QNE that handles the traffic as it leaves
	enters the domain.		the domain.
	- interior QNE - a QNE that is part of an administrative domain,		- ingress QNE - an edge QNE that handles the traffic as it
	e.g., Diffserv, and is not an edge QNE.		enters the domain.
	- QNE - an NSIS Entity (NE), which supports the QoS-NSLP.		- interior QNE - a QNE that is part of an administrative domain,
			e.g., Diffserv, and is not an edge QNE.
	- QNI - the first node in the sequence of QNEs that issues a		- QNE - an NSIS Entity (NE), which supports the QoS-NSLP.
	reservation request.
	- QNR - the last node in the sequence of QNEs that receives a		- QNI - the first node in the sequence of QNEs that issues a
	reservation request.		reservation request.
	NSLP for Quality-of-Service signaling September 2003		NSLP for Quality-of-Service signaling October 2003
	- QoS-NSLP stateful operation - mode of operation where per-flow		- QNR - the last node in the sequence of QNEs that receives a
	reservation states are created, maintained and used.		reservation request.
	- QoS-NSLP reduced-state operation - mode of operation where		- QoS-NSLP stateful operation - mode of operation where per-flow
	reservation states with a coarser granularity (e.g. per-class)		reservation states are created, maintained and used.
	are created, maintained and used.
	- QoS-NSLP stateless operation - mode of operation where		- QoS-NSLP reduced-state operation - mode of operation where
	reservation state is not needed and not created.		reservation states with a coarser granularity (e.g. per-class)
			are created, maintained and used.
	- reduced state QNE - a QNE that supports the QoS NSLP reduced		- QoS-NSLP stateless operation - mode of operation where
	state operation.		reservation state is not needed and not created.
	- Source or message source - QoS NSLP messages are sent peer-to-		- reduced state QNE - a QNE that supports the QoS NSLP reduced
	peer. This means that a QNE considers its adjacent stateful		state operation.
	upstream or downstream peer to be the source of a QoS NSLP
	message. I.e. the source of a QoS NSLP message is not
	necessarily the QNI.
	- Stateful QNE - a QNE that supports the QoS NSLP stateful		- Source or message source - QoS NSLP messages are sent peer-to-
	operation.		peer. This means that a QNE considers its adjacent stateful
			upstream or downstream peer to be the source of a QoS NSLP
			message. I.e. the source of a QoS NSLP message is not
			necessarily the QNI.
	- Stateless QNE - a QNE that supports the QoS NSLP stateless		- Stateful QNE - a QNE that supports the QoS NSLP stateful
	operation.		operation.
	2. Protocol design principles		- Stateless QNE - a QNE that supports the QoS NSLP stateless
			operation.
	2.1 Basic protocol structure		2. Protocol design principles
	Messages are normally passed from the NSLP to the NTLP via an API,		2.1 Basic protocol structure
	which also specifies the signaling application (as QoS-NSLP), the
	flow/session identifier, and an indication of the intended direction
	- towards data sender or receiver. On reception, the NTLP provides
	the same information to the QoS-NSLP.
	The protocol specifies four message types (RESERVE, QUERY, RESPONSE		Messages are normally passed from the NSLP to the NTLP via an API,
	and NOTIFY) and two objects (QSpec and Policy object).		which also specifies the signaling application (as QoS-NSLP), the
			flow/session identifier, and an indication of the intended direction
			- towards data sender or receiver. On reception, the NTLP provides
			the same information to the QoS-NSLP.
	- Each protocol message includes header information that		The protocol specifies four message types (RESERVE, QUERY, RESPONSE
	identifies the message type and determines which objects it		and NOTIFY) and two objects (QSpec and Policy object).
	may carry.
	- A protocol message also contains Control Information (CI);		- Each protocol message includes header information that
	this is a group of objects that qualify and/or restrict the		identifies the message type and determines which objects it
	action that a QNE may perform on the QoS message. Control		may carry.
	NSLP for Quality-of-Service signaling September 2003
	Information is always associated to a QSpec, i.e. CI and QSpec		NSLP for Quality-of-Service signaling October 2003
	always come in pairs. This is important when we have locally
	valid objects e.g. for reduced state operation, because both a
	CI and a QSpec will be added.
	- QSpec object: The QoS parameters defined by the QoS model are		- A protocol message also contains Control Information (CI);
	carried in a QSpec object. It describes the QoS that is being		this is a group of objects that qualify and/or restrict the
	reserved.		action that a QNE may perform on the QoS message. Control
			Information is always associated to a QSpec, i.e. CI and QSpec
			always come in pairs. This is important when we have locally
			valid objects e.g. for reduced state operation, because both a
			CI and a QSpec will be added.
	- Policy object: The Policy object authenticates and authorizes		- QSpec object: The QoS parameters defined by the QoS model are
	the requester of the QoS reservation.		carried in a QSpec object. It describes the QoS that is being
			reserved.
	This memo intends to define message types and control information for		- Policy object: The Policy object authenticates and authorizes
	the QoS-NSLP (generic to all QoS models). It also introduces the QoS		the requester of the QoS reservation.
	model (section 2.2) and Policy object (section 2.3). However, a
	detailed description of these objects will need to be provided in
	separate documents.
	2.2 QoS model		This memo intends to define message types and control information for
			the QoS-NSLP (generic to all QoS models). It also introduces the QoS
			model (section 2.2) and Policy object (section 2.3). However, a
			detailed description of these objects will need to be provided in
			separate documents.
	A QoS model is a defined mechanism for achieving QoS as a whole. The		2.2 QoS model
	specification of a QoS model includes a description of its QoS
	parameter information, as well as how that information should be
	treated or interpreted in the network. In that sense, the QoS model
	goes beyond the QoS-NSLP protocol level in that it could also
	describe underlying assumptions, conditions and/or specific
	provisioning mechanisms appropriate for it.
	A QoS model provides a specific set of parameters to be carried in		A QoS model is a defined mechanism for achieving QoS as a whole. The
	the QSpec, or restricts the values these parameters can take.		specification of a QoS model includes a description of its QoS
	Integrated Services [5], Differentiated Services[9] and RMD [11] are		parameter information, as well as how that information should be
	all examples of QoS models. There is no restriction on the number of		treated or interpreted in the network. In that sense, the QoS model
	QoS models. QoS models may be local, meaning that they are private to		goes beyond the QoS-NSLP protocol level in that it could also
	one network, implementation or vendor specific or global, meaning		describe underlying assumptions, conditions and/or specific
	that they must be implementable by different networks and vendors.		provisioning mechanisms appropriate for it.
	The QSpec contains a set of parameters and values describing the		A QoS model provides a specific set of parameters to be carried in
	requested resources. It is opaque to the QoS-NSLP and similar in		the QSpec, or restricts the values these parameters can take.
	purpose to the TSpec, RSpec and AdSpec specified in [4,6]. At each		Integrated Services [5], Differentiated Services[9] and RMD [11] are
	QNE, its content is interpreted by the resource management function		all examples of QoS models. There is no restriction on the number of
	for the purposes of policy control and traffic control (including		QoS models. QoS models may be local, meaning that they are private to
	admission control and configuration of the packet classifier and		one network, implementation or vendor specific or global, meaning
	scheduler).		that they must be implementable by different networks and vendors.
	Different QoS models may share a common set of QoS parameters.		The QSpec contains a set of parameters and values describing the
	Standardizing a QSpec template would allow for a consistent		requested resources. It is opaque to the QoS-NSLP and similar in
	specification of common QoS parameters in different QoS models. It		purpose to the TSpec, RSpec and AdSpec specified in [4,6]. At each
	NSLP for Quality-of-Service signaling September 2003		QNE, its content is interpreted by the resource management function
			for the purposes of policy control and traffic control (including
			admission control and configuration of the packet classifier and
			scheduler).
	would simplify the introduction of new QoS models as well as greatly		NSLP for Quality-of-Service signaling October 2003
	increasing interoperability. Other examples of QoS description for
	which a template was standardized are e.g. the MEF Ethernet Service
	definition [10]. The QSpec template is envisaged to be useful for
	specifying a wide range of QoS descriptions. It would, for instance,
	need to support both qualitative and quantitative QoS specifications
	in order to provide for terminals that are not willing or capable to
	quantitatively describe the traffic behavior they require. A strawman
	QSpec template is described in Appendix A. In addition to
	standardizing a QSpec template, individual QoS models could be
	standardized, but we would expect them to have local significance
	only.
	2.3 Authentication and authorization		Different QoS models may share a common set of QoS parameters.
			Standardizing a QSpec template would allow for a consistent
			specification of common QoS parameters in different QoS models. It
			would simplify the introduction of new QoS models as well as greatly
			increasing interoperability. Other examples of QoS description for
			which a template was standardized are e.g. the MEF Ethernet Service
			definition [10]. The QSpec template is envisaged to be useful for
			specifying a wide range of QoS descriptions. It would, for instance,
			need to support both qualitative and quantitative QoS specifications
			in order to provide for terminals that are not willing or capable to
			quantitatively describe the traffic behavior they require. A strawman
			QSpec template is described in Appendix A. In addition to
			standardizing a QSpec template, individual QoS models could be
			standardized, but we would expect them to have local significance
			only.
	Future versions of this document will contain a discussion on the		2.3 Authentication and authorization
	Policy object, based on [7,8].
	2.4 Control Information		Future versions of this document will contain a discussion on the
			Policy object, based on [7,8].
	Any QoS-NSLP message may contain a set of objects for conveying		2.4 Control Information
	information about how these messages should be handled. This set of
	objects is collectively known as Control Information (CI).
	Control Information can have a local scope (Local Control Information		Any QoS-NSLP message may contain a set of objects for conveying
	or LCI) or global scope.		information about how these messages should be handled. This set of
			objects is collectively known as Control Information (CI).
	The ability of a QNE to explicitly request a RESPONSE to its messages		Control Information can have a local scope (Local Control Information
	(section 2.4.1) and the ability to limit the scope of a message are		or LCI) or global scope.
	both examples of Control Information (section 2.4.2). Future versions
	of the draft may include more examples of Control
	Information objects.
	2.4.1 ResponseRequest		The ability of a QNE to explicitly request a RESPONSE to its messages
			(section 2.4.1) and the ability to limit the scope of a message are
			both examples of Control Information (section 2.4.2). Future versions
			of the draft may include more examples of Control
			Information objects.
	Some QNEs may require explicit responses to messages they send. A		2.4.1ResponseRequest
	QUERY message (section 3.2), for instance, will always cause a
	RESPONSE message (section 3.3) to be sent. The QNE that generates a
	RESERVE message (section 3.1) may explicitly request that it triggers
	a RESPONSE.
	If a RESPONSE message is required or desired, the QNE inserts a		Some QNEs may require explicit responses to messages they send. A
	ResponseRequest object in the message. The exact format of this		QUERY message (section 3.2), for instance, will always cause a
	object will be determined in a future version of this specification.		RESPONSE message (section 3.3) to be sent. The QNE that generates a
			RESERVE message (section 3.1) may explicitly request that it triggers
			a RESPONSE.
	NSLP for Quality-of-Service signaling September 2003		NSLP for Quality-of-Service signaling October 2003
	In order to be able to match a response back to the corresponding		If a RESPONSE message is required or desired, the QNE inserts a
	request , the ResponseRequest object contains Response Identification		ResponseRequest object in the message. The exact format of this
	Information (RII). The RII is inserted by the QNE that requests the		object will be determined in a future version of this specification.
	response and is copied into the corresponding RESPONSE message. QNEs
	that receive a RESPONSE containing their own RII should not forward
	the message further.
	The ResponseRequest object also contains a flag to indicate whether		In order to be able to match a response back to the corresponding
	it is requesting a response from the next node (a 'local' response),		request , the ResponseRequest object contains Response Identification
	or a response from the QNR. More general ways of specifying scoping		Information (RII). The RII is inserted by the QNE that requests the
	information will be investigated in future versions of this document.		response and is copied into the corresponding RESPONSE message. QNEs
			that receive a RESPONSE containing their own RII should not forward
			the message further.
	Note that if an intermediate QNE desires a RESPONSE as well, it		The ResponseRequest object also contains a flag to indicate whether
	should not change the RII or add another ResponseRequest since the		it is requesting a response from the next node (a 'local' response),
	RESPONSE will pass through it anyway.		or a response from the QNR. More general ways of specifying scoping
			information will be investigated in future versions of this document.
	2.4.2 Message and object scoping		Note that if an intermediate QNE desires a RESPONSE as well, it
			should not change the RII or add another ResponseRequest since the
			RESPONSE will pass through it anyway.
	QoS-NSLP supports locally defined QoS model specifications by means		2.4.2Message and object scoping
	of local QSpecs and local Control Information. Messages containing
	such local information need to be scoped, i.e. it should be possible
	to restrict the forwarding of such a message to the domain in which
	it is applicable. It may also be needed to scope individual objects
	in the message.
	One example of message scoping uses the RII to limit the forwarding		QoS-NSLP supports locally defined QoS model specifications by means
	of a RESPONSE to the QNE that requested it. Another example might be		of local QSpecs and local Control Information. Messages containing
	controlling the scope of a tearing RESERVE.		such local information need to be scoped, i.e. it should be possible
			to restrict the forwarding of such a message to the domain in which
			it is applicable. It may also be needed to scope individual objects
			in the message.
	The two scopes of "single QoS-NSLP hop" and "whole path" appear to be		One example of message scoping uses the RII to limit the forwarding
	useful concepts. In case no scoping information is specified, the		of a RESPONSE to the QNE that requested it. Another example might be
	default case of "whole path" must be assumed. It is still to be		controlling the scope of a tearing RESERVE.
	determined what the best way(s) of specifying more flexible scoping
	information, such as per-domain are.
	2.5 Nested protocol operation		The two scopes of "single QoS-NSLP hop" and "whole path" appear to be
			useful concepts. In case no scoping information is specified, the
			default case of "whole path" must be assumed. It is still to be
			determined what the best way(s) of specifying more flexible scoping
			information, such as per-domain are.
	For various reasons an operator may want to use a different type of		2.5 Nested protocol operation
	QoS specification (i.e. a different QoS model) within its network.
	This may be done, for example, in order for QNEs to be able to store
	less reservation state. In order to allow some local selection of
	which QoS Model to use without destroying all end-to-end aspects of
	the signaling, QoS-NSLP allows a nesting of QoS Models by 'stacking'
	more than one pair of Control Information / QSpec object within a
	message.
	NSLP for Quality-of-Service signaling September 2003		For various reasons an operator may want to use a different type of
			QoS specification (i.e. a different QoS model) within its network.
			This may be done, for example, in order for QNEs to be able to store
			less reservation state. In order to allow some local selection of
			which QoS Model to use without destroying all end-to-end aspects of
			NSLP for Quality-of-Service signaling October 2003
	The details of this operation will be covered in future versions of		the signaling, QoS-NSLP allows a nesting of QoS Models by 'stacking'
	this draft. This nested operation would allow localized QSpec objects		more than one pair of Control Information / QSpec object within a
	and control information to be used along parts of the path. It also		message.
	has dependencies on the scoping facilities provided by the protocol.
	2.6 Protocol extensibility		The details of this operation will be covered in future versions of
			this draft. This nested operation would allow localized QSpec objects
			and control information to be used along parts of the path. It also
			has dependencies on the scoping facilities provided by the protocol.
	QoS-NSLP is designed in modular way making it possible to support		2.6 Protocol extensibility
	different QoS models and other future extensions of the protocol.
	Extensions can be provided by specifying new QoS models and their
	usage or defining new QoS-NSLP objects (similar to the current QSpec
	and Policy object) and their usage.
	In QoS-NSLP the basic operation mechanism of the protocol is clearly		QoS-NSLP is designed in modular way making it possible to support
	separated from the control and traffic information being transported.		different QoS models and other future extensions of the protocol.
	This logical separation makes it possible to develop a variety of new		Extensions can be provided by specifying new QoS models and their
	QoS models within one protocol frame. Each of the QoS-NSLP message		usage or defining new QoS-NSLP objects (similar to the current QSpec
	types can carry, for each supported QoS Model, QoS descriptions by		and Policy object) and their usage.
	using object templates. This memo discusses a template for the QoS
	specification (QSpec). A future version will also cover the Policy
	object.
	A new QoS model is specified by defining the internal content of the		In QoS-NSLP the basic operation mechanism of the protocol is clearly
	template objects and by defining how QoS provisioning is done in		separated from the control and traffic information being transported.
	different nodes. Another important aspect of defining a new QoS model		This logical separation makes it possible to develop a variety of new
	is the specification of the associated CI used in these templates,		QoS models within one protocol frame. Each of the QoS-NSLP message
	which allow particular setting in different nodes.		types can carry, for each supported QoS Model, QoS descriptions by
			using object templates. This memo discusses a template for the QoS
			specification (QSpec). A future version will also cover the Policy
			object.
	A QoS model may have internal structure into different components,		A new QoS model is specified by defining the internal content of the
	some of which may have application limited to particular nodes while		template objects and by defining how QoS provisioning is done in
	being opaque to others.		different nodes. Another important aspect of defining a new QoS model
			is the specification of the associated CI used in these templates,
			which allow particular setting in different nodes.
	2.7 Implementation flexibility for scalability		A QoS model may have internal structure into different components,
			some of which may have application limited to particular nodes while
			being opaque to others.
	The QoS-NSLP protocol supports QoS architectures in which some QNEs		2.7 Implementation flexibility for scalability
	may not be able or willing to store per-session state. A stateless
	operation is conceivable, in which QNEs interior to a domain store
	neither NSLP nor NTLP state. They rather e.g. just send and receive
	messages to provide information on currently available resources, and
	react upon overload detection. Also reduced-state operation is
	conceivable, in which QNEs do not store full per session (per-flow or
	per-aggregate) state in both NSLP and NTLP, but rather, e.g. one per-
	class state in NSLP and no state in NTLP. Examples of how QoS can be
	achieved with stateless and reduced-state operation are described in
	RMD [11].
	NSLP for Quality-of-Service signaling September 2003		The QoS-NSLP protocol supports QoS architectures in which some QNEs
			may not be able or willing to store per-session state. A stateless
			operation is conceivable, in which QNEs interior to a domain store
			neither NSLP nor NTLP state. They rather e.g. just send and receive
			messages to provide information on currently available resources, and
			react upon overload detection. Also reduced-state operation is
			conceivable, in which QNEs do not store full per session (per-flow or
			per-aggregate) state in both NSLP and NTLP, but rather, e.g. one per-
			NSLP for Quality-of-Service signaling October 2003
	Stateless and reduced state operation is only applicable under		class state in NSLP and no state in NTLP. Examples of how QoS can be
	certain circumstances. Stateless or reduced state QNEs are not able		achieved with stateless and reduced-state operation are described in
	to perform message bundling, message fragmentation and reassembly (at		RMD [11].
	the NSLP) or congestion control. They are not able to establish and
	maintain security associations with their neighbors, which means they
	can only be applied in a trusted environment. For these reasons, a
	typical application of stateless or reduced state QNEs is for
	signaling within a single domain where the edges of the domain are
	stateful QNEs.
	Stateless and reduced state QoS-NSLP operation makes the most sense		Stateless and reduced state operation is only applicable under
	when (some nodes of) the underlying NTLP is (are) able to operate in		certain circumstances. Stateless or reduced state QNEs are not able
	a stateless way as well. Such nodes should not worry about keeping		to perform message bundling, message fragmentation and reassembly (at
	reverse path state, message fragmentation and reassembly (at the		the NSLP) or congestion control. They are not able to establish and
	NTLP), congestion control or security associations. A stateless or		maintain security associations with their neighbors, which means they
	reduced state QNE will be able to inform the underlying NTLP of this		can only be applied in a trusted environment. For these reasons, a
	situation. We rely on the NTLP design to allow for a mode of		typical application of stateless or reduced state QNEs is for
	operation that can take advantage of this information (section 6.1).		signaling within a single domain where the edges of the domain are
			stateful QNEs.
	3. Basic message types		Stateless and reduced state QoS-NSLP operation makes the most sense
			when (some nodes of) the underlying NTLP is (are) able to operate in
			a stateless way as well. Such nodes should not worry about keeping
			reverse path state, message fragmentation and reassembly (at the
			NTLP), congestion control or security associations. A stateless or
			reduced state QNE will be able to inform the underlying NTLP of this
			situation. We rely on the NTLP design to allow for a mode of
			operation that can take advantage of this information (section 6.1).
	The QoS-NSLP contains four message types: RESERVE, QUERY, RESPONSE		3. Basic message types
	and NOTIFY.
	These messages have different conceptual properties; the		The QoS-NSLP contains four message types: RESERVE, QUERY, RESPONSE
	fundamental properties of the message determine how it should be		and NOTIFY.
	analyzed from the perspective of re-ordering, loss, end-to-end
	reliability and so on. It is important for applications to know
	whether NSLP messages can be repeated, discarded or merged and so on
	(e.g. for edge mobility support, rerouting, etc). Indeed, the
	ordering of messages that don't manipulate state at QNEs matters
	little, whereas the way that messages that manipulate state are
	interleaved matters very much. Therefore NSLP is designed such that
	the message type identifies whether a message is manipulating state
	(in which case it is idempotent) or not (it is impotent).
	3.1 RESERVE		These messages have different conceptual properties; the
			fundamental properties of the message determine how it should be
			analyzed from the perspective of re-ordering, loss, end-to-end
			reliability and so on. It is important for applications to know
			whether NSLP messages can be repeated, discarded or merged and so on
			(e.g. for edge mobility support, rerouting, etc). Indeed, the
			ordering of messages that don't manipulate state at QNEs matters
			little, whereas the way that messages that manipulate state are
			interleaved matters very much. Therefore NSLP is designed such that
			the message type identifies whether a message is manipulating state
			(in which case it is idempotent) or not (it is impotent).
	The RESERVE message is used to manipulate QoS reservation state in		3.1 RESERVE
	QNEs. A RESERVE message may create, refresh, modify or remove such
	state.
	The RESERVE message opaquely transports a QSpec object, describing		The RESERVE message is used to manipulate QoS reservation state in
	the desired service level and a Policy object, authorizing the		QNEs. A RESERVE message may create, refresh, modify or remove such
	requestor of the service. It also carries the lifetime of the		state.
	reservation (most likely in the Control Information part). Each node
	NSLP for Quality-of-Service signaling September 2003
	may insert a local QSpec object and or local Control Information		NSLP for Quality-of-Service signaling October 2003
	(LCI) provided it has a way of scoping this information (e.g. at the
	boundary of a domain).
	In some cases, a QNE needs to be able to distinguish between newly		The RESERVE message opaquely transports a QSpec object, describing
	created, modified state or refreshed state based on the RESERVE		the desired service level and a Policy object, authorizing the
	message alone (not in combination with state information obtained		requestor of the service. It also carries the lifetime of the
	from previous messages). Therefore, one or more additional flags that		reservation (most likely in the Control Information part). Each node
	provide this differentiation may be needed. Future versions of this		may insert a local QSpec object and or local Control Information
	draft will describe how such flag(s) will be provided and used.		(LCI) provided it has a way of scoping this information (e.g. at the
			boundary of a domain).
	In order to clearly distinguish between a RESERVE message that sets		In some cases, a QNE needs to be able to distinguish between newly
	the reserved resources to zero and a RESERVE message that tears down		created, modified state or refreshed state based on the RESERVE
	QoS-NSLP state completely, a tear bit should be foreseen. Note that		message alone (not in combination with state information obtained
	the potential initiation of (reverse path) state removal at the NTLP		from previous messages). Therefore, one or more additional flags that
	is a separate issue. This will be signaled over the API between NTLP		provide this differentiation may be needed. Future versions of this
	and QoS-NSLP.		draft will describe how such flag(s) will be provided and used.
	RESERVE messages are sent peer-to-peer. This means that a QNE		In order to clearly distinguish between a RESERVE message that sets
	considers its adjacent upstream or downstream peer to be the source		the reserved resources to zero and a RESERVE message that tears down
	of the RESERVE message. Note that two nodes that are adjacent at the		QoS-NSLP state completely, a tear bit should be foreseen. Note that
	QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS-		the potential initiation of (reverse path) state removal at the NTLP
	NSLP node may want to be able to detect changes in its QoS-NSLP		is a separate issue. This will be signaled over the API between NTLP
	peers, or send a message to an explicitly identified node, e.g. for		and QoS-NSLP.
	tearing down a reservation on an old path. This functionality can be
	provided by keeping track of a Source Identification Information
	(SII) object that is similar in nature to the RSVP_HOP object
	described in [4]. We assume such an SII (section 6.2) to be available
	as a service from the NTLP.
	The RESERVE message is idempotent; the resultant effect is the same		RESERVE messages are sent peer-to-peer. This means that a QNE
	whether a message is received once or many times. In addition, the		considers its adjacent upstream or downstream peer to be the source
	ordering of RESERVE messages matters - an old RESERVE message does		of the RESERVE message. Note that two nodes that are adjacent at the
	not replace a newer one. Both of these features are required for		QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS-
	protocol robustness - messages may be re-ordered on route (e.g.		NSLP node may want to be able to detect changes in its QoS-NSLP
	because of mobility, or at intermediate NTLP nodes) or spuriously		peers, or send a message to an explicitly identified node, e.g. for
	retransmitted.		tearing down a reservation on an old path. This functionality can be
			provided by keeping track of a Source Identification Information
			(SII) object that is similar in nature to the RSVP_HOP object
			described in [4]. We assume such an SII (section 6.2) to be available
			as a service from the NTLP.
	In order to tackle these issues, the RESERVE message contains a		The RESERVE message is idempotent; the resultant effect is the same
	Reservation Sequence Number (RSN). A RSN is an identifier that		whether a message is received once or many times. In addition, the
	indicates the order in which state modifying actions are performed by		ordering of RESERVE messages matters - an old RESERVE message does
	a QNE. The RSN has local significance only, i.e. between QNEs.		not replace a newer one. Both of these features are required for
	Attempting to make an identifier that was unique in the context of a		protocol robustness - messages may be re-ordered on route (e.g.
	session identifier but the same along the complete path would be very		because of mobility, or at intermediate NTLP nodes) or spuriously
	hard. Since RESERVEs can be sent by any node on the path that		retransmitted.
	maintains reservation state (e.g. for path repair) we would have the
	difficult task of attempting to keep the identifier synchronized
	along the whole path. The ordering only matters between a pair of
	NSLP for Quality-of-Service signaling September 2003
	nodes maintaining reservation state, i.e. stateful QNEs. This means		In order to tackle these issues, the RESERVE message contains a
	that we can instead make the Reservation Sequence Number unique just		Reservation Sequence Number (RSN). An RSN is an incrementing sequence
	between a pair of neighboring stateful QNEs. Note that an alternative		number that indicates the order in which state modifying actions are
	might be for the NTLP to guarantee in-order delivery between the NSLP		performed by a QNE. The RSN has local significance only, i.e. between
	peers.		QNEs. Attempting to make an identifier that was unique in the context
			of a session identifier but the same along the complete path would be
			NSLP for Quality-of-Service signaling October 2003
	The sender of a RESERVE message may want to receive some confirmation		very hard. Since RESERVEs can be sent by any node on the path that
	from a downstream node. For this purpose the RESERVE message may		maintains reservation state (e.g. for path repair) we would have the
	contain a ResponseRequest object (section 2.4.1).		difficult task of attempting to keep the identifier synchronized
			along the whole path. The ordering only matters between a pair of
			nodes maintaining reservation state, i.e. stateful QNEs. This means
			that we can instead make the Reservation Sequence Number unique just
			between a pair of neighboring stateful QNEs. Note that an alternative
			might be for the NTLP to guarantee in-order delivery between the NSLP
			peers.
	3.2 QUERY		A Flow Identifier groups together state items for a single flow. The
			RSN is one of these state items, and is used to identify reordering
			of messages and to allow the use of partial refresh messages. The
			state items for a number of flows can be linked together and
			identified as part of a single reservation using a Session
			Identifier. The identifiers play complementary roles in the
			management of QoS NSLP state.
	A QUERY message is used to request information about the data path		The sender of a RESERVE message may want to receive some confirmation
	without making a reservation. This functionality can be used to		from a downstream node. For this purpose the RESERVE message may
	'probe' the network for path characteristics or for support of		contain a ResponseRequest object (section 2.4.1).
	certain QoS models. The information obtained from a QUERY may be used
	in the admission control process of a QNE (e.g. in case of
	measurement-based admission control). Note that a QUERY does not
	change existing reservation state, nor does it cause state to be
	installed in nodes other than the one that generated the QUERY.
	A QUERY message contains a ResponseRequest object containing Response		3.2 QUERY
	Identification Information (RII) that allows matching back RESPONSE
	to the QUERY request. It is transported unchanged along the data path
	and may be used to scope the RESPONSE to a QUERY message (section
	3.3).
	The QUERY message can gather information along the data path in a		A QUERY message is used to request information about the data path
	number of objects. Some of these objects may be part of the QoS		without making a reservation. This functionality can be used to
	model. Others may be generic to the QoS-NSLP protocol.		'probe' the network for path characteristics or for support of
			certain QoS models. The information obtained from a QUERY may be used
			in the admission control process of a QNE (e.g. in case of
			measurement-based admission control). Note that a QUERY does not
			change existing reservation state, nor does it cause state to be
			installed in nodes other than the one that generated the QUERY.
	A QUERY message may be scoped. If scoping information is present,		A QUERY message contains a ResponseRequest object containing Response
	this means that the QUERY is not supposed to go down the entire path		Identification Information (RII) that allows matching back RESPONSE
	to the QNR but rather that is has a maximum number of QNE hops it can		to the QUERY request. It is transported unchanged along the data path
	travel. Else, the default case (whole path) is assumed. It is		and may be used to scope the RESPONSE to a QUERY message (section
	currently an open issue what the best way of message scoping is		3.3).
	(section 7.1)
	3.3 RESPONSE		The QUERY message can gather information along the data path in a
			number of objects. Some of these objects may be part of the QoS
			model. Others may be generic to the QoS-NSLP protocol.
	The REPONSE message is used to provide information about the result		A QUERY message may be scoped. If scoping information is present,
	of a previous QoS-NSLP message, e.g. confirmation, error or		this means that the QUERY is not supposed to go down the entire path
	information resulting from a query. The RESPONSE message is impotent,		to the QNR but rather that is has a maximum number of QNE hops it can
	it does not cause any state to be installed or modified.		travel. Else, the default case (whole path) is assumed. It is
			NSLP for Quality-of-Service signaling October 2003
	NSLP for Quality-of-Service signaling September 2003		currently an open issue what the best way of message scoping is
			(section 7.1)
	A QNE may want to receive a RESPONSE message to inform it that the		3.3 RESPONSE
	reservation has been successfully installed. The RESERVE message may
	contain a ResponseRequest object for this purpose. Such a
	ResponseRequest object can be used to request an explicit
	confirmation of the state manipulation signaled in the RESERVE
	message.
	The forwarding of the RESPONSE message along the path does not		The REPONSE message is used to provide information about the result
	necessarily imply the existence of NTLP reverse-path state at every		of a previous QoS-NSLP message, e.g. confirmation, error or
	node. For example, the NTLP may have a mechanism to pass a message		information resulting from a query. The RESPONSE message is impotent,
	directly from the egress to the ingress of a region of QNEs that do		it does not cause any state to be installed or modified.
	not store per-flow reverse-path state.
	If a QNE or the QNR is unable to provide the requested information or		A QNE may want to receive a RESPONSE message to inform it that the
	if the response is negative, the RESPONSE message may be used to		reservation has been successfully installed. The RESERVE message may
	carry an error message.		contain a ResponseRequest object for this purpose. Such a
			ResponseRequest object can be used to request an explicit
			confirmation of the state manipulation signaled in the RESERVE
			message.
	A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY		The forwarding of the RESPONSE message along the path does not
	message will always contain a ResponseRequest object. A RESERVE may		necessarily imply the existence of NTLP reverse-path state at every
	cause a RESPONSE to be sent if this is explicitly requested or when		node. For example, the NTLP may have a mechanism to pass a message
	an error occurs.		directly from the egress to the ingress of a region of QNEs that do
			not store per-flow reverse-path state.
	3.4 NOTIFY		If a QNE or the QNR is unable to provide the requested information or
			if the response is negative, the RESPONSE message may be used to
			carry an error message.
	NOTIFY messages are used to convey information to a QNE. NOTIFY		A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY
	messages are impotent (they do not cause a change in state directly).		message will always contain a ResponseRequest object. A RESERVE may
			cause a RESPONSE to be sent if this is explicitly requested or when
			an error occurs.
	NOTIFY messages differ from RESPONSEs in that they need not refer to		3.4 NOTIFY
	any particular state or previously received message. They are sent
	asynchronously. The NOTIFY message itself does not trigger or mandate
	any action in the receiving QNE.
	The information conveyed by a NOTIFY message is typically related to		NOTIFY messages are used to convey information to a QNE. NOTIFY
	error conditions. One example would be notification to an upstream		messages are impotent (they do not cause a change in state directly).
	peer about state being torn down.
	4. Basic outline of operation		NOTIFY messages differ from RESPONSEs in that they need not refer to
			any particular state or previously received message. They are sent
			asynchronously. The NOTIFY message itself does not trigger or mandate
			any action in the receiving QNE.
	4.1 Making a reservation		The information conveyed by a NOTIFY message is typically related to
			error conditions. One example would be notification to an upstream
			peer about state being torn down.
	To make a new reservation, the QNI builds a RESERVE message		NSLP for Quality-of-Service signaling October 2003
	containing a QSpec specifying the resources required and a Policy
	object containing user identification and authorization information.
	It initializes a Reservation Sequence Number (RSN) counter for the
	flow and provides the initial value in the RESERVE message. This
	NSLP for Quality-of-Service signaling September 2003
	message is passed to the NTLP, which delivers it to the next QNE. A		4. Basic outline of operation
	ResponseRequest object may be introduced if a confirmation of
	successful reservation is desired.
	At the next QNE the RESERVE message is examined. Policy control and		4.1 Making a reservation
	admission control decisions are made. The node performs appropriate
	actions based on the content of any QSpec object in the message. The
	QoS NSLP generates a new RESERVE message based on the one it
	received. This is passed to the NTLP, which forwards it to the next
	QNE.
	The same processing is performed at further QNEs on the path, up to		To make a new reservation, the QNI builds a RESERVE message
	the QNR.		containing a QSpec specifying the resources required and a Policy
			object containing user identification and authorization information.
			It initializes a Reservation Sequence Number (RSN) counter for the
			flow and provides the initial value in the RESERVE message. This
			message is passed to the NTLP, which delivers it to the next QNE. A
			ResponseRequest object may be introduced if a confirmation of
			successful reservation is desired.
	At the QNR, having determined that it is the last QNE (section 6.3)		At the next QNE the RESERVE message is examined. Policy control and
	on the path, the attempt to send a further RESERVE message is		admission control decisions are made. The node performs appropriate
	aborted. The NR may rely on information obtained from the NTLP to		actions based on the content of any QSpec object in the message. The
	determine that it is the last node (section 6.3).		QoS NSLP generates a new RESERVE message based on the one it
			received. This is passed to the NTLP, which forwards it to the next
			QNE.
	A QNE may want to store per-flow state for a number of reasons. It		The same processing is performed at further QNEs on the path, up to
	may be that per-flow reservations are required to provide better		the QNR.
	granularity of reserved resources. Some additional functions can also
	be provided by the NSLP by storing NSLP state.
	If the QNE wishes to be able to detect changes in the neighboring QNE		At the QNR, having determined that it is the last QNE (section 6.3)
	(i.e. that a future RESERVE message did not come from the same node		on the path, the attempt to send a further RESERVE message is
	as the one that sent this RESERVE), then it records the identity of		aborted. The NR may rely on information obtained from the NTLP to
	that node (e.g. SII). The SII on the outgoing message is defined by		determine that it is the last node (section 6.3).
	the NTLP.
	If the QNE also wants to detect re-ordered or duplicated RESERVE		A QNE may want to store per-flow state for a number of reasons. It
	messages then it must also store the Reservation Sequence Number.		may be that per-flow reservations are required to provide better
	When an NSLP node that maintains per-flow reservation state (and may		granularity of reserved resources. Some additional functions can also
	generate refreshes) generates a RESERVE message to forward on to the		be provided by the NSLP by storing NSLP state.
	next peer it must replace the Reservation Sequence Number in the
	message it received with one of its own. If the NSLP does not
	maintain any per-flow reservation state (and thus cannot generate new
	RESERVE messages (refreshes, tears, etc) on its own) then it can use
	the RSN from the RESERVE message it received, rather than maintaining
	its own sequence numbers. By managing the sequence numbers in this
	manner, the source of the RESERVE does not need to determine how the
	next NSLP node will process the message.
	Layering approaches (as outlined in section 2.5) can be used by an		If the QNE wishes to be able to detect changes in the neighboring QNE
	ingress QNE to translate end-to-end NSLP messages into a form which		(i.e. that a future RESERVE message did not come from the same node
	is particularly suited to the local network, where it is expected		as the one that sent this RESERVE), then it records the identity of
	that interior nodes will benefit from this. For example, where only		that node (e.g. SII). The SII on the outgoing message is defined by
	per-class state or no state is stored by nodes (as for stateless or		the NTLP.
	NSLP for Quality-of-Service signaling September 2003
	reduced-state operation in section 2.7). At the egress of the region,		If the QNE also wants to detect re-ordered or duplicated RESERVE
	this local QSpec can be removed.		messages then it must also store the Reservation Sequence Number.
			When an NSLP node that maintains per-flow reservation state (and may
			generate refreshes) generates a RESERVE message to forward on to the
			next peer it must replace the Reservation Sequence Number in the
			message it received with one of its own. If the NSLP does not
			maintain any per-flow reservation state (and thus cannot generate new
			NSLP for Quality-of-Service signaling October 2003
	4.2 Refreshing a reservation		RESERVE messages (refreshes, tears, etc) on its own) then it can use
			the RSN from the RESERVE message it received, rather than maintaining
			its own sequence numbers. By managing the sequence numbers in this
			manner, the source of the RESERVE does not need to determine how the
			next NSLP node will process the message.
	Since the NSIS protocol suite normally takes a soft-state approach to		Layering approaches (as outlined in section 2.5) can be used by an
	managing reservation state in QNEs, the state created by a RESERVE		ingress QNE to translate end-to-end NSLP messages into a form which
	message must be periodically refreshed. Reservation state is deleted		is particularly suited to the local network, where it is expected
	if no new RESERVE messages arrive before the expiration of the		that interior nodes will benefit from this. For example, where only
	reservation lifetime. The Reservation lifetime is indicated in the		per-class state or no state is stored by nodes (as for stateless or
	RESERVE message when the reservation is made. Maintaining the		reduced-state operation in section 2.7). At the egress of the region,
	reservation beyond this lifetime can be done by sending a RESERVE		this local QSpec can be removed.
	message with the same QSpec and Policy objects as the original
	message that created the reservation and by indicating that it is
	refreshing existing state. Note that a refreshing RESERVE should not
	increment the Reservation Sequence Number.
	At the expiration of a "refresh timeout" period, each QNE		4.2 Refreshing a reservation
	independently examines its state and sends a refreshing RESERVE
	message to the next QNE peer where it is absorbed. This peer-to-peer
	refreshing (as opposed to the QNI initiating a refresh which travels
	all the way to the QNR) allows QNEs to choose refresh intervals as
	appropriate for their environment. For example, it is conceivable
	that refreshing intervals in the backbone, where reservations are
	relatively stable, are much larger than in an access network. The
	"refresh timeout" is calculated within the QNE and is not part of the
	protocol; however, it must be chosen to be compatible with the
	reservation lifetime, and an assessment of the reliability of message
	delivery.
	The details of timer management and timer changes (slew handling and		Since the NSIS protocol suite normally takes a soft-state approach to
	so on) are left for future versions of this document.		managing reservation state in QNEs, the state created by a RESERVE
			message must be periodically refreshed. Reservation state is deleted
			if no new RESERVE messages arrive before the expiration of the
			reservation lifetime. The Reservation lifetime is indicated in the
			RESERVE message when the reservation is made. Maintaining the
			reservation beyond this lifetime can be done by sending a RESERVE
			message with the same QSpec and Policy objects as the original
			message that created the reservation and by indicating that it is
			refreshing existing state. Note that a refreshing RESERVE should not
			increment the Reservation Sequence Number.
	If a RESPONSE has been received to acknowledge that reservation state		At the expiration of a "refresh timeout" period, each QNE
	has been installed, then an abbreviated form of refreshing RESERVE		independently examines its state and sends a refreshing RESERVE
	message ('summary refresh') can be sent which references the		message to the next QNE peer where it is absorbed. This peer-to-peer
	reservation using the Reservation Sequence Number, rather than		refreshing (as opposed to the QNI initiating a refresh which travels
	including the full reservation specification. Note that this		all the way to the QNR) allows QNEs to choose refresh intervals as
	functionality requires an explicit acknowledgment of state		appropriate for their environment. For example, it is conceivable
	installation to ensure that the RSN reference will be understood. It		that refreshing intervals in the backbone, where reservations are
	is up to a QNE that receives a ResponseRequest to decide whether it		relatively stable, are much larger than in an access network. The
	wants to accept summary refreshes and provide this explicit		"refresh timeout" is calculated within the QNE and is not part of the
	acknowledgment. For example, reduced state QNEs that cannot support		protocol; however, it must be chosen to be compatible with the
	summary refreshes would not send this acknowledgement.		reservation lifetime, and an assessment of the reliability of message
			delivery.
	It is currently an open point which parts of the RESERVE message are		The details of timer management and timer changes (slew handling and
	reused by the summary refresh. A summary refresh containing only the		so on) are left for future versions of this document.
	NSLP for Quality-of-Service signaling September 2003
	RSN seems to be the minimal case of a broad spectrum of varying		If a RESPONSE has been received to acknowledge that reservation state
	amounts of data that we send in an update. Future versions of this		has been installed, then an abbreviated form of refreshing RESERVE
	document will attempt to identify some objects as 'needing refresh'.		message ('summary refresh') can be sent which references the
			NSLP for Quality-of-Service signaling October 2003
	4.3 Sending a response		reservation using the Reservation Sequence Number, rather than
			including the full reservation specification. Note that this
			functionality requires an explicit acknowledgment of state
			installation to ensure that the RSN reference will be understood. It
			is up to a QNE that receives a ResponseRequest to decide whether it
			wants to accept summary refreshes and provide this explicit
			acknowledgment. For example, reduced state QNEs that cannot support
			summary refreshes would not send this acknowledgement.
	A QNE sending a RESERVE message may also request a RESPONSE message		It is currently an open point which parts of the RESERVE message are
	to be sent back to it. To do this it includes a ResponseRequest		reused by the summary refresh. A summary refresh containing only the
	object with a RII object in it.		RSN seems to be the minimal case of a broad spectrum of varying
			amounts of data that we send in an update. Future versions of this
			document will attempt to identify some objects as 'needing refresh'.
	When a node processes a received RESERVE message it should examine it		When a QNE receives a partial refresh message it compares the RSN
	to see if it contains a local ResponseRequest object. If it does,		against that of the currently installed reservation. If it matches
	then a RESPONSE message is generated, and the contents of this object		then the state is refreshed. If the RSN in the message is less than
	are copied into it. The local ResponseRequest object is removed from		that of the currently installed state (i.e. it refers to 'old' state)
	the RESERVE message being sent out.		then the message is discarded (possibly the messages got reordered
			between the nodes). If the RSN in the message is greater than that of
			the currently installed state then an error MUST be signalled back.
			It means that the peer QNE believes that state is installed when it
			is not. If not informed it would continue to attempt to refresh the
			non-existent state. A partial refresh containing either an unknown
			session identifier or flow identifier MUST also be responded to with
			an error message (this is likely to occur following a rerouting
			event).
	At the QNR, the processing of local ResponseRequest objects is		4.3 Sending a response
	carried out normally (this may happen before this QNE has determined
	that it is the QNR). If the RESERVE message received by the QNR
	contained a ResponseRequest object, then a RESPONSE message is
	created with the contents of the ResponseRequest object copied into
	it.
	On receiving a RESPONSE message a QNE should check the contents of		A QNE sending a RESERVE message may also request a RESPONSE message
	the ResponseRequest object echoed back to see if it contains an		to be sent back to it. To do this it includes a ResponseRequest
	identifier supplied by it (the RII). If it does, then it should		object with a RII object in it.
	inspect the contents of the message and send it no further. This
	should always be the case for local ResponseRequest objects. If one
	of these is received with an incorrect identifier, then the RESPONSE
	must be discarded.
	For other QNR responses, the QNE may inspect the message and then		When a node processes a received RESERVE message it should examine it
	must pass it back to the NTLP to be sent on.		to see if it contains a local ResponseRequest object. If it does,
			then a RESPONSE message is generated, and the contents of this object
			are copied into it. The local ResponseRequest object is removed from
			the RESERVE message being sent out.
	When a RESPONSE message reaches the edge of a stateless domain, the		At the QNR, the processing of local ResponseRequest objects is
	egress QNE will map/interchange the control information used by the		carried out normally (this may happen before this QNE has determined
	"end to end" and "local" scope QoS model types. The generated LCI		that it is the QNR). If the RESERVE message received by the QNR
	information will be encapsulated into the RESPONSE message. By using		contained a ResponseRequest object, then a RESPONSE message is
	the stored SII of the ingress QNE the RESPONSE message will be sent		created with the contents of the ResponseRequest object copied into
	to the particular ingress QNE node.		it.
	Stateless and reduced state interior QNEs are not using the RESPONSE		NSLP for Quality-of-Service signaling October 2003
	message.
	When the RESPONSE message is received by the ingress QNE node, the		On receiving a RESPONSE message a QNE should check the contents of
	LCI information is used by the "local" scope QoS model. Afterwards,		the ResponseRequest object echoed back to see if it contains an
	NSLP for Quality-of-Service signaling September 2003		identifier supplied by it (the RII). If it does, then it should
			inspect the contents of the message and send it no further. This
			should always be the case for local ResponseRequest objects. If one
			of these is received with an incorrect identifier, then the RESPONSE
			must be discarded.
	the LCI information is removed from the RESPONSE message, which is		For other QNR responses, the QNE may inspect the message and then
	sent towards the QNI.		must pass it back to the NTLP to be sent on.
	4.4 Performing a query		When a RESPONSE message reaches the edge of a stateless domain, the
			egress QNE will map/interchange the control information used by the
			"end to end" and "local" scope QoS model types. The generated LCI
			information will be encapsulated into the RESPONSE message. By using
			the stored SII of the ingress QNE the RESPONSE message will be sent
			to the particular ingress QNE node.
	In order to perform a query along a path, a QNE constructs a QUERY		Stateless and reduced state interior QNEs are not using the RESPONSE
	message. The message must contain a ResponseRequest object in the		message.
	same manner as described above to allow it to match any received
	RESPONSE messages back to the original QUERY. The QUERY message may
	contain general QoS NSLP query elements, as well as objects specific
	to a given QoS model. The message is then passed to the NTLP to be
	passed along the path.
	A QNE (including the QNR) receiving a QUERY message should inspect it		When the RESPONSE message is received by the ingress QNE node, the
	and manipulate the general query objects and QoS model specific query		LCI information is used by the "local" scope QoS model. Afterwards,
	objects as required. It then passes it to the NTLP for further		the LCI information is removed from the RESPONSE message, which is
	forwarding unless it knows it is the QNR.		sent towards the QNI.
	At the QNR, a RESPONSE message is generated. Into this is copied the		4.4 Performing a query
	ResponseRequest object, and other general and QoS model specific
	information from the QUERY message. It is then passed to the NTLP to
	be forwarded peer-to-peer back along the path.
	Each QNE receiving the RESPONSE message should inspect the		In order to perform a query along a path, a QNE constructs a QUERY
	ResponseRequest object to see if it contains an RII supplied by it.		message. The message must contain a ResponseRequest object in the
	If it does not then it simply passes the message back to the NTLP		same manner as described above to allow it to match any received
	unless it is a local RESPONSE. If it does, it uses the RII to match		RESPONSE messages back to the original QUERY. The QUERY message may
	the RESPONSE back to the original QUERY, and performs any appropriate		contain general QoS NSLP query elements, as well as objects specific
	action based on the result of the query.		to a given QoS model. The message is then passed to the NTLP to be
			passed along the path.
	4.5 Tearing down a reservation		A QNE (including the QNR) receiving a QUERY message should inspect it
			and manipulate the general query objects and QoS model specific query
			objects as required. It then passes it to the NTLP for further
			forwarding unless it knows it is the QNR.
	Although the use of soft state means that it is not necessary to		At the QNR, a RESPONSE message is generated. Into this is copied the
	explicitly tear down an old reservation, it is RECOMMENDED that QNIs		ResponseRequest object, and other general and QoS model specific
	send a teardown request as soon as a reservation is no longer needed.		information from the QUERY message. It is then passed to the NTLP to
	A teardown deletes reservation state and travels towards the QNR from		be forwarded peer-to-peer back along the path.
	its point of initiation. A teardown message may be initiated either
	by an application in a QNI or by a QNE along the route as the result
	of a state timeout or service preemption. Once initiated, a teardown
	message must be forwarded QNE peer - to - QNE peer without delay.
	A QNE can remove a reservation by building a RESERVE message with the		NSLP for Quality-of-Service signaling October 2003
	'tear' indicator set to inform the next-hop QNE to remove the
	reservation state that it may hold. The tearing RESERVE is passed to
	the NTLP to be forwarded along the NEs up to the next-hop QNE. It is
	currently an open issue whether the tearing RESERVE will
	NSLP for Quality-of-Service signaling September 2003
	automatically tear down state in each NE. The next-hop QNE either		Each QNE receiving the RESPONSE message should inspect the
	tears down the corresponding reservation and passes on the tearing		ResponseRequest object to see if it contains an RII supplied by it.
	RESERVE, or, if it already has torn down the reservation, discards		If it does not then it simply passes the message back to the NTLP
	the message.		unless it is a local RESPONSE. If it does, it uses the RII to match
			the RESPONSE back to the original QUERY, and performs any appropriate
			action based on the result of the query.
	In addition, the QNE should construct a NOTIFY message and attempt to		4.5 Tearing down a reservation
	send it back to the QNE that requested the reservation originally.
	The NOTIFY message will inform the other QNE that a reservation has
	been removed. On receipt of such a NOTIFY message a QNE should
	determine an appropriate course of action. This may include removing
	its own reservation state, and passing the NOTIFY message back
	further along the path.
	The attempt to send a NOTIFY message may be abandoned if the NTLP is		Although the use of soft state means that it is not necessary to
	not able to route the message along the reverse-path (e.g. because it		explicitly tear down an old reservation, it is RECOMMENDED that QNIs
	has not stored the necessary state). In case of a stateless or		send a teardown request as soon as a reservation is no longer needed.
	reduced state domain, the ingress QNE of the domain will be notified		A teardown deletes reservation state and travels towards the QNR from
	by the egress QNE, which has kept track of its SII. The ingress QNE		its point of initiation. A teardown message may be initiated either
	can then send the NOTIFY message further upstream. It can also		by an application in a QNI or by a QNE along the route as the result
	initiate a scoped tearing RESERVE message towards the egress QNE.		of a state timeout or service preemption. Once initiated, a teardown
			message must be forwarded QNE peer - to - QNE peer without delay.
	5. IANA section		A QNE can remove a reservation by building a RESERVE message with the
			'tear' indicator set to inform the next-hop QNE to remove the
			reservation state that it may hold. The tearing RESERVE is passed to
			the NTLP to be forwarded along the NEs up to the next-hop QNE. It is
			currently an open issue whether the tearing RESERVE will
			automatically tear down state in each NE. The next-hop QNE either
			tears down the corresponding reservation and passes on the tearing
			RESERVE, or, if it already has torn down the reservation, discards
			the message.
	This section provides guidance to the Internet Assigned Numbers		In addition, the QNE should construct a NOTIFY message and attempt to
	Authority (IANA) regarding registration of values related to the QoS-		send it back to the QNE that requested the reservation originally.
	NSLP, in accordance with BCP 26 [12].		The NOTIFY message will inform the other QNE that a reservation has
			been removed. On receipt of such a NOTIFY message a QNE should
			determine an appropriate course of action. This may include removing
			its own reservation state, and passing the NOTIFY message back
			further along the path.
	Future versions of this draft will identify name spaces in QoS-NSLP		The attempt to send a NOTIFY message may be abandoned if the NTLP is
	that require registration and contain recommendations for		not able to route the message along the reverse-path (e.g. because it
	registration policies.		has not stored the necessary state). In case of a stateless or
			reduced state domain, the ingress QNE of the domain will be notified
			by the egress QNE, which has kept track of its SII. The ingress QNE
			can then send the NOTIFY message further upstream. It can also
			initiate a scoped tearing RESERVE message towards the egress QNE.
	6. Requirements for the NSIS Transport Layer Protocol (NTLP)		5. IANA section
			NSLP for Quality-of-Service signaling October 2003
	For the moment this section will merely describe what we assume		This section provides guidance to the Internet Assigned Numbers
	and/or request to be available from the NTLP. This section will later		Authority (IANA) regarding registration of values related to the QoS-
	be updated to describe the eventual interface when NTLP work gets		NSLP, in accordance with BCP 26 [12].
	finalized.
	6.1 Support for stateless operation		Future versions of this draft will identify name spaces in QoS-NSLP
			that require registration and contain recommendations for
			registration policies.
	Stateless or reduced state QoS-NSLP operation makes the most sense		6. Requirements for the NSIS Transport Layer Protocol (NTLP)
	when (some nodes of) the underlying NTLP is (are) able to operate in
	a stateless way as well. Such nodes should not worry about keeping
	reverse state, message fragmentation and reassembly (at the NTLP),
	congestion control or security associations. A stateless or reduced
	NSLP for Quality-of-Service signaling September 2003
	state QNE will be able to inform the underlying NTLP of this		For the moment this section will merely describe what we assume
	situation. We rely on the NTLP design to allow for a mode of		and/or request to be available from the NTLP. This section will later
	operation that can take advantage of this information.		be updated to describe the eventual interface when NTLP work gets
			finalized.
	6.2 Support for Source Identification Information (SII)		6.1 Support for stateless operation
	There are several circumstances where it is necessary for a QNE to		Stateless or reduced state QoS-NSLP operation makes the most sense
	identify the adjacent QNE peer, which is the source of a signaling		when (some nodes of) the underlying NTLP is (are) able to operate in
	application message; for example, it may be to apply the policy that		a stateless way as well. Such nodes should not worry about keeping
	"state can only be modified by messages from the node that created		reverse state, message fragmentation and reassembly (at the NTLP),
	it".		congestion control or security associations. A stateless or reduced
			state QNE will be able to inform the underlying NTLP of this
			situation. We rely on the NTLP design to allow for a mode of
			operation that can take advantage of this information.
	We rely on the NTLP to provide this functionality. By default, all		6.2 Support for Source Identification Information (SII)
	outgoing QoS-NSLP messages are tagged like this at the NTLP layer,
	and this is propagated to the next QNE, where it can be used as an
	opaque identifier for the state associated with the message; we call
	this the Source Identification Information (SII). The SII is
	logically similar to the RSVP_HOP object of [4]; however, any IP (and
	possibly higher level) addressing information is not interpreted in
	the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce
	topology hiding by masking the content of the SII (provided this is
	done in a stable way).
	Keeping track of the SII of a certain reservation also provides a		There are several circumstances where it is necessary for a QNE to
	means for the QoS-NSLP to detect route changes. When a QNE receives a		identify the adjacent QNE peer, which is the source of a signaling
	RESERVE referring to existing state but with a different SII, it		application message; for example, it may be to apply the policy that
	knows that its upstream peer has changed. It can then use the old SII		"state can only be modified by messages from the node that created
	to send initiate a teardown along the old section of the path. This		it".
	functionality would require the NTLP to be able to route based on the
	SII. We would like this functionality to be available as a service
	from the NTLP.
	6.3 Last node detection		We rely on the NTLP to provide this functionality. By default, all
			outgoing QoS-NSLP messages are tagged like this at the NTLP layer,
			and this is propagated to the next QNE, where it can be used as an
			opaque identifier for the state associated with the message; we call
			this the Source Identification Information (SII). The SII is
			logically similar to the RSVP_HOP object of [4]; however, any IP (and
			possibly higher level) addressing information is not interpreted in
			the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce
			topology hiding by masking the content of the SII (provided this is
			done in a stable way).
	There are situations in which a QNE needs to determine whether it is		NSLP for Quality-of-Service signaling October 2003
	the last QNE on the data path (QNR), e.g. to construct and send a
	RESPONSE message.
	A number of conditions may result in a QNE determining that it is the		Keeping track of the SII of a certain reservation also provides a
	QNR:		means for the QoS-NSLP to detect route changes. When a QNE receives a
			RESERVE referring to existing state but with a different SII, it
			knows that its upstream peer has changed. It can then use the old SII
			to send initiate a teardown along the old section of the path. This
			functionality would require the NTLP to be able to route based on the
			SII. We would like this functionality to be available as a service
			from the NTLP.
	- the QNE may be the flow destination		6.3 Last node detection
	- the QNE have some other prior knowledge that it should act as		There are situations in which a QNE needs to determine whether it is
	the QNR		the last QNE on the data path (QNR), e.g. to construct and send a
	NSLP for Quality-of-Service signaling September 2003		RESPONSE message.
	- the QNE may be the last NSIS-capable node on the path		A number of conditions may result in a QNE determining that it is the
			QNR:
	- the QNE may be the last NSIS-capable node on the path		- the QNE may be the flow destination
	supporting the QoS NSLP
	Of these four conditions, the last two can only be detected by the		- the QNE have some other prior knowledge that it should act as
	NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by		the QNR
	providing a trigger to the QoS-NSLP when it determines that it is the
	last NE on the path, which supports the QoS-NSLP. It requires the
	NTLP to have an error message indicating that no more NSLPs of a
	particular type are available on the path.
	6.4 Re-routing detection		- the QNE may be the last NSIS-capable node on the path
	This trigger is provided when the NTLP detects that the route taken		- the QNE may be the last NSIS-capable node on the path
	by a flow (which the QoS-NSLP has issued signaling messages for) has		supporting the QoS NSLP
	changed.
	6.5 Performance requirements		Of these four conditions, the last two can only be detected by the
			NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by
			providing a trigger to the QoS-NSLP when it determines that it is the
			last NE on the path, which supports the QoS-NSLP. It requires the
			NTLP to have an error message indicating that no more NSLPs of a
			particular type are available on the path.
	The QoS-NSLP will generate messages with a range of performance		6.4 Re-routing detection
	requirements for the NTLP. These requirements may result from a
	prioritization at the QoS-NSLP (section 7.3.4) or from the
	responsiveness expected by certain applications supported by the QoS-
	NSLP.
	The NTLP design should be able to ensure that performance for one		This trigger is provided when the NTLP detects that the route taken
	class of messages was not degraded by aggregation with other classes		by a flow (which the QoS-NSLP has issued signaling messages for) has
	of messages. The different classes of performance requirements will		changed.
	be listed in future versions of this document.
	7. Open issues		6.5 Performance requirements
	7.1 Refinements of this version		The QoS-NSLP will generate messages with a range of performance
			requirements for the NTLP. These requirements may result from a
			NSLP for Quality-of-Service signaling October 2003
	Some topics raised in this document would benefit from more detailed		prioritization at the QoS-NSLP (section 7.3.4) or from the
	discussion. These include:		responsiveness expected by certain applications supported by the QoS-
	- description of the operation under re-routing conditions		NSLP.
	- description of the modification operation
	- description of the operation under error conditions
	- detailed discussion of message timer
	- detailed discussion of control information, more particularly
	message scoping
	- detailed discussion on the impact of a tearing RESERVE on state
	NSLP for Quality-of-Service signaling September 2003
	teardown at the NTLP		The NTLP design should be able to ensure that performance for one
			class of messages was not degraded by aggregation with other classes
			of messages. The different classes of performance requirements will
			be listed in future versions of this document.
	7.2 Content for next (-01) version		7. Open issues
	In addition to refining the discussion of topics currently described		7.1 Refinements of this version
	in this document, we intend the next version of this document to
	discuss the following issues.
	7.2.1 Sender/Receiver-initiated operation		Some topics raised in this document would benefit from more detailed
			discussion. These include:
			- description of the operation under re-routing conditions
			- description of the modification operation
			- description of the operation under error conditions
			- detailed discussion of message timer
			- detailed discussion of control information, more particularly
			message scoping
			- detailed discussion on the impact of a tearing RESERVE on state
			teardown at the NTLP
	A sender-initiated reservation is made when the QNI for that flow is		7.2 Content for next (-02) version
	located upstream of the QNR with respect to the data path of the flow
	that is being signaled for. A receiver-initiated reservation is then
	made when the QNI is located downstream of the QNR with respect to
	the data path of the flow that is being signaled for. Note however,
	that the actual QoS-NSLP entities that initiate these signaling
	procedures can be anywhere along the data path, not just at the
	endpoints.
	There are signaling scenarios in which the receiver-initiated		In addition to refining the discussion of topics currently described
	approach is more advantageous, while in others the sender-initiated		in this document, we intend the next version of this document to
	approach is required. QoS-NSLP stateless operation, for example, is		discuss the following issues.
	only possible when the sender-initiated approach is applied.
	The next version of this draft will describe the use of sender-		7.2.1 Sender/Receiver-initiated operation
	initiated and receiver-initiated reservations in the protocol. Note
	that the solution of this issue will also impact the way bi-
	directional reservations are supported (see Section 7.3.3).
	7.2.2 Message formats		A sender-initiated reservation is made when the QNI for that flow is
			located upstream of the QNR with respect to the data path of the flow
			that is being signaled for. A receiver-initiated reservation is then
			made when the QNI is located downstream of the QNR with respect to
			the data path of the flow that is being signaled for. Note however,
			that the actual QoS-NSLP entities that initiate these signaling
			procedures can be anywhere along the data path, not just at the
			endpoints.
	This version of the draft describes the functionality provided by the		There are signaling scenarios in which the receiver-initiated
	QoS-NSLP messages. Encoding this functionality into a message format		approach is more advantageous, while in others the sender-initiated
	is left for the next version.		NSLP for Quality-of-Service signaling October 2003
	7.2.3 Message flows		approach is required. QoS-NSLP stateless operation, for example, is
			only possible when the sender-initiated approach is applied.
	This version of the draft briefly describes basic protocol operation.		The next version of this draft will describe the use of sender-
	Future versions of this draft will include message flow diagrams for		initiated and receiver-initiated reservations in the protocol. Note
	informative purposes (potentially in an appendix).		that the solution of this issue will also impact the way bi-
			directional reservations are supported (see Section 7.3.3).
	7.3 Content for future (-0x) versions		7.2.2 Message formats
	NSLP for Quality-of-Service signaling September 2003
	7.3.1 Aggregation		This version of the draft describes the functionality provided by the
			QoS-NSLP messages. Encoding this functionality into a message format
			is left for the next version.
	Future versions of this document will describe the use of aggregation		7.2.3Message flows
	to reduce the signaling overhead (message bundling) and the routing
	state (similar to [13]).
	7.3.2 Tunnel management		This version of the draft briefly describes basic protocol operation.
			Future versions of this draft will include message flow diagrams for
			informative purposes (potentially in an appendix).
	Future versions of this document will describe the use of QoS-NSLP		7.3 Content for future (-0x) versions
	over tunnels and the associated tunnel management.
	7.3.3 Bi-directional/proxy operation		7.3.1 Aggregation
	A future version of this draft will discuss the use of bi-directional		Future versions of this document will describe the use of aggregation
	reservations, i.e. combining the reservations for a pair of coupled		to reduce the signaling overhead (message bundling) and the routing
	flows going in opposite directions. The main difficulty here is that		state (similar to [13]).
	the two flows, although between the same end points, may traverse
	different paths across the Internet.
	Two proposals for tackling this are:		7.3.2 Tunnel management
	- generate both a sender initiated and a receiver-initiated
	reservation at the QNI (section 7.2.1), and allow them to be bundled
	together by the NTLP (the bundle can be split if the paths diverge).
	- generate a sender-initiated reservation that includes a request for
	the QNR to generate a sender-initiated reservation for the flow in
	the other direction.
	Both methods make some assumption about the flow routing. The first		Future versions of this document will describe the use of QoS-NSLP
	method requires that both flows pass through the same QNI. The second		over tunnels and the associated tunnel management.
	assumes that the QNR for one direction is on the path of the flow in
	the other direction.
	A future version will also include discussion on the operation of		7.3.3 Bi-directional/proxy operation
	QoS-NSLP with (path-coupled) proxies.
	7.3.4 Priority and preemption		A future version of this draft will discuss the use of bi-directional
			reservations, i.e. combining the reservations for a pair of coupled
			flows going in opposite directions. The main difficulty here is that
			the two flows, although between the same end points, may traverse
			different paths across the Internet.
	The QoS-NSLP will generate messages with different priority.		Two proposals for tackling this are:
	Prioritization at the level of the QoS-NSLP includes reservation
	priority and message priority.
	Reservation priority enables some reservations to be setup even if		NSLP for Quality-of-Service signaling October 2003
	resources would normally not be available (e.g. for emergency
	services). This requires a priority indication in the message. Note
	NSLP for Quality-of-Service signaling September 2003
	that such an indication may be restricted to the QoS model scope,		- generate both a sender initiated and a receiver-initiated
	although every QoS model is expected to need this functionality.		reservation at the QNI (section 7.2.1), and allow them to be bundled
	Whether resources are freed by means of pre-emption (the act of		together by the NTLP (the bundle can be split if the paths diverge).
	tearing down an existing reservation to free resource for a new one)		- generate a sender-initiated reservation that includes a request for
	or whether high-priority resources should be pre-provisioned is an		the QNR to generate a sender-initiated reservation for the flow in
	implementation issue for the Resource Management Function.		the other direction.
	Message priority allows QoS-NSLP messages to be processed and		Both methods make some assumption about the flow routing. The first
	forwarded in a different order than in which they arrived. This may		method requires that both flows pass through the same QNI. The second
	be needed to ensure responsiveness to reservation requests or		assumes that the QNR for one direction is on the path of the flow in
	modifications (e.g. a reservation caused by a mobility event of an		the other direction.
	in-service session may need to be handled faster than a query or a
	new reservation request). This kind of prioritization should then be
	supported in the QoS-NSLP message set and may pose requirements on
	the NTLP (section 6.5).
	Future versions of this document will describe the support and use of		A future version will also include discussion on the operation of
	prioritization for the QoS-NSLP.		QoS-NSLP with (path-coupled) proxies.
	7.3.5 Network Address Translation (NAT)		7.3.4 Priority and preemption
	Since the QoS-NSLP is used for requesting resources for data flows,		The QoS-NSLP will generate messages with different priority.
	the messages inevitably involve IP addresses and, possibly, port		Prioritization at the level of the QoS-NSLP includes reservation
	numbers. However, the addresses/ports of the data flow can be		priority and message priority.
	modified by Network Address Translators (NATs) along the path. It is
	hoped that some (or all) of this problem can be pushed down into the
	NTLP, so that only generic NSIS-awareness is required at the NAT,
	rather than requiring specific support for QoS-NSLP (as described in
	section 5.3 of [3]). Future versions of this document may contain
	additional discussion on this issue.
	7.3.6 Security components		Reservation priority enables some reservations to be setup even if
			resources would normally not be available (e.g. for emergency
			services). This requires a priority indication in the message. Note
			that such an indication may be restricted to the QoS model scope,
			although every QoS model is expected to need this functionality.
			Whether resources are freed by means of pre-emption (the act of
			tearing down an existing reservation to free resource for a new one)
			or whether high-priority resources should be pre-provisioned is an
			implementation issue for the Resource Management Function.
	7.3.7 Mobility		Message priority allows QoS-NSLP messages to be processed and
			forwarded in a different order than in which they arrived. This may
			be needed to ensure responsiveness to reservation requests or
			modifications (e.g. a reservation caused by a mobility event of an
			in-service session may need to be handled faster than a query or a
			new reservation request). This kind of prioritization should then be
			supported in the QoS-NSLP message set and may pose requirements on
			the NTLP (section 6.5).
	A future version of this draft will provide details on mobility		Future versions of this document will describe the support and use of
	support in QoS-NSLP, following the requirements in [2], [14]. A		prioritization for the QoS-NSLP.
	number of issues are associated with mobility support, such as
	localizing the new reservation to the new segment of the path,
	removing reservation state along the old segment of the path,
	recognizing a RESERVE message for an already established reservation
	although the IP address of the mobile node changed, possible
	concealment of QoS-NSLP messages due to IP-in-IP tunneling utilized
	in mobile IP, etc. Some of these issues can be solved by employing a
	session ID that is independent of the IP address, in addition to the
	NSLP for Quality-of-Service signaling September 2003
	flow ID (this has security implications, see [15]), and by supporting		7.3.5 Network Address Translation (NAT)
	the SII and reservation sequence numbers. Some mobility support will		NSLP for Quality-of-Service signaling October 2003
	be provided by NTLP, such as detection of route changes. More details
	are discussed in [16].
	8. Security Considerations		Since the QoS-NSLP is used for requesting resources for data flows,
			the messages inevitably involve IP addresses and, possibly, port
			numbers. However, the addresses/ports of the data flow can be
			modified by Network Address Translators (NATs) along the path. It is
			hoped that some (or all) of this problem can be pushed down into the
			NTLP, so that only generic NSIS-awareness is required at the NAT,
			rather than requiring specific support for QoS-NSLP (as described in
			section 5.3 of [3]). Future versions of this document may contain
			additional discussion on this issue.
	The security of the NSLP is provided by a combination of security		7.3.6 Security components
	functions at the NTLP and NSLP. Subsequent versions of this draft
	will need to contain a specification of the NSLP security features,
	and how these interact with those at the NTLP.
	Some consideration of the problems can be found in [17][15][8]		7.3.7 Mobility
	9. Change History		A future version of this draft will provide details on mobility
			support in QoS-NSLP, following the requirements in [2], [14]. A
			number of issues are associated with mobility support, such as
			localizing the new reservation to the new segment of the path,
			removing reservation state along the old segment of the path,
			recognizing a RESERVE message for an already established reservation
			although the IP address of the mobile node changed, possible
			concealment of QoS-NSLP messages due to IP-in-IP tunneling utilized
			in mobile IP, etc. Some of these issues can be solved by employing a
			session ID that is independent of the IP address, in addition to the
			flow ID (this has security implications, see [15]), and by supporting
			the SII and reservation sequence numbers. Some mobility support will
			be provided by NTLP, such as detection of route changes. More details
			are discussed in [16].
	10. Appendix A: A strawman QSpec template		8. Security Considerations
	This appendix describes a strawman QSpec template. The QSpec template		The security of the NSLP is provided by a combination of security
	could include objects and fields for conveying the following		functions at the NTLP and NSLP. Subsequent versions of this draft
	information:		will need to contain a specification of the NSLP security features,
			and how these interact with those at the NTLP.
	- QSpec ID: This would allow IANA reservation of well known		Some consideration of the problems can be found in [17][15][8]
	QSpec parameter combinations
	- Traffic Envelope and traffic conformance (similar to RSVP's		9. Change History
	TSpec)
	- Excess treatment: what happens to non-conforming traffic of a		10. Appendix A: A strawman QSpec template
	certain reservation (may be dropped but could be remarked as		NSLP for Quality-of-Service signaling October 2003
	well)
	- Offered guarantees: this may be delay, jitter, loss or		This appendix describes a strawman QSpec template. The QSpec template
	throughput, both qualitatively (low delay) and quantitatively		could include objects and fields for conveying the following
	(delay < 100ms, optionally even with quantiles		information:
	Note that the specification may support ranges of acceptable
	values
	- Service schedule: for when is the service requested: this		- QSpec ID: This would allow IANA reservation of well known
	would allow a RESERVE/COMMIT functionality		QSpec parameter combinations
	- Reliability: what percentage of the time do you expect to get		- Traffic Envelope and traffic conformance (similar to RSVP's
	the offered guarantee (this will allow e.g. a local resource		TSpec)
	management function to map the traffic to an APS protected
	link)
	NSLP for Quality-of-Service signaling September 2003
	- Monitoring requirements: what information do you require about		- Excess treatment: what happens to non-conforming traffic of a
	the reservation. This is related to the AdSpec functionality		certain reservation (may be dropped but could be remarked as
	and may contain parameters or sub object to be used in QUERY.		well)
	Note that Flow identification information is also needed but that		- Offered guarantees: this may be delay, jitter, loss or
	this is not assumed to be part of the QSpec template but rather		throughput, both qualitatively (low delay) and quantitatively
	available over the API between NTLP and QoS-NSLP.		(delay < 100ms, optionally even with quantiles
			Note that the specification may support ranges of acceptable
			values
	It is not the intention that all QoS models support all fields and		- Service schedule: for when is the service requested: this
	sub objects defined here. The definition of a QoS model entails a		would allow a RESERVE/COMMIT functionality
	selection of one or more of these fields and/or sub objects. For
	instance, one QoS model could only allow QSpec ID and DSCP to be
	specified.
	References		- Reliability: what percentage of the time do you expect to get
			the offered guarantee (this will allow e.g. a local resource
			management function to map the traffic to an APS protected
			link)
	1 Bradner, S., "Key words for use in RFCs to Indicate Requirement		- Monitoring requirements: what information do you require about
	Levels", BCP 14, RFC 2119, March 1997		the reservation. This is related to the AdSpec functionality
			and may contain parameters or sub object to be used in QUERY.
	2 M. Brunner, Ed., "Requirements for QoS signaling protocols."		Note that Flow identification information is also needed but that
	draft-ietf-nsis-req-09.txt, August 2003.		this is not assumed to be part of the QSpec template but rather
			available over the API between NTLP and QoS-NSLP.
	3 R. Hancock, Ed., "Next Steps in Signaling: Framework", draft-ietf-		It is not the intention that all QoS models support all fields and
	nsis-fw-03.txt (work in progress), June 2003.		sub objects defined here. The definition of a QoS model entails a
			selection of one or more of these fields and/or sub objects. For
			instance, one QoS model could only allow QSpec ID and DSCP to be
			specified.
	4 Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,		References
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", RFC 2205, September 1997.
	5 Braden, B., Clark, D. and S. Shenker, "Integrated Services in the		1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Internet Architecture: an Overview", RFC 1633, June 1994.		Levels", BCP 14, RFC 2119, March 1997
			NSLP for Quality-of-Service signaling October 2003
	6 Wroclawski, J., "The Use of RSVP with IETF Integrated Services",		2 M. Brunner, Ed., "Requirements for QoS signaling protocols."
	RFC 2210, September 1997.		draft-ietf-nsis-req-09.txt, August 2003.
	7 Tschofenig, H., "NSIS Authentication, Authorization and Accounting		3 R. Hancock, Ed., "Next Steps in Signaling: Framework", draft-ietf-
	Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress),		nsis-fw-03.txt (work in progress), June 2003.
	March 2003.
	8 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne,		4 Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
	"QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-		"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	issues-00 (work in progress), June 2003.		Specification", RFC 2205, September 1997.
	NSLP for Quality-of-Service signaling September 2003		5 Braden, B., Clark, D. and S. Shenker, "Integrated Services in the
			Internet Architecture: an Overview", RFC 1633, June 1994.
	9 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An		6 Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
	Architecture for Differentiated Services", RFC 2475, December		RFC 2210, September 1997.
	1998.
	10 Metro Ethernet Forum, "Ethernet Services Model," letter ballot		7 Tschofenig, H., "NSIS Authentication, Authorization and Accounting
	document, August 2003.		Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress),
			March 2003.
	11 Westberg, L., "Resource Management in Diffserv (RMD) Framework",		8 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne,
	draft-westberg-rmd-framework-04 (work in progress), September		"QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-
	2003.		issues-00 (work in progress), June 2003.
	12 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA		9 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Architecture for Differentiated Services", RFC 2475, December
			1998.
	13 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,		10 Metro Ethernet Forum, "Ethernet Services Model," letter ballot
	"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,		document, August 2003.
	September 2001.
	14 H. Chaskar, "Requirements of a QoS solution for Mobile IP," RFC		11 Westberg, L., "Resource Management in Diffserv (RMD) Framework",
	3583, Sept. 2003.		draft-westberg-rmd-framework-04 (work in progress), September
			2003.
	15 H. Tschofenig, H. Schulzrinne, et al., "Security implications of		12 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
	the session identifier" Internet Draft, June 2003.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	16 X. Fu, H. Schulzrinne, H. Tschofenig "Mobility Support in NSIS",		13 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
	Internet Draft, June 2003.		"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
			September 2001.
	17 H. Tschofenig and D. Kroeselberg, "Security Threats for NSIS",		14 H. Chaskar, "Requirements of a QoS solution for Mobile IP," RFC
	draft-ietf-nsis-threats-02.txt (work in progress), June 2003.		3583, Sept. 2003.
	Acknowledgments		NSLP for Quality-of-Service signaling October 2003
	This section will contain acknowledgments.
	Contributors		15 H. Tschofenig, H. Schulzrinne, et al., "Security implications of
			the session identifier" Internet Draft, June 2003.
	This draft combines work from three individual drafts. The following		16 X. Fu, H. Schulzrinne, H. Tschofenig "Mobility Support in NSIS",
	authors from these drafts also contributed to this document: Robert		Internet Draft, June 2003.
	Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
	Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
	Maarten Buechli (Dante) and Eric Waegeman (Alcatel).
	Contact information		17 H. Tschofenig and D. Kroeselberg, "Security Threats for NSIS",
			draft-ietf-nsis-threats-02.txt (work in progress), June 2003.
	Georgios Karagiannis		Acknowledgments
	University of Twente		This section will contain acknowledgments.
	P.O. BOX 217
	7500 AE Enschede
	The Netherlands
	email: karagian@cs.utwente.nl
	Andrew McDonald		Contributors
	Roke Manor Research
	Old Salisbury Lane
	Romsey
	Hampshire
	SO51 0ZN
	United Kingdom
	email: andrew.mcdonald@roke.co.uk
	Sven Van den Bosch		This draft combines work from three individual drafts. The following
	Alcatel		authors from these drafts also contributed to this document: Robert
	Francis Wellesplein 1		Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
	B-2018 Antwerpen		Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
	Belgium		Maarten Buechli (Dante) and Eric Waegeman (Alcatel).
	email: sven.van_den_bosch@alcatel.be
	Full Copyright Statement		Contact information
	Copyright (C) The Internet Society (2003). All Rights Reserved. This		Georgios Karagiannis
	document and translations of it may be copied and furnished to		University of Twente
	others, and derivative works that comment on or otherwise explain it		P.O. BOX 217
	or assist in its implementation may be prepared, copied, published		7500 AE Enschede
	and distributed, in whole or in part, without restriction of any		The Netherlands
	NSLP for Quality-of-Service signaling September 2003		email: karagian@cs.utwente.nl
	kind, provided that the above copyright notice and this paragraph are		Andrew McDonald
	included on all such copies and derivative works. However, this		Roke Manor Research
	document itself may not be modified in any way, such as by removing		Old Salisbury Lane
	the copyright notice or references to the Internet Society or other		Romsey
	Internet organizations, except as needed for the purpose of		Hampshire
	developing Internet standards in which case the procedures for		SO51 0ZN
	copyrights defined in the Internet Standards process must be		United Kingdom
	followed, or as required to translate it into languages other than		email: andrew.mcdonald@roke.co.uk
	English.
	The limited permissions granted above are perpetual and will not be		Sven Van den Bosch
	revoked by the Internet Society or its successors or assigns. This		Alcatel
	document and the information contained herein is provided on an "AS		Francis Wellesplein 1
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK		B-2018 Antwerpen
	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT		Belgium
	LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL		email: sven.van_den_bosch@alcatel.be
	NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
	OR FITNESS FOR A PARTICULAR PURPOSE.		Full Copyright Statement
			Copyright (C) The Internet Society (2003). All Rights Reserved. This
			document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			NSLP for Quality-of-Service signaling October 2003
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns. This
			document and the information contained herein is provided on an "AS
			IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
			FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
			LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
			NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
			OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 278 change blocks.
	1092 lines changed or deleted		1096 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/