< draft-ietf-nsis-req-01.txt		draft-ietf-nsis-req-02.txt >
	NSIS Working Group		NSIS Working Group
	Internet Draft M. Brunner (Editor)		Internet Draft M. Brunner (Editor)
	Document: draft-ietf-nsis-req-01.txt NEC		Document: draft-ietf-nsis-req-02.txt NEC
	Expires: October 2002 April 2002		Expires: November 2002 May 2002
	Requirements for QoS Signaling Protocols		Requirements for QoS Signaling Protocols
	<draft-ietf-nsis-req-01.txt>		<draft-ietf-nsis-req-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with 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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference 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 document defines requirements for signaling QoS across		This document defines requirements for signaling QoS across
	different network environments. To achieve wide applicability of the		different network environments. To achieve wide applicability of the
	requirements, the starting point is a diverse set of scenarios/use		requirements, the starting point is a diverse set of scenarios/use
	cases concerning various types of networks and application		cases concerning various types of networks and application
	interactions. We also provide an outline structure for the problem,		interactions. We also provide an outline structure for the problem,
	including QoS related terminology. Taken with the scenarios, this		including QoS related terminology. Taken with the scenarios, this
	allows us to focus more precisely on which parts of the overall QoS		allows us to focus more precisely on which parts of the overall QoS
	problem needs to be solved. We present the assumptions and the		problem needs to be solved. We present the assumptions and the
	aspects not considered within scope before listing the requirements		aspects not considered within scope before listing the requirements
	grouped according to areas such as architecture and design goals,		grouped according to areas such as architecture and design goals,
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	implies the need for the translation of information into QoS domain		implies the need for the translation of information into QoS domain
	specific format as well.		specific format as well.
	4. We assume that the service definitions a QoS initiator can ask		4. We assume that the service definitions a QoS initiator can ask
	for are known in advance of the signaling protocol running. Service		for are known in advance of the signaling protocol running. Service
	definition includes QoS parameters, life-time of QoS guarantee etc.		definition includes QoS parameters, life-time of QoS guarantee etc.
	There are many ways a service requester get to know about it. There		There are many ways a service requester get to know about it. There
	might be standardized services, the definition can be negotiated		might be standardized services, the definition can be negotiated
	together with a contract, the service definition is published at a		together with a contract, the service definition is published at a
	Web-page, etc.		Web-page, etc.
	5. We assume that there are means for the discovery of NSIS entities		5. We assume that there are means for the discovery of NSIS entities
	in order to know the signaling peers (solutions include static		in order to know the signaling peers (solutions include static
	configuration, automatically discovered, or implicitly runs over the		configuration, automatically discovered, or implicitly runs over the
	right nodes, etc.)		right nodes, etc.)
	4.2 Exclusions		4.2 Exclusions
	1. Development of specific mechanisms and algorithms for application		1. Development of specific mechanisms and algorithms for application
	and transport layer adaptation are not considered, nor are the		and transport layer adaptation are not considered, nor are the
	protocols that would support it.		protocols that would support it.
	2. Specific mechanisms (APIs and so on) for interaction between		2. Specific mechanisms (APIs and so on) for interaction between
	transport/applications and the network layer are not considered,		transport/applications and the network layer are not considered,
	except to clarify the requirements on the negotiation capabilities		except to clarify the requirements on the negotiation capabilities
	and information semantics that would be needed of the signaling		and information semantics that would be needed of the signaling
	protocol. The same applies to application adaptation mechanisms.		protocol. The same applies to application adaptation mechanisms.
	3. Specific mechanisms for QoS provisioning within a		3. Specific mechanisms for QoS provisioning within a
	domain/subdomain are not considered. It should be possible to		domain/subdomain are not considered. It should be possible to
	exploit these mechanisms optimally within the end to end context.		exploit these mechanisms optimally within the end to end context.
	Consideration of how to do this might generate new requirements for		Consideration of how to do this might generate new requirements for
	NSIS however. For example, the information needed by an QoS		NSIS however. For example, the information needed by an QoS
	controller to manage a radio subnetwork needs to be provided by the		controller to manage a radio subnetwork needs to be provided by the
	NSIS solution.		NSIS solution.
	4. Specific mechanisms (APIs and so on) for interaction between the		4. Specific mechanisms (APIs and so on) for interaction between the
	network layer and underlying QoS provisioning mechanisms are not		network layer and underlying QoS provisioning mechanisms are not
	considered.		considered.
	5. Interaction with QoS administration capabilities is not		5. Interaction with QoS administration capabilities is not
	considered. Standard protocols should be used for this (e.g. COPS).		considered. Standard protocols should be used for this (e.g. COPS).
	This may imply requirements for the sort of information that should		This may imply requirements for the sort of information that should
	be exchanged between the NSIS network QoS entities.		be exchanged between the NSIS network QoS entities.
	6. Security issues related to multicasting are outside the scope of		6. Security issues related to multicasting are outside the scope of
	the QoS signaling protocol.		the QoS signaling protocol.
	Since multicasting is currently not an issue for the QoS protocol,		Since multicasting is currently not an issue for the QoS protocol,
	security issues related to multicast are outside the scope.		security issues related to multicast are outside the scope.
	Multicast security may additionally be an application issue that is		Multicast security may additionally be an application issue that is
	also outside the scope of the QoS protocol.		also outside the scope of the QoS protocol.
	7. Protection of non-QoS signaling messages is outside the scope of		7. Protection of non-QoS signaling messages is outside the scope of
	the QoS protocol		the QoS protocol
	Security protection of data messages transmitted along the		Security protection of data messages transmitted along the
	established QoS path is outside the scope of the QoS protocol. These		established QoS path is outside the scope of the QoS protocol. These
	security properties are likely to be application specific and may be		security properties are likely to be application specific and may be
	provided by the corresponding application layer protocol.		provided by the corresponding application layer protocol.
	8. Service definitions and QoS classes are out of scope. Together		8. Service definitions and QoS classes are out of scope. Together
	with the service definition any definition of service specific		with the service definition any definition of service specific
	parameters are not considered in this draft. Only the base NSIS		parameters are not considered in this draft. Only the base NSIS
	signaling protocol for transporting the QoS/service information are		signaling protocol for transporting the QoS/service information are
	handled.		handled.
	9. Similarly, specific methods, protocols, and ways to express QoS		9. Similarly, specific methods, protocols, and ways to express QoS
	information in the Application/Session level are not considered		information in the Application/Session level are not considered
	(e.g., SDP, SIP, RTSP, etc.).		(e.g., SDP, SIP, RTSP, etc.).
	10. The specification of any extensions needed to signal QoS		10. The specification of any extensions needed to signal QoS
	information via application level protocols (e.g. SDP(ng)), and the		information via application level protocols (e.g. SDP(ng)), and the
	mapping on NSIS information are considered outside of the scope of		mapping on NSIS information are considered outside of the scope of
	NSIS working group, as this work is in the direct scope of other		NSIS working group, as this work is in the direct scope of other
	IETF working groups (e.g. MMUSIC).		IETF working groups (e.g. MMUSIC).
	5 Requirements		5 Requirements
	This section defines more detailed requirements for a QoS signaling		This section defines more detailed requirements for a QoS signaling
	solution, derived from consideration of the use cases/scenarios, and		solution, derived from consideration of the use cases/scenarios, and
	respecting the framework, scoping assumptions, and terminology		respecting the framework, scoping assumptions, and terminology
	considered earlier. The requirements are in subsections, grouped		considered earlier. The requirements are in subsections, grouped
	roughly according to general technical aspects: architecture and		roughly according to general technical aspects: architecture and
	design goals, topology issues, QoS parameters, performance,		design goals, topology issues, QoS parameters, performance,
	security, information, and flexibility.		security, information, and flexibility.
	Two general (and potentially contradictory) goals for the solution		Two general (and potentially contradictory) goals for the solution
	are that it should be applicable in a very wide range of scenarios,		are that it should be applicable in a very wide range of scenarios,
	and at the same time lightweight in implementation complexity and		and at the same time lightweight in implementation complexity and
	resource requirements in nodes. One approach to this is that the		resource requirements in nodes. One approach to this is that the
	solution could deal with certain requirements via modular components		solution could deal with certain requirements via modular components
	or capabilities, which are optional to implement in individual		or capabilities, which are optional to implement in individual
	nodes.		nodes.
	Some of the requirements are technically contradictory. Depending on		Some of the requirements are technically contradictory. Depending on
	the scenarios a solution applies to, one or the other requirement is		the scenarios a solution applies to, one or the other requirement is
	applicable.		applicable.
	Find in Section 6 the MUSTs, SHOULDs, and MAYs		Find in Section 6 the MUSTs, SHOULDs, and MAYs
	5.1 Architecture and Design Goals		5.1 Architecture and Design Goals
	This section contains requirements related to desirable overall		This section contains requirements related to desirable overall
	characteristics of a solution, e.g. enabling flexibility, or		characteristics of a solution, e.g. enabling flexibility, or
	independence of parts of the framework.		independence of parts of the framework.
	5.1.1
	Applicability for different QoS technologies.		5.1.1 Applicability for different QoS technologies.
	The QoS signaling protocol must work with various QoS technologies.		The QoS signaling protocol must work with various QoS technologies.
	The information exchanged over the signaling protocol must be in		The information exchanged over the signaling protocol must be in
	such detail and quantity that it is useful for various QoS		such detail and quantity that it is useful for various QoS
	technologies.		technologies.
	5.1.2
	Resource availability information on request		5.1.2 Resource availability information on request
	In some scenarios, e.g., the mobile terminal scenario, it is		In some scenarios, e.g., the mobile terminal scenario, it is
	required to query, whether resources are available, without		required to query, whether resources are available, without
	performing a reservation on the resource. One solution might be a		performing a reservation on the resource. One solution might be a
	feedback mechanism based on which a QoS inferred handover can take		feedback mechanism based on which a QoS inferred handover can take
	place.		place.
	5.1.3
	Modularity		5.1.3 Modularity
	A modular design allows for more lightweight implementations, if		A modular design allows for more lightweight implementations, if
	fewer features are needed. Mutually exclusive solutions are		fewer features are needed. Mutually exclusive solutions are
	supported. Examples for modularity:		supported. Examples for modularity:
	- Work over any kind of network (narrowband / broadband, error-prone		- Work over any kind of network (narrowband / broadband, error-prone
	/ reliable...) - This implies low bandwidth signaling and redundant		/ reliable...) - This implies low bandwidth signaling and redundant
	information must be supported if necessary.		information must be supported if necessary.
	- In case QoS requirements are soft (e.g. banking transactions,		- In case QoS requirements are soft (e.g. banking transactions,
	gaming), fast and lightweight signaling (e.g., not more than one		gaming), fast and lightweight signaling (e.g., not more than one
	round-trip time)		round-trip time)
	- Uni- and bi-directional reservations are possible		- Uni- and bi-directional reservations are possible
	5.1.4
	Decoupling of protocol and information it is carrying		5.1.4 Decoupling of protocol and information it is carrying
	The signaling protocol(s) used must be clearly separated from the		The signaling protocol(s) used must be clearly separated from the
	QoS control information being transported. This provides for the		QoS control information being transported. This provides for the
	independent development of these two aspects of the solution, and		independent development of these two aspects of the solution, and
	allows for this control information to be carried within other		allows for this control information to be carried within other
	protocols, including application layer ones, existing ones or those		protocols, including application layer ones, existing ones or those
	being developed in the future. The gained flexibility in the		being developed in the future. The gained flexibility in the
	information transported allows for the applicability of the same		information transported allows for the applicability of the same
	protocol in various scenarios.		protocol in various scenarios.
	However, note that the information carried needs to be the same.		However, note that the information carried needs to be the same.
	Otherwise interoperability is difficult to achieve.		Otherwise interoperability is difficult to achieve.
	5.1.5
	Reuse of existing QoS provisioning		5.1.5 Reuse of existing QoS provisioning
	Reuse existing QoS functions and protocols for QoS provisioning		Reuse existing QoS functions and protocols for QoS provisioning
	within a domain/subdomain unchanged. (Motivation: 'Don't re-invent		within a domain/subdomain unchanged. (Motivation: 'Don't re-invent
	the wheel'.)		the wheel'.)
	5.1.6
	Avoid duplication of [sub]domain signaling functions		5.1.6 Independence of signaling and provisioning paradigm
	The specification of the NSIS signaling protocol should be optimized
	to avoid duplication of existing [sub]domain QoS signaling and to
	minimize the overall complexity. (Motivation: we don't want to
	introduce duplicate feedback or negotiation mechanisms, or
	complicate the work by including all possible existing QoS signaling
	in some form. The function will be placed in the new part if it has
	to be end-to-end, universal to all network types
	('simple/lightweight'), or if it has to be protected by upper layer
	security mechanisms.)
	The point here is that the QoS technology (lower layer stuff) gets
	re-used unchanged, and we have new signaling above it. But, in many
	cases the local QoS technology will contain equivalent functions to
	the NSIS-required ones, just in a technology specific form. Examples
	of these functions would be error/QoS violation notifications,
	ability to query for resources and so on. So, there is a danger that
	our 'lightweight' signaling ends up trying to carry all this
	information all over again, and (even worse) that the
	initiator/controller functions have to weigh up nearly equivalent
	information coming from two directions. However, the basic problem
	here is that the boundary between new and re-used stuff is pretty
	shaky. The requirement is trying to scope our problem (a) to
	eliminate the potential overlap, and (b) to keep the new NSIS stuff
	simple.
	However, we are aware that it is very difficult to judge what is
	duplicated, if we want to run the protocol in various environments.
	5.1.7
	Independence of signaling and provisioning paradigm
	The QoS signaling should be independent of the paradigm and		The QoS signaling should be independent of the paradigm and
	mechanism of QoS provisioning. The independence allows for using the		mechanism of QoS provisioning. The independence allows for using the
	NSIS protocol together with various QoS technologies.		NSIS protocol together with various QoS technologies.
	5.2 Signaling Flows		5.2 Signaling Flows
	This section contains requirements related to the possible signaling		This section contains requirements related to the possible signaling
	flows that should be supported, e.g. over what parts of the flow		flows that should be supported, e.g. over what parts of the flow
	path, between what entities (end-systems, routers, middleboxes,		path, between what entities (end-systems, routers, middleboxes,
	management systems), in which direction.		management systems), in which direction.
	5.2.1
	Free placement of QoS Initiator and QoS Controllers functions		5.2.1 Free placement of QoS Initiator and QoS Controllers functions
	The protocol(s) must work in various scenarios such as host-to-		The protocol(s) must work in various scenarios such as host-to-
	network-to-host, edge-to-edge, (e.g., just within one providers		network-to-host, edge-to-edge, (e.g., just within one providers
	domain), user-to-network (from end system into the network, ending,		domain), user-to-network (from end system into the network, ending,
	e.g., at the entry to the network and vice versa), network-to-		e.g., at the entry to the network and vice versa), network-to-
	network (e.g., between providers).		network (e.g., between providers).
	Placing the QoS controller and initiator functions at different		Placing the QoS controller and initiator functions at different
	locations allows for various scenarios to work with the same or		locations allows for various scenarios to work with the same or
	similar protocols.		similar protocols.
	5.2.2
	No constraint of the QoS signaling and QoS Controllers to be in		5.2.2 No constraint of the QoS signaling and QoS Controllers to be in
	the data path.		the data path.
	There is a set of scenarios, where QoS signaling is not on the data		There is a set of scenarios, where QoS signaling is not on the data
	path. The QoS Controller being in the data path is one extreme case		path. The QoS Controller being in the data path is one extreme case
	and useful in certain cases.		and useful in certain cases.
	There are going to be cases where a centralized entity will take a		There are going to be cases where a centralized entity will take a
	decision about QoS requests. In this case, there's no question there		decision about QoS requests. In this case, there's no question there
	is no need to have data follow the signalling path.		is no need to have data follow the signalling path.
	There are going to be cases wiout a centralized entity managing		There are going to be cases wiout a centralized entity managing
	resources and the signaling will be used as a tool for resource		resources and the signaling will be used as a tool for resource
	management. For various reasons (such as efficient use of expensive		management. For various reasons (such as efficient use of expensive
	bandwidth), one will want to have fine-grained, fast, and very		bandwidth), one will want to have fine-grained, fast, and very
	dynamic control of the resources in the network. -		dynamic control of the resources in the network. -
	There are going to be cases where there will be neither signaling		There are going to be cases where there will be neither signaling
	nor a centralized entity (overprovisioning). Nothing has to be done		nor a centralized entity (overprovisioning). Nothing has to be done
	anyway.		anyway.
	One can capture the requirement with the following wording: If one		One can capture the requirement with the following wording: If one
	views the domain with a QoS technology as a virtual router then NSIS		views the domain with a QoS technology as a virtual router then NSIS
	signaling used between those virtual routers must follow the same		signaling used between those virtual routers must follow the same
	path as the data.		path as the data.
	Routing the signaling protocol along an independent path is desired		Routing the signaling protocol along an independent path is desired
	by network operators/designers. Ideally, the capability to route the		by network operators/designers. Ideally, the capability to route the
	protocol along an independent path would give the network		protocol along an independent path would give the network
	designer/operator the option to manage bandwidth utilization through		designer/operator the option to manage bandwidth utilization through
	the topology.		the topology.
	There are other possibilities as well. An NSIS protocol must accept		There are other possibilities as well. An NSIS protocol must accept
	all of these possibilities.		all of these possibilities.
	5.2.3
	Concealment of topology and technology information		5.2.3 Concealment of topology and technology information
	The QoS protocol should allow hiding the internal structure of a QoS		The QoS protocol should allow hiding the internal structure of a QoS
	domain from end-nodes and from other networks. Hence an adversary		domain from end-nodes and from other networks. Hence an adversary
	should not be able to learn the internal structure of a network with		should not be able to learn the internal structure of a network with
	the help of the QoS protocol.		the help of the QoS protocol.
	In various scenarios, topology information should be hidden for		In various scenarios, topology information should be hidden for
	various reasons. From a business point of view, some administrations		various reasons. From a business point of view, some administrations
	don't want to reveal the topology and technology used.		don't want to reveal the topology and technology used.
	5.2.4
	Optional transparency of QoS signaling to network		5.2.4 Optional transparency of QoS signaling to network
	It should be possible that the QoS signaling for some flows traverse		It should be possible that the QoS signaling for some flows traverse
	path segments transparently, i.e., without interpretation at QoS		path segments transparently, i.e., without interpretation at QoS
	controllers within the network. An example would be a subdomain		controllers within the network. An example would be a subdomain
	within a core network, which only interpreted signaling for		within a core network, which only interpreted signaling for
	aggregates established at the domain edge, with the flow-related		aggregates established at the domain edge, with the flow-related
	signaling passing transparently through it.		signaling passing transparently through it.
	5.3 Additional information beyond signaling of QoS information		5.3 Additional information beyond signaling of QoS information
	This section contains the desired signaling (messages) for other		This section contains the desired signaling (messages) for other
	purposes other than that for conveying QoS parameters.		purposes other than that for conveying QoS parameters.
	5.3.1
	Explicit release of resources		5.3.1 Explicit release of resources
	When a QoS reservation is no longer necessary, e.g. because the		When a QoS reservation is no longer necessary, e.g. because the
	application terminates, or because a mobile host experienced a hand-		application terminates, or because a mobile host experienced a hand-
	off, it must be possible to explicitly release resources.		off, it must be possible to explicitly release resources.
	5.3.2
	Possibility for automatic release of resources after failure		5.3.2 Possibility for automatic release of resources after failure
	When the QoS Initiator goes down, the resources it requested should
	be released, since they will no longer be necessary.		When the QoS Initiator goes down, the resources it requested in the
	5.3.3		network should be released, since they will no longer be necessary.
	Possibility for automatic re-setup of resources after recovery
			After detection of a failure in the network, any QoS
			controller/initiator must be able to release a reservation it is
			involved in. For example, this may require signaling of the "Release
			after Failure" message upstream as well as downstream, or soft state
			timing out of reservations.
			Note that this might need to work together with a notification
			mechanism.
			5.3.3 Possibility for automatic re-setup of resources after recovery
	In case of a failure, the reservation can get setup again		In case of a failure, the reservation can get setup again
	automatically. It enables sort of a persistent reservation, if the		automatically. It enables sort of a persistent reservation, if the
	QoS Initiator requests it. In scenarios where the reservations are		QoS Initiator requests it. In scenarios where the reservations are
	on a longer time scale, this could make sense to reduce the		on a longer time scale, this could make sense to reduce the
	signaling load in case of failure and recovery.		signaling load in case of failure and recovery.
	5.3.4
	Prompt notification of QoS violation in case of error / failure to		5.3.4 Prompt notification of QoS violation in case of error/failure to
	QoS Initiator and QoS Controllers		QoS Initiator and QoS Controllers
	5.3.5
	Feedback about success of request for QoS guarantees		QoS Controllers should be able to notify the QoS Initiator, if there
			is an error inside the network. There are two types of network
			errors:
			Recoverable errors: This type error can be locally repaired by the
			network nodes. The network nodes do not have to notify the users of
			the error immediately. This is a condition when the danger of
			degradation (or actual short term degradation) of the provided QoS
			was overcome by the network (QoS controller) itself.
			Unrecoverable errors: the network nodes cannot handle this type of
			error, and have to notify the users as soon as possible.
			5.3.5 Feedback about success of request for QoS guarantees
	A request for QoS must be answered at least with yes or no. However,		A request for QoS must be answered at least with yes or no. However,
	it might be useful in case of a negative answer to also get a		it might be useful in case of a negative answer to also get a
	description of what might be the QoS one can successfully request		description of what might be the QoS one can successfully request
	etc. So it might be useful to include an opaque element into the		etc. So it might be useful to include an opaque element into the
	answer. The element heavily depends on the service requested.		answer. The element heavily depends on the service requested.
			5.3.6 Allow local QoS information exchange between nodes of the same
			administrative domain
			The QoS signaling protocol must be able to exchange local QoS
			information between QoS controllers located within one single
			domain. Local QoS information might, for example, be IP addresses,
			severe congestion notification, notification of successful or
			erroneous processing of QoS signaling messages.
			In some cases, the NSIS QoS signalling protocol may carry
			identification of the QoS controllers located at the boundaries of a
			domain. However, the identification of edge should not be visible to
			the end host (QoS initiator) and only applies within one QoS
			administrative domain.
	5.4 Layering		5.4 Layering
	This section contains requirements related to the way the signaling		This section contains requirements related to the way the signaling
	being considered interacts with upper layer functions (users,		being considered interacts with upper layer functions (users,
	applications, and QoS administration), and lower layer QoS		applications, and QoS administration), and lower layer QoS
	technologies.		technologies.
	5.4.1
	The signaling protocol and QoS control information should be		5.4.1 The signaling protocol and QoS control information should be
	application independent.		application independent.
	However, opaque application information might get transported in the		However, opaque application information might get transported in the
	signaling message, without being handled in the network. Development		signaling message, without being handled in the network. Development
	and deployment of new applications should be possible without		and deployment of new applications should be possible without
	impacting the network infrastructure. Additionally, QoS protocols		impacting the network infrastructure. Additionally, QoS protocols
	are expected to conform to the Internet principles.		are expected to conform to the Internet principles.
	5.5 QoS Control Information		5.5 QoS Control Information
	This section contains requirements related to the QoS control		This section contains requirements related to the QoS control
	information that needs to be exchanged.		information that needs to be exchanged.
	5.5.1
	Mutability information on parameters		5.5.1 Mutability information on parameters
	It should be possible for the initiator to control the mutability of		It should be possible for the initiator to control the mutability of
	the QSC information. This prevents from being changed in a non-		the QSC information. This prevents from being changed in a non-
	recoverable way. The initiator should be able to control what is		recoverable way. The initiator should be able to control what is
	requested end to end, without the request being gradually mutated as		requested end to end, without the request being gradually mutated as
	it passes through a sequence of domains. This implies that in case		it passes through a sequence of domains. This implies that in case
	of changes made on the parameters, the original requested ones must		of changes made on the parameters, the original requested ones must
	still be available.		still be available.
	Note that we do not require anything about particular QoS paramters		Note that we do not require anything about particular QoS paramters
	being changed.		being changed.
	5.5.2
	Possibility to add and remove local domain information		5.5.2 Possibility to add and remove local domain information
	It should be possible for the QoS control functions to add and		It should be possible for the QoS control functions to add and
	remove local scope elements. E.g., at the entrance to a QoS domain		remove local scope elements. E.g., at the entrance to a QoS domain
	domain-specific information is added, which is used in this domain		domain-specific information is added, which is used in this domain
	only, and the information is removed again when a signaling message		only, and the information is removed again when a signaling message
	leaves the domain. The motivation is in the economy of re-use the		leaves the domain. The motivation is in the economy of re-use the
	protocol for domain internal signaling of various information. Where		protocol for domain internal signaling of various information. Where
	additional information is needed for QoS control within a particular		additional information is needed for QoS control within a particular
	domain, it should be possible to carry this at the same time as the		domain, it should be possible to carry this at the same time as the
	'end to end' information.)		'end to end' information.)
	5.5.3
	Independence of reservation identifier		5.5.3 Independence of reservation identifier
	A reservation identifier must be used, which is independent of the		A reservation identifier must be used, which is independent of the
	flow identifier, the IP address of the QoS Initiator, and the flow		flow identifier, the IP address of the QoS Initiator, and the flow
	end-points. Various scenarios in the mobility area require this		end-points. Various scenarios in the mobility area require this
	independence because flows resulting from handoff might have changed		independence because flows resulting from handoff might have changed
	end-points etc. but still have the same QoS requirement.		end-points etc. but still have the same QoS requirement.
	5.5.4
	Seamless modification of already reserved QoS		5.5.4 Seamless modification of already reserved QoS
	In many case, the reservation needs to be updated (up or downgrade).		In many case, the reservation needs to be updated (up or downgrade).
	This must happen seamlessly without service interruption. At least		This must happen seamlessly without service interruption. At least
	the signaling protocol must allow for it, even if some data path		the signaling protocol must allow for it, even if some data path
	elements might not be capable of doing so.		elements might not be capable of doing so.
	5.5.5
	Signaling must support quantitative, qualitative, and relative QoS		5.5.5 Signaling must support quantitative, qualitative, and relative
	specifications		QoS specifications
	5.6 Performance		5.6 Performance
	This section discusses performance requirements and evaluation		This section discusses performance requirements and evaluation
	criteria and the way in which these could and should be traded off		criteria and the way in which these could and should be traded off
	against each other in various parts of the solution.		against each other in various parts of the solution.
	Scalability is a must anyway. However, depending on the scenario the		Scalability is a must anyway. However, depending on the scenario the
	question to which extends the protocol must be scalable.		question to which extends the protocol must be scalable.
	5.6.1		5.6.1 Scalability in the number of messages received by a signaling
	Scalability in the number of messages received by a signaling
	communication partner (QoS initiator and controller)		communication partner (QoS initiator and controller)
	5.6.2
	Scalability in number of hand-offs		5.6.2 Scalability in number of hand-offs
	5.6.3
	Scalability in the number of interactions for setting up a		5.6.3 Scalability in the number of interactions for setting up a
	reservation		reservation
	5.6.4
	Scalability in the number of state per entity (QoS initiators and		5.6.4 Scalability in the number of state per entity (QoS initiators and
	QoS controllers)		QoS controllers)
	5.6.5
	Scalability in CPU use (end terminal and intermediate nodes)		5.6.5 Scalability in CPU use (end terminal and intermediate nodes)
	5.6.6
	Low latency in setup		5.6.6 Low latency in setup
	Low latency is only needed in scenarios, where reservations are in a		Low latency is only needed in scenarios, where reservations are in a
	short time scale (e.g. mobile environments), or where human		short time scale (e.g. handover in mobile environments), or where
	interaction is immediately concerned (e.g., voice communication		human interaction is immediately concerned (e.g., voice
	setup delay)		communication setup delay)
	5.6.7
	Allow for low bandwidth consumption for signaling protocol		5.6.7 Allow for low bandwidth consumption for signaling protocol
	Again only small sets of scenarios call for low bandwidth, mainly		Again only small sets of scenarios call for low bandwidth, mainly
	those where wireless links are involved.		those where wireless links are involved.
	Note that many of the performance issues are heavily dependent on		Note that many of the performance issues are heavily dependent on
	the scenario assumed and are normally a trade-off between speed,		the scenario assumed and are normally a trade-off between speed,
	reliability, complexity, and scalability. The trade-off varies in		reliability, complexity, and scalability. The trade-off varies in
	different parts of the network. For example, in radio access		different parts of the network. For example, in radio access
	networks low bandwidth consumption will overweight the low latency		networks low bandwidth consumption will overweight the low latency
	requirement, while in core networks it may be reverse.		requirement, while in core networks it may be reverse.
	5.6.8
	Ability to constrain load on devices		5.6.8 Ability to constrain load on devices
	The NSIS architecture should give the ability to constrain the load		The NSIS architecture should give the ability to constrain the load
	(CPU load, memory space, signaling bandwidth consumption and		(CPU load, memory space, signaling bandwidth consumption and
	signaling intensity) on devices where it is needed. This can be		signaling intensity) on devices where it is needed. One of the
	achieved by many different methods, for example message aggregation,		reasons is that the protocol handling should have a minimal impact
	by ignoring signaling message, header compression or minimizing		on interior (core) nodes.
	functionality. The architecture may choose any of these methods as
	long as the requirement is met.		This can be achieved by many different methods. Examples, and this
			are only examples, include message aggregation, by ignoring
			signaling message, header compression, or minimizing functionality.
			The framework may choose any method as long as the requirement is
			met.
			5.6.9 Highest possible network utilization
			There are networking environments that require high network
			utilization for various reasons, and the signaling protocol should
			to its best ability support high resource utilization while
			maintaining appropriate QoS.
			In networks where resources are very expensive (as is the case for
			many wireless networks), efficient network utilization is of
			critical financial importance. On the other hand there are other
			parts of the network where high utilization is not required.
	5.7 Flexibility		5.7 Flexibility
	This section lists the various ways the protocol can flexibly be		This section lists the various ways the protocol can flexibly be
	employed.		employed.
	5.7.1
	Aggregation capability, including the capability to select and		5.7.1 Aggregation capability, including the capability to select and
	change the level of aggregation.		change the level of aggregation.
	5.7.2
	Flexibility in the placement of the QoS initiator		5.7.2 Flexibility in the placement of the QoS initiator
	It might be the sender or the receiver of content. But also network-		It might be the sender or the receiver of content. But also network-
	initiated reservations are required in various scenarios.		initiated reservations are required in various scenarios.
	5.7.3
	Flexibility in the initiation of re-negotiation (QoS change		5.7.3 Flexibility in the initiation of re-negotiation (QoS change
	requests)		requests)
	Again the sender or the receiver of content might initiate a re-		Again the sender or the receiver of content might initiate a re-
	negotiation due to various reasons, such as local resource shortage		negotiation due to various reasons, such as local resource shortage
	(CPU, memory on end-system) or a user changed application		(CPU, memory on end-system) or a user changed application
	preference/profiles. But also network-initiated re-negotiation is		preference/profiles. But also network-initiated re-negotiation is
	required in cases, where the network is not able to further		required in cases, where the network is not able to further
	guarantee resources etc.		guarantee resources etc.
	5.7.4
	Uni / bi-directional reservation		5.7.4 Uni / bi-directional reservation
	Both uni-directonal as well as bi-direction reservations must be		Both uni-directonal as well as bi-direction reservations must be
	possible.		possible.
	5.8 Security		5.8 Security
	This section discusses security-related requirements. First a list		This section discusses security-related requirements. First a list
	of security threats is given.		of security threats is given.
	5.8.1
	The QoS protocol must provide strong authentication		5.8.1 The QoS protocol must provide strong authentication
	A QoS protocol must make provision for enabling various entities to		A QoS protocol must make provision for enabling various entities to
	be authenticated against each other using data origin and/or entity		be authenticated against each other using data origin and/or entity
	authentication. The QoS protocol must enable mutual authentication		authentication. The QoS protocol must enable mutual authentication
	between the two communicating entities. The term strong		between the two communicating entities. The term strong
	authentication points to the fact that weak plain-text password		authentication points to the fact that weak plain-text password
	mechanisms must not be used for authentication.		mechanisms must not be used for authentication.
	5.8.2
	The QoS protocol must provide means to authorize resource requests		5.8.2 The QoS protocol must provide means to authorize resource
			requests
	This requirement demands a hook to interact with a policy entity to		This requirement demands a hook to interact with a policy entity to
	request authorization data. This allows an authenticated entity to		request authorization data. This allows an authenticated entity to
	be associated with authorization data and to verify the resource		be associated with authorization data and to verify the resource
	request. Authorization prevents reservations by unauthorized		request. Authorization prevents reservations by unauthorized
	entities, reservations violating policies, theft of service and		entities, reservations violating policies, theft of service and
	additionally limits denial of service attacks against parts of the		additionally limits denial of service attacks against parts of the
	network or the entire network. Additionally it might be helpful to		network or the entire network. Additionally it might be helpful to
	provide some means to inform other protocols of participating nodes		provide some means to inform other protocols of participating nodes
	within the same administrative domain about a previous successful		within the same administrative domain about a previous successful
	authorization event.		authorization event.
	5.8.3
	The QoS signaling messages must provide integrity protection.		5.8.3 The QoS signaling messages must provide integrity protection.
	The integrity protection of the transmitted signaling messages		The integrity protection of the transmitted signaling messages
	prevent an adversary from modifying parts of the QoS signaling		prevent an adversary from modifying parts of the QoS signaling
	message and from mounting denial of service attacks against network		message and from mounting denial of service attacks against network
	elements participating in the QoS protocol.		elements participating in the QoS protocol.
	5.8.4		5.8.4 The QoS signaling messages must be replay protected.
	The QoS signaling messages must be replay protected.
	To prevent replay of previous signaling messages the QoS protocol		To prevent replay of previous signaling messages the QoS protocol
	must provide means to detect old messages. A solution must cover		must provide means to detect old messages. A solution must cover
	issues of synchronization problems in the case of a restart or a		issues of synchronization problems in the case of a restart or a
	crash of a participating network element. The use of replay		crash of a participating network element. The use of replay
	mechanism apart from sequence numbers should be investigated.		mechanism apart from sequence numbers should be investigated.
	5.8.5
	The QoS signaling protocol must allow for hop-by-hop security.		5.8.5 The QoS signaling protocol must allow for hop-by-hop security.
	Hop-by-Hop security is a well known and proven concept in QoS		Hop-by-Hop security is a well known and proven concept in QoS
	protocols that allows intermediate nodes that actively participate		protocols that allows intermediate nodes that actively participate
	in the QoS protocol to modify the messages as required by the QoS		in the QoS protocol to modify the messages as required by the QoS
	processing. Note that this requirement does not exclude end-to-end		processing. Note that this requirement does not exclude end-to-end
	or network-to-network security of a QoS reservation request. End-to-		or network-to-network security of a QoS reservation request. End-to-
	end security between the initiator and the responder may be used to		end security between the initiator and the responder may be used to
	provide protection of non-mutable data fields. Network-to-network		provide protection of non-mutable data fields. Network-to-network
	security refers to the protection of messages over various hops but		security refers to the protection of messages over various hops but
	not in an end-to-end manner i.e. protected over a particular		not in an end-to-end manner i.e. protected over a particular
	network.		network.
	5.8.6
	The QoS protocol should allow identity confidentiality and		5.8.6 The QoS protocol should allow identity confidentiality and
	location privacy.		location privacy.
	Identity confidentiality enables privacy and avoids profiling of		Identity confidentiality enables privacy and avoids profiling of
	entities by adversary eavesdropping the signaling traffic along the		entities by adversary eavesdropping the signaling traffic along the
	path. The identity used in the process of authentication may also be		path. The identity used in the process of authentication may also be
	hidden to a limited extent from a network to which the initiator is		hidden to a limited extent from a network to which the initiator is
	attached. It is however required that the identity provide enough		attached. It is however required that the identity provide enough
	information for the access network to collect accounting data.		information for the access network to collect accounting data.
	Location privacy is an issue for the initiator who triggers the QoS		Location privacy is an issue for the initiator who triggers the QoS
	protocol. In some scenarios the initiator may not be willing to		protocol. In some scenarios the initiator may not be willing to
	reveal location information to the responder.		reveal location information to the responder.
	5.8.7
	The QoS protocol should prevent denial-of-service attacks against		5.8.7 The QoS protocol should prevent denial-of-service attacks against
	signaling entities.		signaling entities.
	To effectively prevent denial-of-service attacks the QoS protocol		To effectively prevent denial-of-service attacks the QoS protocol
	and the used security mechanisms should not force to do heavy		and the used security mechanisms should not force to do heavy
	computation to verify a resource request prior authenticating the		computation to verify a resource request prior authenticating the
	requesting entity. Additionally the QoS protocol and the used		requesting entity. Additionally the QoS protocol and the used
	security mechanisms should not require large resource consumption		security mechanisms should not require large resource consumption
	(for example main memory or other additional message exchanges)		(for example main memory or other additional message exchanges)
	before a successful authentication was done.		before a successful authentication was done.
	5.8.8
	The QoS protocol should support confidentiality of signaling		5.8.8 The QoS protocol should support confidentiality of signaling
	messages.		messages.
	Based on the signaling information exchanged between nodes		Based on the signaling information exchanged between nodes
	participating in the QoS protocol an adversary may learn both the		participating in the QoS protocol an adversary may learn both the
	identities and the content of the QoS messages. To prevent this from		identities and the content of the QoS messages. To prevent this from
	happening, confidentiality of the QoS requests in a hop-by-hop		happening, confidentiality of the QoS requests in a hop-by-hop
	manner should be provided. Note that hop-by-hop is always required		manner should be provided. Note that hop-by-hop is always required
	whenever entities actively participating in the protocol must be		whenever entities actively participating in the protocol must be
	able to read and eventually modify the content of the QoS messages.		able to read and eventually modify the content of the QoS messages.
	This does not exclude the case where one or more network elements		This does not exclude the case where one or more network elements
	are not required to read the information of the transmitted QoS		are not required to read the information of the transmitted QoS
	messages.		messages.
	5.8.9
	The QoS protocol should provide hooks to interact with protocols		5.8.9 The QoS protocol should provide hooks to interact with protocols
	that allow the negotiation of authentication and key management		that allow the negotiation of authentication and key management
	protocols.		protocols.
	The negotiation of an authentication and key management protocols		The negotiation of an authentication and key management protocols
	within the QoS protocol is outside the scope of the QoS protocol.		within the QoS protocol is outside the scope of the QoS protocol.
	This requirement originates from the fact that more than one key		This requirement originates from the fact that more than one key
	management protocol may be used to provide security associations. So		management protocol may be used to provide security associations. So
	both entities must be capable to use the same protocol which may be		both entities must be capable to use the same protocol which may be
	difficult in a mobile environment with different requirements and		difficult in a mobile environment with different requirements and
	different protocols. The goal of such a negotiation step is to		different protocols. The goal of such a negotiation step is to
	determine which authentication and key management protocol to use is		determine which authentication and key management protocol to use is
	executed prior to the execution of the chosen key management		executed prior to the execution of the chosen key management
	protocol. The used key management protocol must however be able to		protocol. The used key management protocol must however be able to
	create a security association that matches with the one used in the		create a security association that matches with the one used in the
	QoS protocol. A QoS protocol should however provide a way to		QoS protocol. A QoS protocol should however provide a way to
	interact with these negotiation protocols.		interact with these negotiation protocols.
	5.8.10 The QoS protocol should provide means to interact with key
			5.8.10 The QoS protocol should provide means to interact with key
	management protocols		management protocols
	Key management protocols typically require a larger number of		Key management protocols typically require a larger number of
	messages to be transmitted to allow a session key and the		messages to be transmitted to allow a session key and the
	corresponding security association to be derived. To avoid the		corresponding security association to be derived. To avoid the
	complex issue of mapping individual authentication and key		complex issue of mapping individual authentication and key
	management protocols to a QoS protocol such a protocol is outside		management protocols to a QoS protocol such a protocol is outside
	the scope of the QoS protocol. Although the key management protocol		the scope of the QoS protocol. Although the key management protocol
	may be independent there must be a way for the QoS protocol to		may be independent there must be a way for the QoS protocol to
	exploit existing security associations to avoid executing a separate		exploit existing security associations to avoid executing a separate
	key management protocol (or instance of the same protocol) for		key management protocol (or instance of the same protocol) for
	skipping to change at page 19, line 40 ¶		skipping to change at page 20, line 17 ¶
	complex issue of mapping individual authentication and key		complex issue of mapping individual authentication and key
	management protocols to a QoS protocol such a protocol is outside		management protocols to a QoS protocol such a protocol is outside
	the scope of the QoS protocol. Although the key management protocol		the scope of the QoS protocol. Although the key management protocol
	may be independent there must be a way for the QoS protocol to		may be independent there must be a way for the QoS protocol to
	exploit existing security associations to avoid executing a separate		exploit existing security associations to avoid executing a separate
	key management protocol (or instance of the same protocol) for		key management protocol (or instance of the same protocol) for
	protocols that closely operate together. If no such security		protocols that closely operate together. If no such security
	association exists then there should be means for the QoS protocol		association exists then there should be means for the QoS protocol
	to trigger a key management protocol to dynamically create the		to trigger a key management protocol to dynamically create the
	required security associations.		required security associations.
	5.9 Mobility		5.9 Mobility
			5.9.1 Allow efficient QoS re-establishment after handover
			Handover is an essential function in wireless networks. After
			handover, QoS may need to be completely or partially re-established
			due to route changes. The re-establishment may be requested by the
			mobile node itself or triggered by the access point that the mobile
			node is attached to. In the first case, the QoS signalling should
			allow efficient QoS re-establishment after handover. Re-
			establishment of QoS after handover should be as quick as possible
			so that the mobile node does not experience service interruption or
			QoS degradation. The re-establishment should be localized, and not
			require end-to-end signalling, if possible.
	TBD		TBD
	5.10 Interworking with other protocols and techniques		5.10 Interworking with other protocols and techniques
	Hooks must be provided to enable efficient interworking between		Hooks must be provided to enable efficient interworking between
	various protocols and techniques including:		various protocols and techniques including:
	5.10.1 Interworking with IP tunneling
			5.10.1 Interworking with IP tunneling
	IP tunneling for various applications must be supported. More		IP tunneling for various applications must be supported. More
	specifically tunneling for IPSec tunnels are of importance. This		specifically tunneling for IPSec tunnels are of importance. This
	mainly impacts the identification of flows. Additionally, care needs		mainly impacts the identification of flows. Additionally, care needs
	to be taken using IPSec for signaling message.		to be taken using IPSec for signaling message.
	5.10.2 The solution should not constrain either to IPv4 or IPv6
	5.10.3 Independence from charging model		5.10.2 The solution should not constrain either to IPv4 or IPv6
			5.10.3 Independence from charging model
	Signaling must not be constrained by charging models or the charging		Signaling must not be constrained by charging models or the charging
	infrastructure used. However, the end-system should be able to query		infrastructure used. However, the end-system should be able to query
	current pay statistics and to specify user cost functions.		current pay statistics and to specify user cost functions.
	5.10.4 The QoS protocol should provide hooks for AAA protocols
			5.10.4 The QoS protocol should provide hooks for AAA protocols
	The security mechanism should be developed with respect to be able		The security mechanism should be developed with respect to be able
	to collect usage records from one or more network elements.		to collect usage records from one or more network elements.
	5.11 Operational		5.11 Operational
	5.11.1 Ability to assign transport quality to signaling messages
			5.11.1 Ability to assign transport quality to signaling messages
	The NSIS architecture should allow the network operator to assign		The NSIS architecture should allow the network operator to assign
	the NSIS protocol messages a certain transport quality. As signaling		the NSIS protocol messages a certain transport quality. As signaling
	opens up for possible denial-of-service attacks, this requirement		opens up for possible denial-of-service attacks, this requirement
	gives the network operator a mean, but also the obligation, to		gives the network operator a mean, but also the obligation, to
	trade-off between signaling latency and the impact (from the		trade-off between signaling latency and the impact (from the
	signaling messages) on devices within his/her network. From protocol		signaling messages) on devices within his/her network. From protocol
	design this requirement states that the protocol messages should be		design this requirement states that the protocol messages should be
	detectable, at least where the control and assignment of the		detectable, at least where the control and assignment of the
	messages priority is done.		messages priority is done.
	6 The MUSTs, SHOULDs, and MAYs		6 The MUSTs, SHOULDs, and MAYs
	In order to prioritize the various requirements from Section 5, we		In order to prioritize the various requirements from Section 5, we
	define different 'parts of the network'. In the different parts of		define different 'parts of the network'. In the different parts of
	the network a particular requirement might have a different		the network a particular requirement might have a different
	priority.		priority.
	The parts of the networks we differentiate are the host-to-first		The parts of the networks we differentiate are the host-to-first
	router, the access network, and the core network. The host to first		router, the access network, and the core network. The host to first
	router part includes all the layer 2 technologies to access to the		router part includes all the layer 2 technologies to access to the
	Internet. In many cases, there is an application and/or user running		Internet. In many cases, there is an application and/or user running
	on the host initiating QoS signaling. The access network can be		on the host initiating QoS signaling. The access network can be
	characterized by low capacity links, meadium speed IP processing		characterized by low capacity links, meadium speed IP processing
	capabilities, and it might consist of a complete layer 2 network as		capabilities, and it might consist of a complete layer 2 network as
	well. The core network characteristics include high-speed forwarding		well. The core network characteristics include high-speed forwarding
	capacities and interdomain QoS issues. All of them are not strictly		capacities and interdomain QoS issues. All of them are not strictly
	defined and should not be regarded as that, but should give a		defined and should not be regarded as that, but should give a
	skipping to change at page 20, line 42 ¶		skipping to change at page 21, line 39 ¶
	router part includes all the layer 2 technologies to access to the		router part includes all the layer 2 technologies to access to the
	Internet. In many cases, there is an application and/or user running		Internet. In many cases, there is an application and/or user running
	on the host initiating QoS signaling. The access network can be		on the host initiating QoS signaling. The access network can be
	characterized by low capacity links, meadium speed IP processing		characterized by low capacity links, meadium speed IP processing
	capabilities, and it might consist of a complete layer 2 network as		capabilities, and it might consist of a complete layer 2 network as
	well. The core network characteristics include high-speed forwarding		well. The core network characteristics include high-speed forwarding
	capacities and interdomain QoS issues. All of them are not strictly		capacities and interdomain QoS issues. All of them are not strictly
	defined and should not be regarded as that, but should give a		defined and should not be regarded as that, but should give a
	feeling about where in the network we have different requirements		feeling about where in the network we have different requirements
	concerning QoS signaling.		concerning QoS signaling.
	Note that the requirement titles are listed for better reading.		Note that the requirement titles are listed for better reading.
	5.1 Architecture and Design Goals		5.1 Architecture and Design Goals
	5.1.1 Applicability for different QoS technologies.		5.1.1 Applicability for different QoS technologies.
	5.1.2 Resource availability information on request		5.1.2 Resource availability information on request
	5.1.3 Modularity		5.1.3 Modularity
	5.1.4 Decoupling of protocol and information it is carrying		5.1.4 Decoupling of protocol and information it is carrying
	5.1.5 Reuse of existing QoS provisioning		5.1.5 Reuse of existing QoS provisioning
	5.1.6 Avoid duplication of [sub]domain signaling functions		5.1.6 Independence of signaling and provisioning paradigm
	5.1.7 Independence of signaling and provisioning paradigm
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.1 | | | |		5.1.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.2 | | | |		5.1.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.3 | | | |		5.1.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.4 | | | |		5.1.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.5 | | | |		5.1.5 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.6 | | | |		5.1.6 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.1.7 | | | |
	----------------------+-------------+-------------+------------+
	5.2 Signaling Flows		5.2 Signaling Flows
	5.2.1 Free placement of QoS Initiator and QoS Controllers functions		5.2.1 Free placement of QoS Initiator and QoS Controllers functions
	5.2.2 No constraint of the QoS signaling and QoS Controllers to be		5.2.2 No constraint of the QoS signaling and QoS Controllers to be
	in the data path.		in the data path.
	5.2.3 Concealment of topology and technology information		5.2.3 Concealment of topology and technology information
	5.2.4 Optional transparency of QoS signaling to network		5.2.4 Optional transparency of QoS signaling to network
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.1 | | | |		5.2.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.2 | | | |		5.2.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.3 | | | |		5.2.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.4 | | | |		5.2.4 | | | |
	skipping to change at page 22, line 4 ¶		skipping to change at page 22, line 31 ¶
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.1 | | | |		5.2.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.2 | | | |		5.2.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.3 | | | |		5.2.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.2.4 | | | |		5.2.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3 Additional information beyond signaling of QoS information		5.3 Additional information beyond signaling of QoS information
	5.3.1 Explicit release of resources		5.3.1 Explicit release of resources
	5.3.2 Possibility for automatic release of resources after failure		5.3.2 Possibility for automatic release of resources after failure
	5.3.3 Possibility for automatic re-setup of resources after recovery		5.3.3 Possibility for automatic re-setup of resources after recovery
	5.3.4 Prompt notification of QoS violation in case of error /		5.3.4 Prompt notification of QoS violation in case of error /
	failure to QoS Initiator and QoS Controllers		failure to QoS Initiator and QoS Controllers
	5.3.5 Feedback about success of request for QoS guarantees		5.3.5 Feedback about success of request for QoS guarantees
			5.3.6 Allow local QoS information exchange between nodes of the same
			administrative domain
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3.1 | | | |		5.3.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3.2 | | | |		5.3.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3.3 | | | |		5.3.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3.4 | | | |		5.3.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.3.5 | | | |		5.3.5 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
			5.3.6 | | | |
			----------------------+-------------+-------------+------------+
	5.4 Layering		5.4 Layering
	5.4.1 The signaling protocol and QoS control information should be		5.4.1 The signaling protocol and QoS control information should be
	application independent.		application independent.
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.4.1 | | | |		5.4.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5 QoS Control Information		5.5 QoS Control Information
	5.5.1 Mutability information on parameters		5.5.1 Mutability information on parameters
	5.5.2 Possibility to add and remove local domain information		5.5.2 Possibility to add and remove local domain information
	5.5.3 Independence of reservation identifier		5.5.3 Independence of reservation identifier
	5.5.4 Seamless modification of already reserved QoS		5.5.4 Seamless modification of already reserved QoS
	5.5.5 Signaling must support quantitative, qualitative, and relative		5.5.5 Signaling must support quantitative, qualitative, and relative
	QoS specifications		QoS specifications
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.1 | | | |		5.5.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.2 | | | |		5.5.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.3 | | | |		5.5.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.4 | | | |		5.5.4 | | | |
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 37 ¶
	5.5.1 | | | |		5.5.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.2 | | | |		5.5.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.3 | | | |		5.5.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.4 | | | |		5.5.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.5.5 | | | |		5.5.5 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6 Performance		5.6 Performance
	5.6.1 Scalability in the number of messages received by a signaling		5.6.1 Scalability in the number of messages received by a signaling
	communication partner (QoS initiator and controller)		communication partner (QoS initiator and controller)
	5.6.2 Scalability in number of hand-offs		5.6.2 Scalability in number of hand-offs
	5.6.3 Scalability in the number of interactions for setting up a		5.6.3 Scalability in the number of interactions for setting up a
	reservation		reservation
	5.6.4 Scalability in the number of state per entity (QoS initiators		5.6.4 Scalability in the number of state per entity (QoS initiators
	and QoS controllers)		and QoS controllers)
	5.6.5 Scalability in CPU use (end terminal and intermediate nodes)		5.6.5 Scalability in CPU use (end terminal and intermediate nodes)
	5.6.6 Low latency in setup		5.6.6 Low latency in setup
	5.6.7 Allow for low bandwidth consumption for signaling protocol		5.6.7 Allow for low bandwidth consumption for signaling protocol
	5.6.8 Ability to constrain load on devices		5.6.8 Ability to constrain load on devices
			5.6.9 Highest possible network utilization
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.1 | | | |		5.6.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.2 | | | |		5.6.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.3 | | | |		5.6.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.4 | | | |		5.6.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.5 | | | |		5.6.5 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.6 | | | |		5.6.6 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.7 | | | |		5.6.7 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.6.8 | | | |		5.6.8 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
			5.6.9 | | | |
			----------------------+-------------+-------------+------------+
	5.7 Flexibility		5.7 Flexibility
	5.7.1 Aggregation capability, including the capability to select and		5.7.1 Aggregation capability, including the capability to select and
	change the level of aggregation.		change the level of aggregation.
	5.7.2 Flexibility in the placement of the QoS initiator		5.7.2 Flexibility in the placement of the QoS initiator
	5.7.3 Flexibility in the initiation of re-negotiation (QoS change		5.7.3 Flexibility in the initiation of re-negotiation (QoS change
	requests)		requests)
	5.7.4 Uni / bi-directional reservation		5.7.4 Uni / bi-directional reservation
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.7.1 | | | |		5.7.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.7.2 | | | |		5.7.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.7.3 | | | |		5.7.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.7.4 | | | |		5.7.4 | | | |
	skipping to change at page 24, line 45 ¶		skipping to change at page 25, line 34 ¶
	5.8.6 | | | |		5.8.6 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.8.7 | | | |		5.8.7 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.8.8 | | | |		5.8.8 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.8.9 | | | |		5.8.9 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.8.10 | | | |		5.8.10 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.9 Mobility		5.9 Mobility
			5.9.1 Allow efficient QoS re-establishment after handover
			----------------------+-------------+-------------+------------+
			| host-to-net | access | core |
			----------------------+-------------+-------------+------------+
			5.9.1 | | | |
			----------------------+-------------+-------------+------------+
	5.10 Interworking with other protocols and techniques		5.10 Interworking with other protocols and techniques
	5.10.1 Interworking with IP tunneling		5.10.1 Interworking with IP tunneling
	5.10.2 The solution should not constrain either to IPv4 or IPv6		5.10.2 The solution should not constrain either to IPv4 or IPv6
	5.10.3 Independence from charging model		5.10.3 Independence from charging model
	5.10.4 The QoS protocol should provide hooks for AAA protocols		5.10.4 The QoS protocol should provide hooks for AAA protocols
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.1 | | | |		5.10.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.2 | | | |		5.10.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.3 | | | |		5.10.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.4 | | | |		5.10.4 | | | |
	skipping to change at page 25, line 14 ¶		skipping to change at page 26, line 9 ¶
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.1 | | | |		5.10.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.2 | | | |		5.10.2 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.3 | | | |		5.10.3 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.10.4 | | | |		5.10.4 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.11 Operational		5.11 Operational
	5.11.1 Ability to assign transport quality to signaling messages		5.11.1 Ability to assign transport quality to signaling messages
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	| host-to-net | access | core |		| host-to-net | access | core |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	5.11.1 | | | |		5.11.1 | | | |
	----------------------+-------------+-------------+------------+		----------------------+-------------+-------------+------------+
	7 References		7 References
	[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem		[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
	Statement", RFC 3132, June 2001.		Statement", RFC 3132, June 2001.
	[2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",		[2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",
	draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,		draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,
	August 2001		August 2001
	[3] Manner. J., et al, "Mobility Related Terminology", draft-manner-		[3] Manner. J., et al, "Mobility Related Terminology", draft-manner-
	seamoby-terms-02.txt, Work In Progress, July 2001.		seamoby-terms-02.txt, Work In Progress, July 2001.
	[4] 3GPP, "General Packet Radio Service (GPRS); Service Description		[4] 3GPP, "General Packet Radio Service (GPRS); Service Description
	Stage 2 v 7.7.0", TS 03.60, June 2001		Stage 2 v 7.7.0", TS 03.60, June 2001
	[5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum		[5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum
	System, revision B", S.R0005-B, May 2001		System, revision B", S.R0005-B, May 2001
	[6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling		[6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling
	BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001		BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001
	[7] Partain, D., et al, "Resource Reservation Issues in Cellular		[7] Partain, D., et al, "Resource Reservation Issues in Cellular
	Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt,		Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt,
	Work in Progress, June 2001.		Work in Progress, June 2001.
	[8] YESSIR - YEt another Sender Session Internet Reservations,		[8] YESSIR - YEt another Sender Session Internet Reservations,
	h		http://www.cs.columbia.edupingpan/projects/yessir.html
	ttp://www.cs.columbia.edupingpan/projects/yessir.htm
	l
	[9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,		[9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional		"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", IETF RFC 2205, 1997.		Specification", IETF RFC 2205, 1997.
	[10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G.,		[10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G.,
	Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource		Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource
	Management in Diffserv Framework", Internet draft, work in progress,		Management in Diffserv Framework", Internet draft, work in progress,
	draft-westberg-rmd-framework-xx.txt, 2002.		draft-westberg-rmd-framework-xx.txt, 2002.
	[11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA		[11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA
	Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt,		Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt,
	Work in progress, September 2001.		Work in progress, September 2001.
	8 Appendix: Scenarios/Use cases		8 Appendix: Scenarios/Use cases
	In the following we describe scenarios, which are important to		In the following we describe scenarios, which are important to
	cover, and which allow us to discuss various requirements. Some		cover, and which allow us to discuss various requirements. Some
	regard this as use cases to be covered defining the use of a QoS		regard this as use cases to be covered defining the use of a QoS
	signaling protocol.		signaling protocol.
	8.1 Scenario: Terminal Mobility		8.1 Scenario: Terminal Mobility
	The scenario we are looking at is the case where a mobile terminal		The scenario we are looking at is the case where a mobile terminal
	(MT) changes from one access point to another access point. The		(MT) changes from one access point to another access point. The
	access points are located in separate QoS domains. We assume Mobile		access points are located in separate QoS domains. We assume Mobile
	IP to handle mobility on the network layer in this scenario and		IP to handle mobility on the network layer in this scenario and
	consider the various extensions (i.e., IETF proposals) to Mobile IP,		consider the various extensions (i.e., IETF proposals) to Mobile IP,
	in order to provide 'fast handover' for roaming Mobile Terminals.		in order to provide 'fast handover' for roaming Mobile Terminals.
	The goal to be achieved lies in providing, keeping, and adapting the		The goal to be achieved lies in providing, keeping, and adapting the
	requested QoS for the ongoing IP sessions in case of handover.		requested QoS for the ongoing IP sessions in case of handover.
	Furthermore, the negotiation of QoS parameters with the new domain		Furthermore, the negotiation of QoS parameters with the new domain
	via the old connection might be needed, in order to support the		via the old connection might be needed, in order to support the
	skipping to change at page 35, line 8 ¶		skipping to change at page 36, line 4 ¶
	At the edge router (i.e., border node), the flow is admitted, again		At the edge router (i.e., border node), the flow is admitted, again
	with an optional authentication process, possibly involving an		with an optional authentication process, possibly involving an
	external policy server. Note that the relationship between the PSTN		external policy server. Note that the relationship between the PSTN
	GW and the policy server and the routers and the policy server is		GW and the policy server and the routers and the policy server is
	outside the scope of NSIS. The edge router then admits the flow into		outside the scope of NSIS. The edge router then admits the flow into
	the core of the network, possibly using some aggregation technique.		the core of the network, possibly using some aggregation technique.
	At the interior nodes, the NSIS host-to-host signaling should either		At the interior nodes, the NSIS host-to-host signaling should either
	be ignored or invisible as the Edge router performed the admission		be ignored or invisible as the Edge router performed the admission
	control decision to some aggregate.		control decision to some aggregate.
	At the inter-provider router (i.e., border node), again the NSIS		At the inter-provider router (i.e., border node), again the NSIS
	host-to-host signaling should either be ignored or invisible as the		host-to-host signaling should either be ignored or invisible as the
	Edge router has performed an admission control decision about an		Edge router has performed an admission control decision about an
	aggregate across a carrier network.		aggregate across a carrier network.
	8.9 PSTN trunking gateway		8.9 PSTN trunking gateway
	One of the use cases for the NSIS signaling protocol is the scenario		One of the use cases for the NSIS signaling protocol is the scenario
	of interconnecting PSTN gateways with an IP network that supports		of interconnecting PSTN gateways with an IP network that supports
	QoS.		QoS.
	Four different scenarios are considered here.		Four different scenarios are considered here.
	1.		1. In-band QoS signaling is used. In this case the Media Gateway
	In-band QoS signaling is used. In this case the Media Gateway
	(MG) will be acting as the QoS Initiator and the Edge Router		(MG) will be acting as the QoS Initiator and the Edge Router
	(ER) will be the QoS Controller. Hence, the ER should do		(ER) will be the QoS Controller. Hence, the ER should do
	admission control (into pre-provisioned traffic trunks) for the		admission control (into pre-provisioned traffic trunks) for the
	individual traffic flows. This scenario is not further		individual traffic flows. This scenario is not further
	considered here.		considered here.
	2.		2. Out-of-band signaling in a single domain, the QoS Controller is
	Out-of-band signaling in a single domain, the QoS Controller is
	integrated in the MGC. In this case no NSIS protocol is		integrated in the MGC. In this case no NSIS protocol is
	required.		required.
	3.		3. Out-of-band signaling in a single domain, the QoS Controller is
	Out-of-band signaling in a single domain, the QoS Controller is
	a separate box. In this case NSIS signaling is used between the		a separate box. In this case NSIS signaling is used between the
	MGC and the QoS Controller.		MGC and the QoS Controller.
	4.		4. Out-of-band signaling between multiple domains, the QoS
	Out-of-band signaling between multiple domains, the QoS
	Controller (which may be integrated in the MGC) triggers the		Controller (which may be integrated in the MGC) triggers the
	QoS Controller of the next domain.		QoS Controller of the next domain.
	When the out-of-band QoS signaling is used the Media Gateway		When the out-of-band QoS signaling is used the Media Gateway
	Controller (MGC) will be acting as the QoS Initiator.		Controller (MGC) will be acting as the QoS Initiator.
	In the second scenario the voice provider manages a set of traffic		In the second scenario the voice provider manages a set of traffic
	trunks that are leased from a network provider. The MGC does the		trunks that are leased from a network provider. The MGC does the
	admission control in this case. Since the QoS Controller acts both		admission control in this case. Since the QoS Controller acts both
	as a QoS Initiator and a QoS Controller, no NSIS signaling is		as a QoS Initiator and a QoS Controller, no NSIS signaling is
	required. This scenario is shown in figure 1.		required. This scenario is shown in figure 1.
	+-------------+ ISUP/SIGTRAN +-----+ +-----+		+-------------+ ISUP/SIGTRAN +-----+ +-----+
	| SS7 network |---------------------| MGC |--------------| SS7 |		| SS7 network |---------------------| MGC |--------------| SS7 |
	+-------------+ +-------+-----+---------+ +-----+		+-------------+ +-------+-----+---------+ +-----+
	: / : \		: / : \
	: / : \		: / : \
	: / +--------:----------+ \		: / +--------:----------+ \
	: MEGACO / / : \ \		: MEGACO / / : \ \
	: / / +-----+ \ \		: / / +-----+ \ \
	: / / | NMS | \ \		: / / | NMS | \ \
	: / | +-----+ | \		: / | +-----+ | \
	skipping to change at page 37, line 17 ¶		skipping to change at page 38, line 17 ¶
	Quite a number of people have been involved in the discussion of the		Quite a number of people have been involved in the discussion of the
	draft, adding some ideas, requirements, etc. We list them without a		draft, adding some ideas, requirements, etc. We list them without a
	guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul		guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
	(NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas		(NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
	Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),		Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
	Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical		Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
	University Berlin), Xiaoming Fu (Technical University Berlin), Hans-		University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
	Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph		Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
	Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya		Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya
	Freytsis.		Freytsis.
	Some text and/or ideas for text, requirements, scenarios have been		Some text and/or ideas for text, requirements, scenarios have been
	taken from a draft written by the following authors: David Partain		taken from a draft written by the following authors: David Partain
	(Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia),		(Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia),
	Georgios Karagiannis (Ericsson), Jukka Manner (University of		Georgios Karagiannis (Ericsson), Jukka Manner (University of
	Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars		Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
	Westberg (Ericsson), Haihong Zheng (Nokia).		Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
			actively contributed new text to the draft as well.
			Another draft impacting this draft has been written by Sven Van den
			Bosch, Maarten Buchli, and Danny Goderis. These people contributed
			also with new text.
	10 Author's Addresses		10 Author's Addresses
	Marcus Brunner (Editor)		Marcus Brunner (Editor)
	NEC Europe Ltd.		NEC Europe Ltd.
	Network Laboratories		Network Laboratories
	Adenauerplatz 6		Adenauerplatz 6
	D-69115 Heidelberg		D-69115 Heidelberg
	Germany		Germany
	E-Mail: brunner@ccrle.nec.de (contact)		E-Mail: brunner@ccrle.nec.de (contact)
	Robert Hancock, Eleanor Hepworth		Robert Hancock, Eleanor Hepworth
	Roke Manor Research Ltd		Roke Manor Research Ltd
	Romsey, Hants, SO51 0ZN		Romsey, Hants, SO51 0ZN
	United Kingdom		United Kingdom
	E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk		E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk
	Cornelia Kappler		Cornelia Kappler
	Siemens AG		Siemens AG
	Berlin 13623		Berlin 13623
	Germany		Germany
	E-Mail: cornelia.kappler@icn.siemens.de		E-Mail: cornelia.kappler@icn.siemens.de
	Hannes Tschofenig		Hannes Tschofenig
	Siemens AG		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	81739 Munchen		81739 Munchen
	Germany		Germany
	Email: Hannes.Tschofenig@mchp.siemens.de		Email: Hannes.Tschofenig@mchp.siemens.de
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	skipping to change at page 38, line 26 ¶		skipping to change at page 39, line 27 ¶
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Open Issues/To Dos		Open Issues/To Dos
	1) (OPEN) add Scenarios		1) (OPEN) add Scenarios
	Do we need to add, remove, or change the scenarios?		Do we need to add, remove, or change the scenarios?
	- added scenario on QoS signalling between PSTN gateways and		- added scenario on QoS signalling between PSTN gateways and
	backbone routers		backbone routers
	- added: Application request end-to-end QoS path from the network		- added: Application request end-to-end QoS path from the network
	We can what ever scenario we want. The more the better to understand		We can what ever scenario we want. The more the better to understand
	the issues. Nevertheless, we have to take care that we are future		the issues. Nevertheless, we have to take care that we are future
	prove as well.		prove as well.
	2) (OPEN) Sender/receiver initiation		2) (OPEN) Sender/receiver initiation
	What is the requirement concerning data sender or data receiver or		What is the requirement concerning data sender or data receiver or
	both to initiate a QoS request.		both to initiate a QoS request.
	- does it matter who pays?
	- terminology text added		Terminology text added
	open issue, what is a potential req (currently we say "both must be		open issue, what is a potential req (currently we say "both must be
	possible")		possible")
			Proposals:
			1)should be optimized for sender initiated
			2) remove the requirement, because it is not relevant if we allow
			for third party QoS initiators
			3) SHOULD support sender initiated, MAY support reciever initiated
			Issues:
			- does it matter who pays?
			- for sender initiated, can we support implicit signaling
			(bundling the QoS requests with other signaling - registration,
			etc.)?
			- For reciever initiated, do we need protection against spamming -
			how do we protect against unwanted changes?
	3) (CLOSED) Draft organization		3) (CLOSED) Draft organization
	The proposed changes include		The proposed changes include
	- put all the scenarios into an appendix		- put all the scenarios into an appendix
	- In Section 6 add text describing 3 different "parts of the		- In Section 6 add text describing 3 different "parts of the
	network"		network"
	-Host to first hop		-Host to first hop
	-access network		-access network
	-core networks		-core networks
	better names are welcome, but I don't want to be religious about		better names are welcome, but I don't want to be religious about
	it		it
	- Prioritize the requirements according to the "parts of the		- Prioritize the requirements according to the "parts of the
	network" (This means the the tables in Section 6 of the current		network" (This means the the tables in Section 6 of the current
	draft will get three colums with the MUST, SHOULDs, and MAYs for		draft will get three colums with the MUST, SHOULDs, and MAYs for
	each requirement		each requirement
	4) (OPEN) MUSTs, SHOULDs, MAY needs discussion		4) (OPEN) MUSTs, SHOULDs, MAY needs discussion
	5) (CLOSED) Framework text.		5) (CLOSED) Framework text.
	The figures have been removed, because they seamed to be misleading.		The figures have been removed, because they seamed to be misleading.
	the text has been revisited. I regard the issue closed until we have		the text has been revisited. I regard the issue closed until we have
	a clear picture about what the NSIS framework draft is about.		a clear picture about what the NSIS framework draft is about.
	6) (CLOSED) The requirement organization		6) (CLOSED) The requirement organization
	I heard some voices on the list that the grouping should be more		I heard some voices on the list that the grouping should be more
	along the lines of host-to-edge, edge to edge etc.		along the lines of host-to-edge, edge to edge etc.
	So far I have not changed it, because I though that the requirements		So far I have not changed it, because I though that the requirements
	heavily depend on the scenario we are looking at.		heavily depend on the scenario we are looking at.
	closed, by the change in the draft organisation (issue 3)		closed, by the change in the draft organisation (issue 3)
	7) (OPEN) Hemant Chaskar: Section 3.1, items 1) Handoff decision and		7) (OPEN) Hemant Chaskar: Section 3.1, items 1) Handoff decision and
	2) Trigger sources: The handoff decision and trigger sources should		2) Trigger sources: The handoff decision and trigger sources should
	be out of scope of NSIS. NSIS should rather focus only on		be out of scope of NSIS. NSIS should rather focus only on
	"establishing" QoS along the packet path after handoff.		"establishing" QoS along the packet path after handoff.
	needs more WG discussion, potentially even cross-WG		needs more WG discussion, potentially even cross-WG
	8) (OPEN) bi-directional data path setup with one QoS request		8) (OPEN) bi-directional data path setup with one QoS request
	I have not seen consensus on whether to require bi-directional data		I have not seen consensus on whether to require bi-directional data
	path setup with QoS.		path setup with QoS.
	- How can we actually perform bi-directional reservations when the
			Q: How can we actually perform bi-directional reservations when the
	forward and reverse paths are not reciprocal, with respect to		forward and reverse paths are not reciprocal, with respect to
	routing topology and routing policy of network domains between		routing topology and routing policy of network domains between
	sender and receiver?		sender and receiver?
			A: bi-directional data path setup does not need to use the same
			return path as the forwarding path. The only requirement to achieve
			a bi-directional reservation is that the sender for the forwarding
			path is also the receiver for the return path and that the receiver
			for the forwarding path is also the sender for the return path.
	- The need to ensure that the return path is the same as the		- The need to ensure that the return path is the same as the
	forwarding path is one of the problems with RSVP, particularly in a		forwarding path is one of the problems with RSVP, particularly in a
	mobile environment.		mobile environment.
	9) (CLOSED) Potential requirement: must be implementable in user		9) (CLOSED) Potential requirement: must be implementable in user
	space (on end hosts)		space (on end hosts)
	has not been included in the req list because it seams to be		has not been included in the req list because it seams to be
	implementation specific.		implementation specific.
	10) (CLOSED) Potential requirement: must provide support for		10) (CLOSED) Potential requirement: must provide support for
	globally defined services as well as private services (Ruediger)		globally defined services as well as private services (Ruediger)
	replaced by issue 17 and 18, closed		replaced by issue 17 and 18, closed
	11) (CLOSED) Potential requirement: Flexibility in the granularity		11) (CLOSED) Potential requirement: Flexibility in the granularity
	of reservation (I don't remember who brought it up, but I assume it		of reservation (I don't remember who brought it up, but I assume it
	refers to the flexibility in terms of what size the flow has. Where		refers to the flexibility in terms of what size the flow has. Where
	size can be bandwidth etc.)		size can be bandwidth etc.)
	The assumption that QoS classes as well as service definitions are		The assumption that QoS classes as well as service definitions are
	out of scope for this draft, also the flexibility is.		out of scope for this draft, also the flexibility is.
	12) (CLOSED) text replacing scalability reqs		12) (CLOSED) text replacing scalability reqs
	"The nsis architecture should give the ability to constrain the load		"The nsis architecture should give the ability to constrain the load
	(CPU load, memory space, signaling bandwidth consumption and		(CPU load, memory space, signaling bandwidth consumption and
	signaling intensity) on devices where it is needed. This can be		signaling intensity) on devices where it is needed. This can be
	achieved by many different methods, for example message aggregation,		achieved by many different methods, for example message aggregation,
	by ignoring signaling message, header compression or minimizing		by ignoring signaling message, header compression or minimizing
	functionality. The architecture may choose any of these methods as		functionality. The architecture may choose any of these methods as
	long as the requirement is met."		long as the requirement is met."
	Editor: added the above text, but did not remove scalability reqs
			Editor: added the draft text, but did not remove scalability reqs
	13) (CLOSED) add operator req "Ability to assign transport quality		13) (CLOSED) add operator req "Ability to assign transport quality
	to signaling messages"		to signaling messages"
	"The nsis architecture should allow the network operator to assign		"The nsis architecture should allow the network operator to assign
	the nsis protocol messages a certain transport quality. As signaling		the nsis protocol messages a certain transport quality. As signaling
	opens up for possible denial-of-service attacks, this requirement		opens up for possible denial-of-service attacks, this requirement
	gives the network operator a mean, but also the obligation, to		gives the network operator a mean, but also the obligation, to
	trade-off between signaling latency and the impact (from the		trade-off between signaling latency and the impact (from the
	signaling messages) on devices within his/her network. From protocol		signaling messages) on devices within his/her network. From protocol
	design this requirement states that the protocol messages should be		design this requirement states that the protocol messages should be
	detectable, at least where the control and assignment of the		detectable, at least where the control and assignment of the
	skipping to change at page 40, line 42 ¶		skipping to change at page 42, line 22 ¶
	add "support grouping of microflows (possibly only for feedback)"		add "support grouping of microflows (possibly only for feedback)"
	"As a consequence of the optimization for the interactive multimedia		"As a consequence of the optimization for the interactive multimedia
	services, the signaling should allow one unique request for several		services, the signaling should allow one unique request for several
	micro flows having the same origination and destination IP		micro flows having the same origination and destination IP
	addresses. This is usually the case for multimedia SIP calls where		addresses. This is usually the case for multimedia SIP calls where
	the voice and video micro flows follow the same path. This grouping		the voice and video micro flows follow the same path. This grouping
	of requests allows optimization of the QoS processing. Note that		of requests allows optimization of the QoS processing. Note that
	this may be detrimental for the call setup time. The use of grouping		this may be detrimental for the call setup time. The use of grouping
	for microflows may be restricted to teardown and/or notification		for microflows may be restricted to teardown and/or notification
	messages when call setup time is a concern."		messages when call setup time is a concern."
	open issue: first resolve the bi-directional issue which is somewhat		open issue: first resolve the bi-directional issue which is somewhat
	related, because it seams to be an optimization as well		related, because it seams to be an optimization as well
			Should not be restrict to teardown and/or notification, it might be
			useful also for the procedure that refreshes reservation states
	15) (CLOSED) Support for preemption of sessions		15) (CLOSED) Support for preemption of sessions
	-might play into the fault/ error handling case		-might play into the fault/ error handling case
	-is regarded as service-specific, whether existing sessions can be		-is regarded as service-specific, whether existing sessions can be
	pre-empted		pre-empted
	Conclusion: it is network policy to determine how to do pre-emption,		Conclusion: it is network policy to determine how to do pre-emption,
	not a protocol issue.		not a protocol issue.
	16) (OPEN) Req: 5.1.9 change provisioning into better term, since		16) (OPEN) Req: 5.1.9 change provisioning into better term, since
	different people understand different thing with provisioning		different people understand different thing with provisioning
	open action for Anders		open action for Anders
	17) (CLOSED) add assumption that QoS classes/service definitions are		17) (CLOSED) add assumption that QoS classes/service definitions are
	already known to all the parties involved in signaling before hand		already known to all the parties involved in signaling before hand
	(before a signalling session even starts		(before a signalling session even starts
	added text in Section 4.1		added text in Section 4.1
	18) (CLOSED) add exclusion of methods, protocols, and ways to		18) (CLOSED) add exclusion of methods, protocols, and ways to
	express QoS		express QoS
	Even so, this might be covered by saying that we are independent of		Even so, this might be covered by saying that we are independent of
	QoS classes and service description etc. (see issue 17), I added two		QoS classes and service description etc. (see issue 17), I added two
	points to the exclusion Section 4.2.		points to the exclusion Section 4.2.
	Implications: issue 20, 23,		Implications: issue 20, 23,
	19) (CLOSED) remove req 5.2.5 IP fragmentation		19) (CLOSED) remove req 5.2.5 IP fragmentation
	20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a		20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a
	reservation		reservation
	is regarded service-specific therefore part of the service		is regarded service-specific therefore part of the service
	description		description
	added some reservation life time text service description assumption		added some reservation life time text service description assumption
	text and removed the req		text and removed the req
	21) (CLOSED) remove req 5.5.4 Aggregation method specification		21) (CLOSED) remove req 5.5.4 Aggregation method specification
	Concerns		Concerns
	-QI not able to know the impact of aggregation		-QI not able to know the impact of aggregation
	-to far down the implementation/ service definition road		-to far down the implementation/ service definition road
	-leave it to the provider how a service is realized		-leave it to the provider how a service is realized
	removed		removed
	22) (CLOSED) remove 5.3.7 Automatic notification on available		22) (CLOSED) remove 5.3.7 Automatic notification on available
	resources not been granted before		resources not been granted before
	regarded to complex and is heavily dependend on the service		regarded to complex and is heavily dependend on the service
	description		description
	removed		removed
	23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS		23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS
	provisioning parameters		provisioning parameters
	this heavily depends on service definition and therefore is out of		this heavily depends on service definition and therefore is out of
	scope of this document		scope of this document
	removed		removed
	24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually		24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually
	received level of QoS guarantees" with two requirements: 1) the		received level of QoS guarantees" with two requirements: 1) the
	feedback of a request MUST include yes and no (MUST respond yes or		feedback of a request MUST include yes and no (MUST respond yes or
	no) 2) in case of no it MAY include an opaque service-specific		no) 2) in case of no it MAY include an opaque service-specific
	information about what would be possible		information about what would be possible
	It is still only one requirement, but the text has been replaced.		It is still only one requirement, but the text has been replaced.
	25) (CLOSED) remove req 5.10.3 Combination with Mobility management		25) (CLOSED) remove req 5.10.3 Combination with Mobility management
	However the integration should not be a priori excluded, there is		However the integration should not be a priori excluded, there is
	explicitly no statemant about independence of mobility management.		explicitly no statemant about independence of mobility management.
	There is more discussion for the mobility case needed anyway.		There is more discussion for the mobility case needed anyway.
	26) (OPEN) interaction of NSIS with seamoby (context transfer and		26) (OPEN) interaction of NSIS with seamoby (context transfer and
	CAR discovery)		CAR discovery)
	27) (CLOSED) remove req 5.5.10 QoS conformance specification		27) (CLOSED) remove req 5.5.10 QoS conformance specification
	Motivation: this heavily depends on the service definition and is		Motivation: this heavily depends on the service definition and is
	therefore out of scope		therefore out of scope
	removed		removed
	28) (OPEN) new requirement on "asynchronous events from the network"		28) (OPEN) new requirement on "asynchronous events from the network"
	The content of the message might be very service specific, but the		The content of the message might be very service specific, but the
	protocol support for asynchronous events from the network might be a		protocol support for asynchronous events from the network might be a
	valuable requirement.		valuable requirement. We have something about notification in case
			of errors/failures.
	29) (OPEN) NSIS in case of handovers		29) (OPEN) NSIS in case of handovers
			The whole mobility area needs to be defined
	30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in		30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in
	various dimensions)		various dimensions)
	removed because it seams to be obvious		removed because it seams to be obvious
	31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol		31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol
	for existing local technologies		for existing local technologies
	It is contradictory to 5.1.9 and the intention behind the		It is contradictory to 5.1.9 and the intention behind the
	requirement is covered by the requierement that the QoS controller		requirement is covered by the requierement that the QoS controller
	can be placed wherever needed.		can be placed wherever needed.
	32) (CLOSED) add assumption: there are means for discovery of nsis		32) (CLOSED) add assumption: there are means for discovery of nsis
	entities in order to know the signaling peers (solutions include		entities in order to know the signaling peers (solutions include
	static configuration, or automatically discovered etc.)		static configuration, or automatically discovered etc.)
	33) (OPEN) add req " highest possible network utilization"
			33) (CLOSED) add req " highest possible network utilization"
	"There are networking environments that require high network		"There are networking environments that require high network
	utilization for various reasons, and the signaling protocol should		utilization for various reasons, and the signaling protocol should
	to its best ability support high resource utilization while		to its best ability support high resource utilization while
	maintaining appropriate QoS.		maintaining appropriate QoS.
	In networks where resources are very expensive (as is the case for		In networks where resources are very expensive (as is the case for
	many wireless networks), efficient network utilization is of		many wireless networks), efficient network utilization is of
	critical financial importance. On the other hand there are other		critical financial importance. On the other hand there are other
	parts of the network where high utilization is not required.		parts of the network where high utilization is not required.
	"		"
	34) (OPEN)_difference between "UMTS access scenario" "cellular
			req added
			34) (CLOSED)_difference between "UMTS access scenario" "cellular
	network scenario", and "Wired part of wireless network" (Section		network scenario", and "Wired part of wireless network" (Section
	8.2, 8.3, and 8.4)		8.2, 8.3, and 8.4)
	currently all three are included
	what are the essential issues?		all three are included.
	35) (OPEN) difference between the two PSTN gateway scenarios		The only common point between the three scenarios is that they are
			related to cellular networks. Section 8.4 is introducing the
			scenario used in the radio access network of cellular networks.
			Sections 8.2 and Section 8.3 are discussing other parts of the
			cellular network.
			35) (CLOSED) difference between the two PSTN gateway scenarios
	(Section 8.8 and 8.9)		(Section 8.8 and 8.9)
	currently both are included
	what are the essential issues?		currently both are included, they might be merged, sionce one seams
	36) req "Independence of reservation identifier"		to be more general than the other
			36) (OPEN) req "Independence of reservation identifier"
	issue here is that this might only be valuable in mobile		issue here is that this might only be valuable in mobile
	environments, and complicate the protocol for other environemnts.		environments, and complicate the protocol for other environemnts.
	there related issues (37,38,
	37) ownership of a reservation		there are related issues (37,38,
			37) (OPEN) ownership of a reservation
	The issue here is that a known party owns reservations done in the		The issue here is that a known party owns reservations done in the
	network. (which might include that the party also pays). The		network. (which might include that the party also pays). The
	question arose who is allowed to tear-down, receive asynchronous		question arose who is allowed to tear-down, receive asynchronous
	notifications in case of network initiated tear-down, etc.		notifications in case of network initiated tear-down, etc.
	This also relates to how certain service granted is		This also relates to how certain service granted is
	named/identified.		named/identified.
	38) (OPEN) definition of security threats		38) (OPEN) definition of security threats
	39) (OPEN) simplify security requirements section		39) (OPEN) simplify security requirements section
	40) (OPEN) add mobility related requirements		40) (OPEN) add mobility related requirements
	41) (CLOSED) remove req 5.5.1 Mutability information on parameters		41) (CLOSED) remove req 5.5.1 Mutability information on parameters
	removed because it is service-specific		removed because it is service-specific
	42) (OPEN) add an assumption that QoS nmonitoring is application-		42) (OPEN) add an assumption that QoS nmonitoring is application-
	specific and with it out of scope of the WG		specific and with it out of scope of the WG
	43) (OPEN) asynchronous notification of QoS Initiator, Controller,		43) (OPEN) asynchronous notification of QoS Initiator, Controller,
	Receiver, there are security issues related. Basically, an ownership		Receiver, there are security issues related. Basically, an ownership
	issue. Nevertheless, an asynch notifcation in case of an error,		issue. Nevertheless, an asynch notifcation in case of an error,
	network failure etc. is specifically in areas, where longer lived		network failure etc. is specifically in areas, where longer lived
	sessions are setup, essential in order to notify upper layes		sessions are setup, essential in order to notify upper layes
	(appluications etc. as well.		(appluications etc. as well.
	44) (OPEN) req 5.1.2 resource availability info on request come back		44) (OPEN) req 5.1.2 resource availability info on request come back
	to it as soon as we have a more clear idea about service description		to it as soon as we have a more clear idea about service description
	issue		issue
	45) (OPEN) 5.3.4 Possibility for automatic re-setup of resources		45) (OPEN) 5.3.4 Possibility for automatic re-setup of resources
	after recovery		after recovery
	- more thoughts in failure conditions potentially		- more thoughts in failure conditions potentially
	- better text		- better text
	- operation under overload		- operation under overload
	plays into issue 46)		plays into issue 46)
	46) (OPEN) we need multiple scenario for failure and recovery cases		46) (OPEN) we need multiple scenario for failure and recovery cases
	to derive requirements. Or a list failre cases might be a start as		to derive requirements. Or a list failre cases might be a start as
	well.		well.
	47) (OPEN) traffic engineering and route pinning		47) (OPEN) traffic engineering and route pinning
	I assume this would result in operational type of requirements		I assume this would result in operational type of requirements
	Opinions on that?		Opinions on that?
	48) (CLOSED) req 5.5.5 remove Multiple levels of detail		48) (CLOSED) req 5.5.5 remove Multiple levels of detail
	"The QSC should allow for multiple levels of detail in description.		"The QSC should allow for multiple levels of detail in description.
	(Motivation: someone interpreting the request can tune its own level		(Motivation: someone interpreting the request can tune its own level
	of complexity by going down to more or less levels of detail. A		of complexity by going down to more or less levels of detail. A
	lightweight implementation within the core could consider only the		lightweight implementation within the core could consider only the
	coarsest level.)"		coarsest level.)"
	removed, because it is service-specific		removed, because it is service-specific
	49) (CLOSED) remove req 5.5.9 Signaling must support quantitative,		49) (CLOSED) remove req 5.5.9 Signaling must support quantitative,
	qualitative, and relative QoS specifications		qualitative, and relative QoS specifications
	removed because it is service-specific		removed because it is service-specific
	50) (CLOSED) req 5.5.6 remove Ranges in specification		50) (CLOSED) req 5.5.6 remove Ranges in specification
	The QSC should allow for specification of minimum required QoS		The QSC should allow for specification of minimum required QoS
	and/or desirable QoS. (Motivation: The QoS Service Classes should		and/or desirable QoS. (Motivation: The QoS Service Classes should
	allow for ranges to be indicated, to minimize negotiation latency		allow for ranges to be indicated, to minimize negotiation latency
	and suppress error notifications during handover events.)		and suppress error notifications during handover events.)
	removed, is service specific		removed, is service specific
	51) (OPEN) remove 5.1.6 Avoid duplication of [sub]domain signaling
			51) (CLOSED) remove 5.1.6 Avoid duplication of [sub]domain signaling
	functions		functions
	we might to use the text somewhere else
			we might use the requirement text somewhere else:
			Heading: Avoid duplication of [sub]domain signaling functions
			The specification of the NSIS signaling protocol should be optimized
			to avoid duplication of existing [sub]domain QoS signaling and to
			minimize the overall complexity. (Motivation: we don't want to
			introduce duplicate feedback or negotiation mechanisms, or
			complicate the work by including all possible existing QoS signaling
			in some form. The function will be placed in the new part if it has
			to be end-to-end, universal to all network types
			('simple/lightweight'), or if it has to be protected by upper layer
			security mechanisms.)
			The point here is that the QoS technology (lower layer stuff) gets
			re-used unchanged, and we have new signaling above it. But, in many
			cases the local QoS technology will contain equivalent functions to
			the NSIS-required ones, just in a technology specific form. Examples
			of these functions would be error/QoS violation notifications,
			ability to query for resources and so on. So, there is a danger that
			our 'lightweight' signaling ends up trying to carry all this
			information all over again, and (even worse) that the
			initiator/controller functions have to weigh up nearly equivalent
			information coming from two directions. However, the basic problem
			here is that the boundary between new and re-used stuff is pretty
			shaky. The requirement is trying to scope our problem (a) to
			eliminate the potential overlap, and (b) to keep the new NSIS stuff
			simple.
			However, we are aware that it is very difficult to judge what is
			duplicated, if we want to run the protocol in various environments.
	52) (OPEN) New requirement: interaction with policy		52) (OPEN) New requirement: interaction with policy
	this most likely is covered by an opaque token for authentication		this most likely is covered by an opaque token for authentication
	dependency on security changes		dependency on security changes
	53) (OPEN) add req 5.1.16. of draft-partain-...-00 Error handling
	and redundancy considerations		53) (OPEN) Section 5.3. Error handling
	Border nodes should be able to notify the users if there is an error
	inside the network. There are two types of network errors:
	- Recoverable errors: this type error can be locally repaired
	by the network nodes. The network nodes do not have to
	notify the users of the error immediately.
	- Unrecoverable errors: the network nodes cannot handle this
	type of error, and have to notify the users as soon as
	possible.
	Comments:		Comments:
	1) notification of user in case of unrecoverable errors (has been		1) notification of user in case of unrecoverable errors (has been
	done by notification req, or will be done by asynch notification		done by notification requirement, or will be done by asynch
	2) recoverable error (might need to be added) req 5.3.4 is going		notification, issue 43)
	into this direction		A description of both types of errors (recoverable, unrecoverable)
	3) what does this mean for different parts of the network		are listed in Section 5.3.4.
	in different parts of the network)
	4) hop-by-hop? OR right to the end?		2) hop-by-hop? OR right to the end?
			3) What is potential value to notify about recoverable errors?
			Proposal: not hop by hop, but QoS controller to QoS initiator
	54) (CLOSED) add req 5.1.17. to assumption "Identification		54) (CLOSED) add req 5.1.17. to assumption "Identification
	requirement"		requirement"
	assumption say that the discovery of QI, QC, QR is out-of-scope of		assumption say that the discovery of QI, QC, QR is out-of-scope of
	the draft		the draft
	55) (OPEN) 5.2.2. Allow local QoS information exchange between two
	border nodes		55) (CLOSED) add from draft-partain-nsis-requirements-00.txt req
			5.2.2. Allow local QoS information exchange between two border
			nodes
	"The QoS signalling protocol must be able to exchange local QoS		"The QoS signalling protocol must be able to exchange local QoS
	information between edge nodes. Local QoS information might, for		information between edge nodes. Local QoS information might, for
	example, be IP addresses, severe congestion notification,		example, be IP addresses, severe congestion notification,
	notification of succesful or erroneous processing of QoS signalling		notification of succesful or erroneous processing of QoS signalling
	messages at one border node.		messages at one border node.
	In some domains, the NSIS QoS signalling protocol MAY carry		In some domains, the NSIS QoS signalling protocol MAY carry
	identification of the ingress and egress edge between the ingress-		identification of the ingress and egress edge between the ingress-
	egress edges. However, the identification of edges should not be		egress edges. However, the identification of edges should not be
	visible to the end host and only applies within one QoS		visible to the end host and only applies within one QoS
	administrative domain.		administrative domain.
	"		"
	Comments:		Comments:
	- service mapping is more service-specific (layering,tunneling)		- service mapping is more service-specific (layering,tunneling)
	- the scenario to look at is a complicated service description -> in		- the scenario to look at is a complicated service description -> in
	part of the network you want to change the message to something more		part of the network you want to change the message to something more
	easy, and at the other end go back to the more complicated part.		easy, and at the other end go back to the more complicated part.
	-QI being everywhere might be enough		-QI being everywhere might be enough
	-and we have already a requirement saying that intermediate node		-and we have already a requirement saying that intermediate node
	MUST be able to add/remove domain-specific information to/from		MUST be able to add/remove domain-specific information to/from
	signaling messages		signaling messages
	56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00		56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00
	-already added a req to the scalability section (issue ???), which		-already added a req to the scalability section (issue ???), which
	has been provided by Anders		has been provided by Anders
	57) (OPEN) potentially better title for text from issue 56) e.g.
	(?minimal impact on core?)		57) (CLOSED) potentially better title for text from issue 56) e.g.
			(ôminimal impact on coreö)
	58) (CLOSED) add req 5.3.2 from draft-partain-...-00		58) (CLOSED) add req 5.3.2 from draft-partain-...-00
	- the fast establishment req is handled by the low setup latency		- the fast establishment req is handled by the low setup latency
	req, and the scalability in handover req		req, and the scalability in handover req
	- added the text to the teminal mobility scenario		- added the text to the teminal mobility scenario
			- added text " time scale (e.g., handover in mobile environments),"
			to req
	59) (OPEN) add req: ability to deal with severe congestion (req		59) (OPEN) add req: ability to deal with severe congestion (req
	5.3.4 of draft-partain-..-00		5.3.4 of draft-partain-..-00
	issues are:		issues are:
	- the use in highly utilized networks		- occurs in a highly utilised network and if it is not solved very
			fast then the network performance will quickly collapse
	- deos it belong to failure recovery (I would assume from a service		- deos it belong to failure recovery (I would assume from a service
	point of view this is failure		point of view this is failure
	- hop by hop problem (issue from Jorge)		- hop by hop problem (issue from Jorge)
	60) (OPEN) add req 5.4.3. from draft-partain-...-00 "Allow efficient		- What difference does it make (from the QoS perspective) if the
	QoS re-establishment after handover"		provided QoS degraded due to hardware failure on a device or due to
			congestion caused by failures on some other devices? What is
			required from the protocol is to signal this failure to other
			participants (QCs or QI) in the hope that they can do something
			meaningful (e.g. re-routing) to correct the problem or tear down the
			flow.
			60) (CLOSED) add req 5.4.3. from draft-partain-...-00 "Allow
			efficient QoS re-establishment after handover"
	"Handover is an essential function in wireless networks. After		"Handover is an essential function in wireless networks. After
	handover, QoS may need to be completely or partially re-established		handover, QoS may need to be completely or partially re-established
	due to route changes. The re-establishment may be requested by the		due to route changes. The re-establishment may be requested by the
	mobile node itself or triggered by the access point that the mobile		mobile node itself or triggered by the access point that the mobile
	node is attached to. In the first case, the QoS signalling should		node is attached to. In the first case, the QoS signalling should
	allow efficient QoS re-establishment after handover. Re-		allow efficient QoS re-establishment after handover. Re-
	establishment of QoS after handover should be as quick as possible		establishment of QoS after handover should be as quick as possible
	so that the mobile node does not experience service interruption or		so that the mobile node does not experience service interruption or
	QoS degradation. The re-establishment should be localized, and not		QoS degradation. The re-establishment should be localized, and not
	require end-to-end signalling, if possible."		require end-to-end signalling, if possible."
	most likely it is already cover, please check again, whether there
			- most likely it is already cover, please check again, whether there
	is something missing		is something missing
			- added it again under the mobility requiremments
	61) (OPEN) add req: 6.1.8 from draft-bucheli-...-00 on multicast		61) (OPEN) add req: 6.1.8 from draft-bucheli-...-00 on multicast
	"Multicast consideration should not impact the protocol complexity		"Multicast consideration should not impact the protocol complexity
	for unicast flows. Multicast support is not considered as a		for unicast flows. Multicast support is not considered as a
	priority, because the targeted interactive multimedia services are		priority, because the targeted interactive multimedia services are
	mainly unicast. For this reason, if considered in the solution,		mainly unicast. For this reason, if considered in the solution,
	multicast should not bring complexity in the unicast scenario."		multicast should not bring complexity in the unicast scenario."
	Opinions?		Opinions?
			---------------------------------------------------
			starting from -02 version
			---------------------------------------------------
			62) (OPEN) Request to add VPN scenario
			- Related to issue 1)
			- Difference of VPN scenario compared to what we already have is
			missing
			63) (CLOSED) added Sven Van den Bosch, Maarten Buchli, and Danny
			Goderis to acknowledgement section.
			64) (OPEN) Request to add req: Backwards compatibility
			A later version of an NSIS protocol must be backwards compatible
			with earlier versions of an NSIS protocol.
			65) (OPEN) Request to add req: Unexpected situations and error
			restistance
			An NSIS protocol must define behaviour of NSIS signaling units
			during unexpected situations. Unexpected situtions are unknown
			messages, parameters and parameter settings as well as receiption of
			unexpected messages (e.g. a "Reservation Confirmation" without prior
			"Reservation Request").
			Related to Open issues (53) and requirement 5.3.4.
			This requirement is emphasizing to many details that might not be
			necessary
			Req 5.3.4 refers to behaviour in the case of problems in the data
			plane. My suggestion here is about unexpected events/errors in the
			control plane. If you think that this point carries to many details,
			let's split it up in several individual requirements.
			66) (OPEN) Request to add req: Default behaviour
			An NSIS protocol must define default behaviours and parameter
			settings wherever applicable.
			67) (OPEN) Request to add req: Extendability
			An NSIS protocol must provide means to enhance a protocol with
			future procedures, messages, parameters and parameter settings.
			This was refering mostly to the service specific part of the
			protocol.
			could be a part of the modularity requirement 5.1.3
			68) (OPEN) Request to add req: Preventation of stale state
			An NSIS signalling protocol must provide means for an NSIS signaling
			unit to discover and remove local stale state. This may for example
			be done by means like soft state and periodic flooding or by a
			polling mechanism and hard state signaling.
			Might already be covered in other requirements, could also be that
			the solutions known are solutions for different problems. I think
			distributed garbage collection could also be a solution.
			69) (OPEN) Request to add req: Reliable Communication
			NSIS signaling procedures, connectivity between units involved in
			NSIS signaling as well as the basic transport protocol used by NSIS
			must provide a maximum of communication reliability. Procedures must
			define how an NSIS signaling systems behaves if some kind of request
			it sent stays without answer (this could require e.g. be timers,
			number of message retransmits and release messages).
			An NSIS signaling unit must be able to check its connectivity to an
			adjacent NSIS signaling unit at any time (this requirement must
			however not result in a DoS attack tool - the frequency of these
			checks must be limited, and flow control may be useful).
			The basic transport protocol to be used between adjacent NSIS units
			must ensure message integrity and reliable transport.
			MUST/SHOULD ensure error- and loss free transmission of signaling
			information.
			Do we really require this? Isn't this a soft state versus hard state
			issue?
			70) (OPEN) Request to add req: Smooth breakdown
			A unit participating in NSIS signaling must no cause further damage
			to other systems involved in NSIS signaling when it has to go out of
			service.
			71) (CLOSED) Changed text "5.6.8: Ability to constrain load on
			devices" to
			The NSIS architecture should give the ability to constrain the load
			(CPU load, memory space, signaling bandwidth consumption and
			signaling intensity) on devices where it is needed. This can be
			achieved by many different methods. Examples, and this are only
			examples, include message aggregation, by ignoring signaling
			message, header compression, or minimizing functionality. The
			framework may choose any method as long as the requirement is met.
			72) (OPEN) request to add "Error notification and error location"
			"An NSIS signaling node rejecting or releasing a reservation must
			indicate its identity. NSIS signalling should indicate why a
			requested resource is not or no longer available. "
			Compared to 5.3.4 this is about problems on the control plane
			------------------------------------------------------
			Change Log Version 01 -> 02
			- added issues 62-72
			- added some discussion text to open issues
			- req " highest possible network utilization" added (issue 33,
			closed)
			- issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios),
			- removed req "Avoid duplication of [sub]domain signaling
			functions", issue 51
			- Section 5.3.4: added explanation of recoverable and unrecoverable
			errors (issue 53)
			- added the following requirement: (closed issue 55) Allow local QoS
			information exchange between nodes of the saeme administrative
			domain
			The QoS signaling protocol must be able to exchange local QoS
			information between QoS controllers located within one single
			domain. Local QoS information might, for example, be IP addresses,
			severe congestion notification, notification of successful or
			erroneous processing of QoS signaling messages.
			In some cases, the NSIS QoS signalling protocol may carry
			identification of the QoS controllers located at the boundaries of a
			domain. However, the identification of edge should not be visible to
			the end host (QoS initiator) and only applies within one QoS
			administrative domain.
			- closed issue 57: add text about "Minimal impact on interior (core)
			nodes" to requirement 5.6.8 "Ability to constrain load on devices"
			- added requirement "Allow efficient QoS re-establishment after
			handover", closed issue 60.
			- changed text in 5.3.2
End of changes. 277 change blocks.
	189 lines changed or deleted		574 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/