< draft-fu-nsis-qos-nslp-statemachine-00.txt		draft-fu-nsis-qos-nslp-statemachine-01.txt >
	NSIS X. Fu		NSIS X. Fu
	Internet-Draft Univ. Goettingen		Internet-Draft Univ. Goettingen
	Expires: May 11, 2005 H. Tschofenig		Expires: August 25, 2005 H. Tschofenig
	T. Tsenov		T. Tsenov
	Siemens		Siemens
	November 10, 2004		February 21, 2005
	QoS NSLP State Machine		QoS NSLP State Machine
	draft-fu-nsis-qos-nslp-statemachine-00.txt		draft-fu-nsis-qos-nslp-statemachine-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 38 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 11, 2005.		This Internet-Draft will expire on August 25, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes the state machines for the NSIS Signaling		This document describes the state machines for the NSIS Signaling
	Layer Protocol for Quality-of-Service signaling (QoS NSLP). A set of		Layer Protocol for Quality-of-Service signaling (QoS NSLP). A set of
	state machines for QoS NSLP entities at different locations of a flow		state machines for QoS NSLP entities at different locations of a flow
	path are presented in order to illustrate how QoS NSLP may be		path are presented in order to illustrate how QoS NSLP may be
	implemented.		implemented.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Notational conventions used in state diagrams . . . . . . . . 5		3. Notational conventions used in state diagrams . . . . . . . 5
	4. State Machine Symbols . . . . . . . . . . . . . . . . . . . . 7		4. State Machine Symbols . . . . . . . . . . . . . . . . . . . 7
	5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8		5.1 Common Procedures . . . . . . . . . . . . . . . . . . . . 8
	5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 8		5.2 Common Variables . . . . . . . . . . . . . . . . . . . . . 8
	5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9		5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. State machine for first QoS NSLP node in the flow path . . . . 10		5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
	7. State machine for intermediate QoS NSLP nodes . . . . . . . . 13		6. State machine for QNI QoS NSLP node . . . . . . . . . . . . 10
	8. State machine for last QoS NSLP node in the flow path . . . . 17		7. State machine for QNE QoS NSLP nodes . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. State machine for QNR QoS NSLP node . . . . . . . . . . . . 17
	10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 20		9. Security Considerations . . . . . . . . . . . . . . . . . . 20
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21		10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 21
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. Change History . . . . . . . . . . . . . . . . . . . . . . . 22
	12.1 Normative References . . . . . . . . . . . . . . . . . . . . 22		11.1 Changes in Version -01 . . . . . . . . . . . . . . . . . 22
	12.2 Informative References . . . . . . . . . . . . . . . . . . . 22		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . 24		13.1 Normative References . . . . . . . . . . . . . . . . . . 24
			13.2 Informative References . . . . . . . . . . . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . 26
	1. Introduction		1. Introduction
	This document describes the state machines for QoS NSLP [1], trying		This document describes the state machines for QoS NSLP [1], trying
	to show how QoS NSLP can be implemented to support its deployment.		to show how QoS NSLP can be implemented to support its deployment.
	The state machines described in this document are illustrative of how		The state machines described in this document are illustrative of how
	the QoS NSLP protocol defined in [1] may be implemented for the first		the QoS NSLP protocol defined in [1] may be implemented for the QNI
	QoS NSLP node in the flow path, intermediate QoS NSLP nodes, and the		QoS NSLP node, QNE QoS NSLP nodes, and QNR QoS NSLP node in the flow
	last QoS NSLP node in the flow path. Where there are differences [1]		path. Where there are differences [1] are authoritative. The state
	are authoritative. The state machines are informative only.		machines are informative only. Implementations may achieve the same
	Implementations may achieve the same results using different methods.		results using different methods.
	According to [1], there are several possibilities for QoS NSLP		According to [1], there are several possibilities for QoS NSLP
	signaling, at least including the following:		signaling, at least including the following:
	end-to-end signaling vs. scoped signaling		end-to-end signaling vs. scoped signaling
	sender-initiated signaling vs. receiver-initiated signaling		sender-initiated signaling vs. receiver-initiated signaling
	(which need to be incorporated into use scenarios when describing		(which need to be incorporated into use scenarios when describing
	state machine. Note they are represented by way of certain		state machine. Note they are represented by way of certain
	objects/flags in Reserve and Query messages.)		objects/flags in Reserve and Query messages.)
	The messages used in the QoS NSLP protocol can be summarized as		The messages used in the QoS NSLP protocol can be summarized as
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	5. Common Rules		5. Common Rules
	Throughout the document we use terms defined in the [1], such as flow		Throughout the document we use terms defined in the [1], such as flow
	sender, flow receiver, QUERY, RESERVE or RESPONSE.		sender, flow receiver, QUERY, RESERVE or RESPONSE.
	5.1 Common Procedures		5.1 Common Procedures
	tx_RESERVE(Toff): Transmit RESERVE message with 'Teardown' bit off		tx_RESERVE(Toff): Transmit RESERVE message with 'Teardown' bit off
	tx_RESERVE(Ton): Transmit RESERVE message with 'Teardown' bit on		tx_RESERVE(Ton): Transmit RESERVE message with 'Teardown' bit on
	tx_RESPONSE(): Transmit RESPONSE message		tx_RESPONSE(): Transmit RESPONSE message
	tx_QUERY(w/RII): Transmit QUERY message with Request Identification		tx_QUERY(<object>): Transmit QUERY message with <object>
	Information (RII) object		tx_QUERY(w/o<object>): Transmit QUERY message without <object>
	tx_QUERY(w/oRII): Transmit QUERY message without RII object		tx_NOTIFY(): Transmit NOTIFY message
	rx_RESPONSE(): Receive RESPONSE message		rx_RESPONSE(): Receive RESPONSE message
	rx_QUERY(): Receive QUERY message		rx_QUERY(): Receive QUERY message
	rx_RESERVE(): Receive RESERVE message		rx_RESERVE(): Receive RESERVE message
	TIMEOUT_State: State lifetime timer expiration		rx_NOTIFY(): Transmit NOTIFY message
			TIMEOUT_StateLifetime: State lifetime timer expiration
	TIMEOUT_Refresh: Refresh interval timer expiration		TIMEOUT_Refresh: Refresh interval timer expiration
			TIMEOUT_Refresh: Wait-Response interval timer expiration
	tg_QUERY: External trigger to send a QUERY message (typically		tg_QUERY: External trigger to send a QUERY message (typically
	triggered by the application).		triggered by the application).
	tg_RESERVE: External trigger to send a RESERVE message.		tg_RESERVE: External trigger to send a RESERVE message.
	tg_TEARDOWN: External trigger to clear previously established QoS		tg_TEARDOWN: External trigger to clear previously established QoS
	state (typically triggered by the application). It is translated		state (typically triggered by the application). It is translated
	to a tx_RESERVE(Ton) message.		to a tx_RESERVE(Ton) message.
	Set QoS state: establish the local QoS state.		Install QoS state: Install the local QoS state.
	Refresh QoS state: refresh the local QoS state.		Refresh QoS state: Refresh the local QoS state.
	Clear QoS state: delete the local QoS state.		Delete QoS state: Delete the local QoS state.
	Send info to Application: report information to the application.		Send info to Application: Report information to the application.
	RMF: Performs Resource Management Function and returns the following		RMF: Performs Resource Management Function and returns the following
	values{AVAIL, NO_AVAIL}.		values{AVAIL, NO_AVAIL}.
	SetRII: Sets the RII object of the messages e.g. the node requests		SetRII: Sets the RII object of the messages e.g. the node requests
	explicit response to the message being sent. Returns values		explicit response to the message being sent. Returns values
	{0,1}.		{0,1}.
	CheckRII: Checks the RII object of received RESPONSE message if it is		CheckRII: Checks the RII object of received RESPONSE message if it is
	requested by current node or other upstream node. Returns values		requested by current node or other upstream node. Returns values
	{LOCAL, NO_LOCAL}.		{LOCAL, NO_LOCAL}.
	Result: Processes the information of the RESPONSE messages and		ProcessQUERY: Processes a Query message and provides the requested
	provides information. It tells whether the reservation is		info
	successful or not (if it is a response to a reserve message), or
	the information carried in the response message (if it is a
	response to a query message), or an error has occurred. Returns
	values {INFO, SUCCESSFUL, ERROR}.
	5.2 Common Variables		5.2 Common Variables
	RII: Request Identification Information (RII) object. Logical		RII: Request Identification Information (RII) object. Logical
	variable representing if the RII is set or not. Takes values		variable representing if the RII is set or not. Takes values
	{0,1}.		{0,1}.
	SCOPING: Scoping flag of common message header. Takes values		SCOPING: Scoping flag of common message header. Takes values
	{"Next_hop","Whole_path"}.		{"Next_hop","Whole_path"}.
			RSN: Reservation Sequence Number object. Takes values:
			- recRSN - RSN object of the received message
			- currRSN - Current stored RSN value for installed QoS state.
			(Assumed to be the one for the direction where the message comes
			from e.g.Upstream/Downstream)
			ACK: Acknowledgement flag of common message header. Takes values
			{"On","Off"}.
			SummaryRefresh: Keeps information if Summary refresh method may be
			used for refreshing a installed QoS state. Takes value
			{"On","Off"}.
			E_SPEC: Error_Spec object. Takes values:
			- 0x02? - Success values
			- 0x04? - Transient Failure values
			- ERROR - Not specified in the QoS NSLP draft, but used
			here.(Section 10)
			QSPEC: QoS specification object.
			FlowID: Flow ID kept by the installed QoS state.
			Replace: Replace flag of common message header. Takes values
			{"On","Off"}.
			SII: Source Identification Information entry. Takes values:
			- CurrSII - SII entry stored for current installed QoS state.
			(Assumed to be the one for the direction where the message comes
			from e.g.Upstream/Downstream)
			- newSII - SII of the received message is different from the SII
			stored for the current installed QoS state.
	5.3 Constants		5.3 Constants
	6. State machine for first QoS NSLP node in the flow path
			5.4 Assumptions
			o For simplification not all included objects in a message are
			showed. Only those that are significant for the case are showed.
			State machines do not present handling of messages that are not
			significant for management of the states such as certain NOTIFY
			and QUERY messages.
			o State machines represent handling of messages of the same Session
			ID and with no protocol errors. Separate parallel instances of
			the state machines should handle messages for different Session
			IDs.
			o Default message handling should be defined for messages with
			different Session IDs that have impact on current session state
			and error messages. This is not included in the current version.
			o ACK flag in the common header is set "On" by default.
			o Direction of receiving and sending messages is not specified. We
			assume it is implicit from the context.
			6. State machine for QNI QoS NSLP node
	-----------		-----------
	State: INIT		State: INIT
	-----------		-----------
	Condition Action State		Condition Action State
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	UCT | initialize variables |IDLE		UCT | initialize variables |IDLE
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	-----------		-----------
	State: IDLE		State: IDLE
	-----------		-----------
	Condition Action State Note		Condition Action State Note
	------------------------+-------------------------+-----------+---		------------------------+-------------------------+-----------+---
	(rx_QUERY) && (!RII) && |tx_NOTIFY(ERROR) |IDLE |1)		rx_QUERY(RII) |ProcessQUERY |IDLE |
	(RMF="NO_AVAIL") | | |2)		|tx_RESPONSE(RII) | |
	| | |		| | |
	(rx_QUERY) && (RII) |tx_RESPONSE(w/RII) |IDLE |		(tg_RESERVE) && |Send info to Application |IDLE |
	| | |		(RMF="NO_AVAIL") | | |
	(tg_RESERVE) && |Send info to Application |IDLE |		| | |
	(RMF="NO_AVAIL") | | |		(tg_RESERVE) && (!RII) |tx_RESERVE(w/oRII), |QoS state |
	| | |		&& (!setRII) && | Install QoS state, |Installed |
	(tg_QUERY) && (setRII) |tx_QUERY(w/RII) |WAITRESP1 |		(RMF="AVAIL") | Send info to Application| |
	| | |		| | |
	(tg_RESERVE) && (RII) &&|tx_RESERVE(w/RII) |WAITRESP2 |		(tg_RESERVE) && (setRII)|Install QoS state, |QoS state |
	(RMF="AVAIL") | | |		&&(RMF="AVAIL") | tx_RESERVE(RII) |Installed +|
	| | |		| |WAITRESP2 |
	(rx_QUERY) && (!RII) && |tx_RESERVE(w/RII) |WAITRESP2 |2)		| | |
	(setRII) && | | |		(rx_QUERY)&&(!RII)&& |Tx_RESPONSE(RSN, |IDLE |1)
	(RMF="AVAIL") | | |		(RMF="NO_AVAIL") | E_SPEC="ERROR") | |2)
	| | |		| | |
	(rx_QUERY) && (!RII) && |tx_RESERVE(w/oRII), |ESTABLISHED|2)		(rx_QUERY) && (!RII) && |tx_RESERVE(w/oRII), |QoS state |2)
	(!setRII) && | Set QoS state, | |		(!setRII) && | Install QoS state, |Installed |
	(RMF="AVAIL") | Send info to Application| |		(RMF="AVAIL") | Send info to Application| |
	| | |		| | |
	(tg_RESERVE) && |tx_RESERVE(w/oRII), |ESTABLISHED|		(rx_QUERY) && (!RII) && |Install QoS state, |QoS state |2)
	(!setRII) && | Set QoS state, | |		(setRII) && |tx_RESERVE( RII) |Installed +|
	(RMF="AVAIL") | Send info to Application| |		(RMF="AVAIL") | |WAITRESP2 |
	------------------------+-------------------------+-----------+---		| | |
			(tg_QUERY) && (setRII) |tx_QUERY(RII) |WAITRESP1 |
			| | |
			------------------------+-------------------------+-----------+---
			Note:
			1) How to signal unsuccessful reservation for Receiver initiated
			reservation (No RII included; sent Response(RSN) should not be
			forwarded further than the next peer). No Error_SPEC value
			specified for this case.
			2) Relevant for Receiver-initiated reservation.
	Note: 1) tx_NOTIFY(ERROR) is transmitted when an ERROR event must		----------------
	be announced to other downstream nodes which do not expect		State: WAITRESP1
	a RESPONSE message for this action. E.g., there is no provided		----------------
	RII which will be included in a RESPONSE message;
	2) Relevant for Receiver-initiated reservation.
	----------------		Condition Action State
	State: WAITRESP1		------------------------+-------------------------+------------
	----------------		(TIMEOUT_WaitResp) && |tx_QUERY(RII) |WAITRESP1
			(!MaxRetry) | |
			| |
			(TIMEOUT_WaitResp) && |Send info to Application |IDLE
			(MaxRetry) | |
			| |
			rx_RESPONSE |Send info to Application |IDLE
			------------------------+-------------------------+------------
	Condition Action State		--------------------------------------
	------------------------+-------------------------+------------		State: QoS state installed + WAITRESP2
	(TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP1		--------------------------------------
	(!MaxRetry) | |
	| |
	(TIMEOUT_Refresh) && |Send info to Application |IDLE
	(MaxRetry) | |
	| |
	rx_RESPONSE |Send info to Application |IDLE
	------------------------+-------------------------+------------
	------------------		Condition Action State
	State: ESTABLISHED		------------------------+-------------------------+------------
	------------------		(TIMEOUT_WaitResp) && |tx_RESERVE(RII) |QoS state
			(!MaxRetry) | |installed +
			| |WAITRESP2
			| |
			| |
			(TIMEOUT_WaitResp) && |Delete QoS state |IDLE
			(MaxRetry) |Send info to Application |
			| |
			rx_RESPONSE(RII, |Delete QoS state |IDLE
			E_SPEC="0x04?") |Send info to Application |
			| |
			| |
			rx_RESPONSE(RII, |Send info to Application |QoS state
			E_SPEC="0x02?") |SummaryRefresh="On" |installed
			------------------------+-------------------------+------------
			--------------------------
			State: QoS state installed
			--------------------------
	Condition Action State		Condition Action State Note
	------------------------+-------------------------+------------		------------------------+-------------------------+-----------+---
	TIMEOUT_Refresh |tx_RESERVE |ESTABLISHED		TIMEOUT_Refresh |If (SummaryRefresh="On") |QoS state |
	| |		| (Tx_RESERVE(RSN)) && |installed |
	tg_TEARDOWN |tx_RESERVE(Ton), |IDLE		| (SummaryRefresh="Off") | |
	| Clear QoS state |		|Else | |
	------------------------+-------------------------+------------		| Tx_RESERVE(RSN,QSPEC); | |
	----------------		| | |
	State: WAITRESP2		rx_RESPONSE(RSN, |SummaryRefresh="On" |QoS state |
	----------------		E_SPEC="0x02?") | |installed |
			| | |
			TIMEOUT_StateLifetime |Delete QoS state |IDLE |1)
			|Send info to Application | |
			| | |
			tg_TEARDOWN |Delete QoS state, |IDLE |
			| tx_RESERVE(Ton) | |
			| | |
			rx_NOTIFY(RSN, |Delete QoS state |IDLE |
			E_SPEC="0x04?") |Send info to Application | |
			------------------------+-------------------------+-----------+---
	Condition Action State		Note:
	------------------------+-------------------------+------------		1) If QoS state lifetime expires in QNI, should RESERVE(Ton)
	(TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP2		be sent downstream the path?
	(!MaxRetry) | |
	| |
	(TIMEOUT_Refresh) && |Send info to Application |IDLE
	(MaxRetry) | |
	| |
	(rx_RESPONSE) && |Send info to Application |IDLE
	(Result="ERROR") | |
	| |
	(rx_RESPONSE) && |Set QoS state, |ESTABLISHED
	(Result="SUCCESS")&& | Send info to Application|
	(RMF="AVAIL") | |
	------------------------+-------------------------+------------
	7. State machine for intermediate QoS NSLP nodes		7. State machine for QNE QoS NSLP nodes
	-----------		-----------
	State: INIT		State: INIT
	-----------		-----------
	Condition Action State		Condition Action State
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	UCT | initialize variables |IDLE		UCT | initialize variables |IDLE
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	-----------		-----------
	State: IDLE		State: IDLE
	-----------		-----------
	Condition Action State Note		Condition Action State Note
	------------------------+-------------------------+-----------+---		------------------------+-------------------------+-----------+---
	(rx_RESERVE)&& !((RII)&&|Set QoS state, |ESTABLISHED|1a)		(rx_QUERY) && (!RII) |tx_QUERY(w/oRII) |IDLE |2)
	(setRII)) && | tx_RESERVE(w/oRII) | |		| | |
	(RMF="AVAIL") | | |		(rx_QUERY(RII, |ProcessQUERY, |IDLE |7)
	| | |		SCOPING="Next_hop") |Tx_RESPONSE(RII) | |
	(rx_RESERVE) && (RII) &&|Set QoS state, |ESTABLISHED|1b)		| | |
	(RMF="AVAIL") && | tx_RESPONSE(w/RII) | |		(rx_QUERY) && (RII) |tx_QUERY(w/RII) |IDLE |7)
	(SCOPING="Next_hop") | | |		| | |
	| | |		(rx_RESERVE(RII)) && |Tx_RESPONSE(RII, |IDLE |3)
	(rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|1b)		(RMF="NO_AVAIL") | E_SPEC="0x04?") | |
	(RMF="AVAIL") && | | |		| | |
	(SCOPING="Next_hop") | | |		(rx_RESERVE) && (!RII)&&|Tx_RESPONSE(RSN, |IDLE |3)
	| | |		(RMF="NO_AVAIL") | E_SPEC="0x04?") | |
	(rx_QUERY) && (!RII) |tx_QUERY(w/oRII) |IDLE |2)		| | |
	| | |		(rx_RESPONSE(RII)) && |Tx_RESPONSE(RII) |IDLE |
	(rx_QUERY) && |tx_QUERY(w/RII) |IDLE |		(CheckRII="Not_LOCAL")| | |
	(SCOPING="Next_hop") | | |		| | |
	| | |		(rx_RESERVE)&& !(setRII)|Install QoS state, |QoS State |1a)
	(rx_RESERVE) && (RII)&& |tx_RESPONSE(RII, ERROR) |IDLE |3)		&& (RMF="AVAIL") |If(ACK="On") |Installed |
	(RMF="NO_AVAIL") | | |		| Tx_RESPONSE(RSN, | |
	| | |		| E_SPEC="0x02?");| |
	(rx_RESERVE) && (!RII)&&|tx_NOTIFY(ERROR) |IDLE |3)		|If(RII) Tx_RESPONSE(RII) | |
	(RMF="NO_AVAIL") | | |		|Else Tx_RESPONSE(w/oRII)| |
	| | |		| | |
	(rx_RESERVE) && ((RII)|||tx_RESERVE(w/RII) |WAITRESP1 |4)		(rx_RESERVE(SCOPING= |Install QoS state, |QoS State |1b)
	(setRII)) && | | |		"Next_hop")) && |If(RII) Tx_RESPONSE(RII, |Installed |
	(RMF="AVAIL") | | |		(RMF="AVAIL") | E_SPEC="0x02?") | |
	| | |		|Else Tx_RESPONSE(RSN, | |
	(rx_QUERY) && (RII) |tx_QUERY(w/RII) |WAITRESP2 |5)		| E_SPEC="0x02?") | |
	| | |		| | |
	(tg_QUERY) && (setRII) |tx_QUERY(w/RII) |WAITRESP2 |5)		(rx_RESERVE) && (setRII)|Install QoS state, |QoS State |4)
	------------------------+-------------------------+-----------+---		&& (RMF="AVAIL") |Tx_RESPONSE(RII), |Installed +|
			|If(ACK="On") |WAITRESP1 |
			| Tx_RESPONSE(RSN, | |
			| E_SPEC="0x02?");| |
			| | |
			(tg_QUERY) && (setRII) |tx_QUERY(RII) |WAITRESP2 |5)
			------------------------+-------------------------+-----------+---
	------------------		----------------
	State: ESTABLISHED		State: QoS State Installed + WAITRESP1
	------------------		----------------
	Condition Action State		Condition Action State Note
	------------------------+-------------------------+------------		------------------------+-------------------------+-----------+---
	rx_RESERVE(Ton) |tx_RESERVE(Ton), |IDLE		(TIMEOUT_WaitResp) && |tx_RESERVE(RII) |WAITRESP1 |
	| clear QoS state |		(!MaxRetry) | | |
	| |		| | |
	TIMEOUT_Refresh |Refresh QoS state; |ESTABLISHED		(TIMEOUT_WaitResp) && |Delete QoS State, | |
	| if state changes, |		(MaxRetry) && |tx_NOTIFY(RSN, |IDLE |
	| tx_RESERVE(w/RII) |		| E_SPEC="0x04?") | |
	| |		|Send info to Application | |
	TIMEOUT_State |Clear QoS state |IDLE		| | |
	------------------------+-------------------------+------------		(rx_RESPONSE(RII, |Delete QoS State, |IDLE |4)
	----------------		E_SPEC="0x04?")) |tx_NOTIFY(RSN, | |
	State: WAITRESP1		&&(CheckRII="LOCAL") | E_SPEC="0x04?") | |
	----------------		|Send info to Application | |
			| | |
			(rx_RESPONSE(RII, |Send info to Application |QoS State |
			E_SPEC="0x02?")) |SummaryRefresh="On" |Installed |
			&&(CheckRII="LOCAL") | | |
			------------------------+-------------------------+-----------+---
	Condition Action State		----------------
	------------------------+-------------------------+------------		State: WAITRESP2
	(TIMEOUT_Refresh) && |tx_RESERVE(w/RII) |WAITRESP1		----------------
	(!MaxRetry) | Send info to Application|
	| |
	(TIMEOUT_Refresh) && |tx_NOTIFY(ERROR), |
	(MaxRetry) && | Send info to Application|IDLE
	(CheckRII="LOCAL") | |
	| |
	(TIMEOUT_Refresh) && |tx_RESPONSE(w/RII,Result=|
	(MaxRetry) && | "ERROR") |IDLE
	(CheckRII="NO_LOCAL")| |
	| |
	(rx_RESPONSE) && |Set QoS state |ESTABLISHED
	(CheckRII="LOCAL")&& | |
	(Result="SUCCESS") | |
	| |
	(rx_RESPONSE) && |Set QoS state, |ESTABLISHED
	(CheckRII="NO_LOCAL")| tx_RESPONSE(RII) |
	&&(Result="SUCCESS") | |
	| |
	(rx_RESPONSE) && |tx_NOTIFY(ERROR), |IDLE
	(CheckRII="LOCAL")&& | send info to Application|
	(Result="ERROR") | |
	| |
	(rx_RESPONSE) && |tx_RESPONSE(w/RII) |IDLE
	(CheckRII="NO_LOCAL")| |
	&&(Result="ERROR") | |
	------------------------+-------------------------+-------------
	----------------
	State: WAITRESP2
	----------------
	Condition Action State		Condition Action State Note
	------------------------+-------------------------+------------		------------------------+-------------------------+-----------+---
	(TIMEOUT_Refresh) && |tx_QUERY(w/RII) |WAITRESP2		(TIMEOUT_WaitResp) && |tx_QUERY(RII) |WAITRESP2 |
	(!MaxRetry) | |		(!MaxRetry) | | |
	| |		| | |
	(TIMEOUT_Refresh) && |Send info to Application |IDLE		(TIMEOUT_WaitResp) && |Send info to Application |IDLE |
	(MaxRetry) && | |		(MaxRetry) | | |
	(CheckRII="LOCAL") | |		| | |
	| |		(rx_RESPONSE) && |Send info to Application |IDLE |
	(TIMEOUT_Refresh) && |tx_RESPONSE(Result= |IDLE		(CheckRII="LOCAL") | | |
	(MaxRetry) && | "ERROR") |		------------------------+-------------------------+-----------+---
	(CheckRII="NO_LOCAL")| |
	| |
	(rx_RESPONSE) && |Send info to Application |IDLE
	(CheckRII="LOCAL") | |
	| |
	(rx_RESPONSE) && |tx_RESPONSE(w/RII) |IDLE
	(CheckRII="NO_LOCAL")| |
	------------------------+-------------------------+-------------
	Note: 1) Successful reservation with response request (1a) and		------------------
	with Scoping (1b);		State: QoS State Installed
	2) Processing of Query msg for Receiver initiated		------------------
	reservation;
	3) Unsuccessful reservation for Receiver initiated
	reservation, with/without request for response from the flow
	sender side. Tx_NOTIFY(ERROR) is sent to the upstream nodes to
	indicate failure of the reservation in the case when no RESPONSE
	is required by them;
	4) Reservation requests with RII set in the upstream nodes
	or in this node;
	5) Processing of Query message received from a neighboring
	node or triggered by the application layer.
	8. State machine for last QoS NSLP node in the flow path		Condition Action State Note
			------------------------+-------------------------+-----------+---
			rx_RESERVE(Ton) |tx_RESERVE(Ton), |IDLE |
			|Delete QoS state | |
			| | |
			rx_RESERVE |Refresh QoS state |QoS State |6)
			|If(ACK="On") |Installed |
			|Tx_RESPONSE(RSN, | |
			| E_SPEC="0x02?") | |
			| | |
			rx_RESPONSE(RSN, |SummaryRefresh="On" |QoS State |6)
			E_SPEC="0x02?") | |Installed |
			| | |
			TIMEOUT_Refresh |If (SummaryRefresh="On") |QoS State |6)
			| (Tx_RESERVE(RSN)) |Installed |
			| &&(SummaryRefresh="Off")| |
			|Else | |
			| Tx_RESERVE(RSN,QSPEC) | |
			| | |
			(rx_RESPONSE(RII, |SummaryRefresh="On" |QoS State |
			E_SPEC="0x02?")) |Tx_RESPONSE(RII, |Installed |
			&&(ChechRII="NOT_LOCAL")| E_SPEC="0x02?") | |
			| | |
			| | |
			(TIMEOUT_StateLifetime) |Delete QoS state |IDLE |8)
			| | |
			(rx_RESPONSE(RII, | | |
			E_SPEC="0x04?")) |Delete QoS state |IDLE |
			&&(ChechRII="NOT_LOCAL")|rx_RESPONSE(RII, | |
			| E_SPEC="0x04?") | |
			| | |
			rx_RESPONSE(RSN, |Delete QoS state |IDLE |
			E_SPEC="0x04?") |rx_NOTIFY(RSN, | |
			| E_SPEC="0x04?") | |
			| | |
			rx_NOTIFY(RSN, |Delete QoS state |IDLE |
			E_SPEC="0x04?") |rx_NOTIFY(RSN, | |
			| E_SPEC="0x04?") | |
			| | |
			| | |
			(Rx_RESERVE)&&(currSII) |Update QoS state |QoS State |9)
			&&(Replace="On") |If (RII) |Installed |
			&&(RMF="AVAIL") | Tx_RESERVE(RII,QSPEC)| |
			&&((recRSN>=currRSN) |else | |
			||(newFlowID)) | Tx_RESERVE(RSN,QSPEC);| |
			|If (ACK="On")&&(!RII) | |
			| tx_RESPONSE(RSN, | |
			| E_SPEC="0x02?");| |
			| | |
			| | |
			(Rx_RESERVE)&&(newSII) |Update QoS state |QoS State |9)
			&&(RMF="AVAIL") |If (RII) |Installed |
			&&((recRSN>=currRSN) | Tx_RESERVE(RII,QSPEC)| |
			||(newFlowID)) |else | |
			| Tx_RESERVE(RSN,QSPEC);| |
			|If (ACK="On")&&(!RII) | |
			| tx_RESPONSE(RSN, | |
			| E_SPEC="0x02?");| |
			|If (Replace="On") | |
			| tx_Reserve(Ton) | |
			| to currSII | |
			------------------------+-------------------------+-----------+---
			NOTE:
			1) Successful reservation without Response request (1a) and with
			Scoping (1b).
			2) Processing of Query msg for Receiver initiated reservation
			3) Unsuccessful reservation with/without request for response
			from previous node in the path.
			4) Unsuccessful reservation. RII requested at the local node.
			NOTIFY(RSN) is sent further to the upstream nodes.
			5) Processing of Query msg triggered by the application layer.
			6) QoS State refresh procedures
			7) Processing of Query msg received from an upstream node.
			8) We assume that handling of QoS state lifetime expiration
			event is based on the local policy of the node.
			NOTIFY/Reserve(Ton) messages might be sent to other peers.
			These issues are not described in the QoS NSLP draft.
			9) Update QoS state and Re-route functionality
			8. State machine for QNR QoS NSLP node
	-----------		-----------
	State: INIT		State: INIT
	-----------		-----------
	Condition Action State		Condition Action State
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	UCT | initialize variables |IDLE		UCT | initialize variables |IDLE
	------------------------+-------------------------+------------		------------------------+-------------------------+------------
	-----------		-----------
	State: IDLE		State: IDLE
	-----------		-----------
	Condition Action State Note
	------------------------+-------------------------+-----------+---
	(tg_QUERY) && |tx_QUERY(w/RII) |WAITRESV |1)
	(!setRII) | | |
	| | |
	(rx_RESERVE) && (RII) &&|Set QoS state, |ESTABLISHED|2a)
	(RMF="AVAIL") | tx_RESPONSE(w/RII) | |
	| | |
	(rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|2b)
	(RMF="AVAIL") | | |
	| | |
	(tg_RESERVE) && |Send info to Application |IDLE |3)
	(RMF="NO_AVAIL") | | |
	| | |
	(rx_RESPONSE) && (RII)&&|tx_RESPONSE(RII, ERROR) |IDLE |
	(RMF="NO_AVAIL") | | |
	| | |
	(rx_QUERY) && (RII) && |tx_QUERY(w/RII) |IDLE |
	------------------------+-------------------------+-----------+---
	------------------		Condition Action State Note
	State: ESTABLISHED		------------------------+-------------------------+-----------+---
	------------------		rx_QUERY(RII) |tx_RESPONSE(RII) |IDLE |
			| | |
			(rx_RESERVE)&&(!RII) |Tx_RESPONSE(RSN, |IDLE |
			&& (RMF="NO_A") | E_SPEC="0x04?") | |
			| | |
			| | |
			(rx_RESERVE(RII)) |Tx_RESPONSE(RII, |IDLE |
			&& (RMF="NO_A") | E_SPEC="0x04?") | |
			| | |
			(tg_QUERY) && |tx_QUERY(w/oRII) |WAITRESV |1)
			(!setRII) | | |
			| | |
			| | |
			(rx_RESERVE(RII)) |Install QoS state |QoS state |2)
			&& (RMF="AVAIL") |Tx_RESPONSE(RII, |installed |
			| E_SPEC="0x02?") | |
			| | |
			(rx_RESERVE)&&(!RII) |Install QoS state |QoS state |2)
			&& (RMF="AVAIL") |Tx_RESPONSE(RSN, |installed |
			E_SPEC="0x02?") | |
			------------------------+-------------------------+-----------+---
			---------------
			State: WAITRESV
			---------------
	Condition Action State		Condition Action State Note
	------------------------+-------------------------+------------		------------------------+-------------------------+-----------+---
	rx_RESERVE |Refresh QoS state |ESTABLISHED		TIMEOUT_WaitResp |Tx_QUERY(w/oRII) |WAITRESV |
	| |		| | |
	TIMEOUT_State |Clear QoS state |IDLE		(TIMEOUT_WaitResp) |Send info to Appl. |IDLE |
	------------------------+-------------------------+------------		&& (MaxRetry) | | |
	---------------		| | |
	State: WAITRESV		(rx_RESERVE)&&(!RII) |tx_RESPONSE(RSN, |IDLE |3)
	---------------		&& (RMF="Not_AVAIL") | E_SPEC="0x04?") | |
			|Send info to Appl. | |
			| | |
			(rx_RESERVE(RII)) |tx_RESPONSE(RII, |IDLE |3)
			&& (RMF="Not_AVAIL") | E_SPEC="0x04?") | |
			|Send info to Appl. | |
			| | |
			rx_RESPONSE(E_SPEC= |Send info to Appl. |IDLE |4)
			"ERROR")| | |
			| | |
			| | |
			(rx_RESERVE)&&(!RII) |Install QoS state |QoS state |
			&& (RMF="AVAIL") |Tx_RESPONSE(RSN, |installed |
			| E_SPEC="0x02?") | |
			| | |
			(rx_RESERVE(RII)) |Install QoS State |QoS state |
			&& (RMF="AVAIL") |Tx_RESPONSE(RII) |installed |
			| | |
			------------------------+-------------------------+-----------+---
			------------------
			State: QoS state installed
			------------------
	Condition Action State Note		Condition Action State Note
	------------------------+-------------------------+-----------+---		------------------------+-------------------------+-----------+---
	(rx_RESPONSE) && |Send info to Application |IDLE |		rx_RESERVE |Refresh QoS state |QoS state |
	(Result="ERROR") | | |		|If(ACK="On") |installed |
	| | |		| Tx_RESPONSE(RSN, | |
	(rx_RESERVE) && (!RII)&&|Set QoS state |ESTABLISHED|2)		| E_SPEC="0x02?")| |
	(RMF="AVAIL") | | |		| | |
	| | |		TIMEOUT_StateLifetime |Delete QoS state |IDLE |5)
	(rx_RESERVE) && (RII)&& |Set QoS state, |ESTABLISHED|2)		| | |
	(RMF="AVAIL") | tx_RESPONSE(w/RII) | |		rx_RESERVE(Ton) |Delete QoS state |IDLE |
	(rx_RESERVE) && (RII) &&|tx_NOTIFY(ERROR), |IDLE |4)		| | |
	(RMF="NO_AVAIL") | Send info to Application| |		------------------------+-------------------------+------------
	| | |
	(rx_RESERVE) && (!RII)&&|tx_RESPONSE(RII,ERROR), |IDLE |4)
	(RMF="NO_AVAIL") | Send info to Application| |
	------------------------+-------------------------+-----------+---
	Note: 1) Initiation of receiver-side reservation;		Note:
	2) Successful reservation with&without response request from		1) Initiation of Receiver-side reservation
	sender side;		2) Successful Reservation with& without response request from the
	3) In case of no response requested (RII not present in		QNI side
	RESERVE message), NOTIFY(ERROR) message is sent back to the		3) Unsuccessful Reservation with & without response request from
	upstream nodes in order to clear already established QoS state;		the QNI side.
	4) Unsuccessful reservation with&without response request		4) How to signal unsuccessful reservation for Receiver initiated
	from sender side;		reservation(No RII is included, received Response(RSN) should
			not be forwarded.
			5) We assume that handling of QoS state lifetime expiration event
			is based on the local policy of the node. NOTIFY/Reserve(Ton)
			messages might be sent to other peers. These issues are not
			described in the QoS NSLP draft.
	9. Security Considerations		9. Security Considerations
	This document does not raise new security considerations. Any		This document does not raise new security considerations. Any
	security concerns with the QoS NSLP are likely reflected in security		security concerns with the QoS NSLP are likely reflected in security
	related NSIS work already (such as [1] or [6]).		related NSIS work already (such as [1] or [6]).
	For the time being, the state machines described in this document do		For the time being, the state machines described in this document do
	not consider the security aspect of QoS NSLP protocol itself. A		not consider the security aspect of QoS NSLP protocol itself. A
	future versions of this document will add security relevant states		future versions of this document will add security relevant states
	and state transitions.		and state transitions.
	10. Open Issues		10. Open Issues
	This document tries to describe possible states and transitions for		This document tries to describe possible states and transitions for
	QoS NSLP according to its current specification [1], Section 5. We		QoS NSLP according to its current specification [1], Section 5. We
	found some issues during the development of the state machines. For		found some issues during the development of the state machines.
	example, for receiver-initiated reservation, it is unclear who
	triggers a teardown; bi-directional reservation is difficult to
	support as the state machine becomes quite complex (note at one
	particular point in time the protocol state engine can be only in one
	state). Another example is, it is often ignored for the
	functionality of abort operation after a defined MaxRetry number of
	retries. Results of this type of transitions are dependent on the
	parameter RII (e.g., if it is locally set or not).
	There are further unclear issues with processing rules and message		o For receiver-initiated reservation, it is unclear who triggers a
	definition, e.g., soft state handling and how to process notification		teardown.
	messages, which will be described in more detail in a future version		o Bi-directional reservation is difficult to support as the state
	of this document.		machine becomes quite complex (note at one particular point in
			time the protocol state engine can be only in one state).
			o How to signal unsuccessful reservation for Receiver initiated
			reservation (No RII included; a resulting Response(RSN) cannot be
			forwarded further than the next peer). No Error_SPEC value
			specified for this case.
			o If QoS state lifetime expires in QNI, should RESERVE(Ton) be sent
			downstream the path?
			o The case of unsuccessful reservation at a QNE node and no RII
			specified by upstream nodes. According to the spec RESPONSE(RSN)
			should not be forwarded further than the next peer. Currently we
			use NOTIFY(RSN) that is sent further to the upstream nodes.
			o We assume that handling of QoS state lifetime expiration event is
			based on the local policy of the node. NOTIFY/Reserve(Ton)
			messages might be sent to other peers. These issues are not
			described in the QoS NSLP draft.
			o The draft states that RESERVE message MUST be sent only towards
			the QNR. This is not the case when re-routing procedure is done
			and RESERVE(Ton) message should be sent from merging QNE node for
			deleting the old branch. We believe this is towards the QNI.
			o Re-routing functionality described in this document is not
			complete and need further consideration.
	To avoid confusions in state machines, instead of QNI, QNE and QNR,		11. Change History
	in this document we use the notations of "first QoS NSLP node in the
	flow path" (the closest one to the flow sender or the flow sender
	itself), "intermediate QoS NSLP nodes" and "last QoS NSLP node in the
	flow path" (the closest one to the flow receiver or the flow receiver
	itself).
	Default rules and common state transitions in case of reception of		11.1 Changes in Version -01
	certain messages as Notify, and Query(w/RII), will be described in a
	future version of this document.
	11. Acknowledgments		Version -01 covers more functionalities of the QoS NSLP. This
			requires addition and changes of the notations. The main details are
			as follows:
			1. Notation of the nodes changed to QNI, QNE and QNR.
			2. Description of soft state refresh functionality.
			3. Support of ACK flag in the common header.
			4. Include of QoS NSLP objects, flags from the common header and
			entries stored with the installed QoS state in a node: ACK,
			Replace, RSN, Error_SPEC, QSPEQ, FlowID, SII.
			5. Initial description of Re-routing functionality (Section 10).
			6. For support of all listed changes, some notations are changed.
			12. Acknowledgments
	The authors would like to thank Sven Van den Bosch for his feedback.		The authors would like to thank Sven Van den Bosch for his feedback.
	12. References		13. References
	12.1 Normative References		13.1 Normative References
	[1] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for		[1] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
	Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 (work		Quality-of-Service signaling",
	in progress), July 2004.		Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	12.2 Informative References		13.2 Informative References
	[3] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State		[3] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State
	Machines for Extensible Authentication Protocol (EAP) Peer and		Machines for Extensible Authentication Protocol (EAP) Peer and
	Authenticator", draft-ietf-eap-statemachine-05 (work in		Authenticator", Internet-Draft draft-ietf-eap-statemachine-06,
	progress), September 2004.		December 2004.
	[4] Institute of Electrical and Electronics Engineers, "DRAFT		[4] Institute of Electrical and Electronics Engineers, "DRAFT
	Standard for Local and Metropolitan Area Networks: Port-Based		Standard for Local and Metropolitan Area Networks: Port-Based
	Network Access Control (Revision)", IEEE 802-1X-REV/D9, January		Network Access Control (Revision)", IEEE 802-1X-REV/D9, January
	2004.		2004.
	[5] Ohba, Y., "State Machines for Protocol for Carrying		[5] Ohba, Y., "State Machines for Protocol for Carrying
	Authentication for Network Access (PANA)",		Authentication for Network Access (PANA)",
	draft-ohba-pana-statemachine-00 (work in progress), July 2004.		Internet-Draft draft-ohba-pana-statemachine-01, February 2005.
	[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",		[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
	draft-ietf-nsis-threats-06 (work in progress), October 2004.		Internet-Draft draft-ietf-nsis-threats-06, October 2004.
	Authors' Addresses		Authors' Addresses
	Xiaoming Fu		Xiaoming Fu
	University of Goettingen		University of Goettingen
	Telematics Group		Telematics Group
	Lotzestr. 16-18		Lotzestr. 16-18
	Goettingen 37083		Goettingen 37083
	Germany		Germany
	EMail: fu@cs.uni-goettingen.de		Email: fu@cs.uni-goettingen.de
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Tseno Tsenov		Tseno Tsenov
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: tseno.tsenov@mytum.de		Email: tseno.tsenov@mytum.de
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 24, line 41 ¶		skipping to change at page 26, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 57 change blocks.
	335 lines changed or deleted		494 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/