< draft-ietf-forces-implementation-report-01.txt		draft-ietf-forces-implementation-report-02.txt >
	Internet Engineering Task Force E. Haleplidis		Internet Engineering Task Force E. Haleplidis
	Internet-Draft University of Patras		Internet-Draft University of Patras
	Intended status: Informational K. Ogawa		Intended status: Informational K. Ogawa
	Expires: August 29, 2010 NTT Corporation		Expires: December 29, 2010 NTT Corporation
	W. Wang		W. Wang
	Zhejiang Gongshang University		Zhejiang Gongshang University
	J. Hadi Salim		J. Hadi Salim
	Mojatatu Networks		Mojatatu Networks
	February 25, 2010		June 27, 2010
	Implementation Report for ForCES		Implementation Report for ForCES
	draft-ietf-forces-implementation-report-01		draft-ietf-forces-implementation-report-02
	Abstract		Abstract
	Forwarding and Control Element Separation (ForCES) defines an		Forwarding and Control Element Separation (ForCES) defines an
	architectural framework and associated protocols to standardize		architectural framework and associated protocols to standardize
	information exchange between the control plane and the forwarding		information exchange between the control plane and the forwarding
	plane in a ForCES Network Element (ForCES NE). RFC3654 has defined		plane in a ForCES Network Element (ForCES NE). RFC3654 has defined
	the ForCES requirements, and RFC3746 has defined the ForCES		the ForCES requirements, and RFC3746 has defined the ForCES
	framework.		framework.
	This document is an implementation report of the ForCES Protocol,		This document is an implementation report of the ForCES Protocol,
	Model and SCTP-TML, including the report on interoperability testing		Model and SCTP-TML, including the report on interoperability testing
	and the current state of ForCES implementations.		and the current state of ForCES implementations.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on December 29, 2010.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 29, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5		1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 7		2.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 6
	2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 7		2.3. Transport mapping layer . . . . . . . . . . . . . . . . . 6
	3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 11		6. Detail Section . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Implementation Experience . . . . . . . . . . . . . . . . 11		6.1. Implementation Experience . . . . . . . . . . . . . . . . 10
	6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 11		6.1.1. ForCES Protocol Features . . . . . . . . . . . . . . . 10
	6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 12		6.1.1.1. Protocol Messages . . . . . . . . . . . . . . . . 11
	6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 13		6.1.1.2. MainHeader Handling . . . . . . . . . . . . . . . 12
	6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 14		6.1.1.3. TLV Handling . . . . . . . . . . . . . . . . . . . 13
	6.1.1.4. Operation Types Supported . . . . . . . . . . . . 15		6.1.1.4. Operation Types Supported . . . . . . . . . . . . 14
	6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 16		6.1.1.5. ForCES Protocol Advanced Features . . . . . . . . 15
	6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 16		6.1.2. ForCES Model Features . . . . . . . . . . . . . . . . 15
	6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 17		6.1.2.1. Basic Atomic Types Supported . . . . . . . . . . . 16
	6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 18		6.1.2.2. Compound Types Supported . . . . . . . . . . . . . 17
	6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 18		6.1.2.3. LFBs Supported . . . . . . . . . . . . . . . . . . 17
	6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 21		6.1.3. ForCES SCTP-TML Features . . . . . . . . . . . . . . . 20
	6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 21		6.1.3.1. TML Priority Ports . . . . . . . . . . . . . . . . 20
	6.1.3.2. Message Handling at specific priorities . . . . . 22		6.1.3.2. Message Handling at specific priorities . . . . . 21
	6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 23		6.1.3.3. TML Security Feature . . . . . . . . . . . . . . . 22
	6.2. Interoperability Report . . . . . . . . . . . . . . . . . 23		6.2. Interoperability Report . . . . . . . . . . . . . . . . . 22
	6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 24		6.2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . 23
	6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 24		6.2.1.1. Scenario 1 - Pre-association Setup . . . . . . . . 23
	6.2.1.2. Scenario 2 - TML priority channels connection . . 25		6.2.1.2. Scenario 2 - TML priority channels connection . . 24
	6.2.1.3. Scenario 3 - Association Setup - Association		6.2.1.3. Scenario 3 - Association Setup - Association
	Complete . . . . . . . . . . . . . . . . . . . . . 25		Complete . . . . . . . . . . . . . . . . . . . . . 24
	6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 26		6.2.1.4. Scenario 4 - CE query . . . . . . . . . . . . . . 25
	6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 26		6.2.1.5. Scenario 5 - Heartbeat monitoring . . . . . . . . 25
	6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 26		6.2.1.6. Scenario 6 - Simple Config Command . . . . . . . . 25
	6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 27		6.2.1.7. Scenario 7 - Association Teardown . . . . . . . . 26
	6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 27		6.2.2. Tested Features . . . . . . . . . . . . . . . . . . . 26
	6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 27		6.2.2.1. ForCES Protocol Features . . . . . . . . . . . . . 26
	6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 29		6.2.2.2. ForCES Model Features . . . . . . . . . . . . . . 28
	6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 32		6.2.2.3. ForCES SCTP-TML Features . . . . . . . . . . . . . 31
	6.2.3. Interoperability Results . . . . . . . . . . . . . . . 33		6.2.3. Interoperability Results . . . . . . . . . . . . . . . 32
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 37		9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 38		10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
	10.2. Informative References . . . . . . . . . . . . . . . . . . 38		10.2. Informative References . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Terminology and Conventions		1. Terminology and Conventions
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Definitions		1.2. Definitions
	skipping to change at page 7, line 25 ¶		skipping to change at page 6, line 25 ¶
	plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined		plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined
	the ForCES requirements, and [RFC3746] has defined the ForCES		the ForCES requirements, and [RFC3746] has defined the ForCES
	framework.		framework.
	2.1. ForCES Protocol		2.1. ForCES Protocol
	The ForCES protocol works in a master-slave mode in which FEs are		The ForCES protocol works in a master-slave mode in which FEs are
	slaves and CEs are masters. The protocol includes commands for		slaves and CEs are masters. The protocol includes commands for
	transport of Logical Function Block (LFB) configuration information,		transport of Logical Function Block (LFB) configuration information,
	association setup, status, and event notifications, etc. The reader		association setup, status, and event notifications, etc. The reader
	is encouraged to read FE-protocol [I-D.ietf-forces-protocol] for		is encouraged to read the ForCES Protocol [RFC5810] for further
	further information.		information.
	2.2. ForCES Model		2.2. ForCES Model
	The FE-MODEL [I-D.ietf-forces-model] presents a formal way to define		The ForCES Model [RFC5812] presents a formal way to define FE Logical
	FE Logical Function Blocks (LFBs) using XML. LFB configuration		Function Blocks (LFBs) using XML. LFB configuration components,
	components, capabilities, and associated events are defined when the		capabilities, and associated events are defined when the LFB is
	LFB is formally created. The LFBs within the FE are accordingly		formally created. The LFBs within the FE are accordingly controlled
	controlled in a standardized way by the ForCES protocol.		in a standardized way by the ForCES protocol.
	2.3. Transport mapping layer		2.3. Transport mapping layer
	The TML transports the PL messages. The TML is where the issues of		The TML transports the PL messages. The TML is where the issues of
	how to achieve transport level reliability, congestion control,		how to achieve transport level reliability, congestion control,
	multicast, ordering, etc. are handled. All ForCES Protocol Layer		multicast, ordering, etc. are handled. All ForCES Protocol Layer
	implementations MUST be portable across all TMLs. Although more than		implementations MUST be portable across all TMLs. Although more than
	one TML may be standardized for the ForCES Protocol, all		one TML may be standardized for the ForCES Protocol, all
	implementations MUST IMPLEMENT the SCTP TML		implementations MUST implement the SCTP-TML [RFC5811].
	[I-D.ietf-forces-sctptml].
	3. Summary		3. Summary
	The authors attest that the ForCES Protocol, Model and SCTP-TML meet		The authors attest that the ForCES Protocol, Model and SCTP-TML meet
	the requirements for Draft Standard.		the requirements for Draft Standard.
	Three independent implementations, NTT Japan, University of Patras		Three independent implementations, NTT Japan, University of Patras
	and Zhejiang Gongshang University, were surveyed and found to already		and Zhejiang Gongshang University, were surveyed and found to already
	implement all the major features. All implementors mentioned they		implement all the major features. All implementors mentioned they
	will be implementing all missing features in the future.		will be implementing all missing features in the future.
	An interop test was conducted in July/2009 for all three		An interop test was conducted in July, 2009 for all three
	implementations. Two other organizations, Mojatatu Networks and		implementations. Two other organizations, Mojatatu Networks and
	Hangzhou Baud Information and Networks Technology Corporation, which		Hangzhou Baud Information and Networks Technology Corporation, which
	independently extended two different well known public domain		independently extended two different well known public domain
	protocol analyzers, Ethereal/Wireshark and tcpdump, also participated		protocol analyzers, Ethereal/Wireshark and tcpdump, also participated
	in the interop for a total of five independent organizations		in the interop for a total of five independent organizations
	implementing. The two protocol analyzers were used to verify		implementing. The two protocol analyzers were used to verify
	validity of ForCEs protocol messages (and in some cases semantics).		validity of ForCEs protocol messages (and in some cases semantics).
	There were no notable difficulties in the interoperability test and		There were no notable difficulties in the interoperability test and
	almost all issues were code bugs that were dealt with mostly on site		almost all issues were code bugs that were dealt with mostly on site
	and tests repeated successfully.		and tests repeated successfully as stated in Section 6.2.3.
	4. Methodology		4. Methodology
	This report has both an implementation experience survey as well as		This report has both an implementation experience survey as well as
	the results of the interoperability test.		the results of the interoperability test.
	The survey information was gathered after implementors answered a		The survey information was gathered after implementors answered a
	brief questionnaire with all ForCES Protocol, Model and SCTP-TML		brief questionnaire with all ForCES Protocol, Model and SCTP-TML
	features. The results can be seen in ForCES Features (Section 6.1)		features. The results can be seen in Section 6.1
	The interoperability results were part of the interoperability test.		The interoperability results were part of the interoperability test.
	Extended Ethereal and extended Tcpdump were used to verify the		Extended Ethereal and extended Tcpdump were used to verify the
	results. The results can be seen in Interoperability Report		results. The results can be seen in Section 6.2
	(Section 6.2)
	5. Exceptions		5. Exceptions
	The core features of the ForCES Protocol, Model and SCTP-TML have		The core features of the ForCES Protocol, Model and SCTP-TML have
	been implemented and tested in an interop in July, 2009. The		been implemented and tested in an interop in July, 2009. The
	intention of the interop testing was to validate that all the main		intention of the interop testing was to validate that all the main
	features of the 3 core documents were inter-operable amongst		features of the 3 core documents were inter-operable amongst
	different implementations. The tested features can be seen in Tested		different implementations. The tested features can be seen in
	Features (Section 6.2.2).		Section 6.2.2.
	Different organizations surveyed have implemented certain features		Different organizations surveyed have implemented certain features
	but not others. This approach is driven by presence of different		but not others. This approach is driven by presence of different
	LFBs the different organizations have currently implemented. All		LFBs the different organizations have currently implemented. All
	organizations surveyed have indicated intention to implement all		organizations surveyed have indicated intention to implement all
	outstanding features in due time. The implemented features can be		outstanding features in due time. The implemented features can be
	seen in Section 6.1.		seen in Section 6.1.
	The mandated TML security requirement, IPSec, was not validated		The mandated TML security requirement, IPSec, was not validated
	during the interop and is not discussed in this document. Since		during the interop and is not discussed in this document. Since
	IPSec is well known and is widely deployed not testing in presence of		IPSec is well known and widely deployed not testing in presence of
	IPSec does not invalidate the tests done.		IPSec does not invalidate the tests done. Note that Section 6.1.3.3
			indicates that none of the implementations reporting included support
			for IPSec, but all indicated their intention to implement.
	Although the SCTP priority ports have been changed since the		Although the SCTP priority ports have been changed since the
	interoperability test with the latest SCTP-TML draft, the change has		interoperability test with the latest SCTP-TML draft, the change has
	no impact in the validity of the interoperability test.		no impact in the validity of the interoperability test.
	6. Detail Section		6. Detail Section
	6.1. Implementation Experience		6.1. Implementation Experience
	Three different organizations have implemented the ForCES Protocol,		Three different organizations have implemented the ForCES Protocol,
	skipping to change at page 25, line 12 ¶		skipping to change at page 24, line 12 ¶
	o The IP of the CE that connected to		o The IP of the CE that connected to
	o The TML priority ports.		o The TML priority ports.
	6.2.1.2. Scenario 2 - TML priority channels connection		6.2.1.2. Scenario 2 - TML priority channels connection
	For the interoperability test, the SCTP was used as TML. The TML		For the interoperability test, the SCTP was used as TML. The TML
	connection with the associating element was needed for the scenario 2		connection with the associating element was needed for the scenario 2
	to be successful.		to be successful.
	Although the latest SCTP-TML document [I-D.ietf-forces-sctptml]		Although SCTP-TML [RFC5811] defines 3 priority channels, with
	defines 3 priority channels, with specific ports:		specific ports:
	o High priority - Port number: 6704		o High priority - Port number: 6704
	o Medium priority - Port number: 6705		o Medium priority - Port number: 6705
	o Lower priority - Port number: 6706		o Lower priority - Port number: 6706
	At the time of the interoperability test, the sctp ports of the three		At the time of the interoperability test, the sctp ports of the three
	priority channels were the following:		priority channels were the following:
	skipping to change at page 33, line 25 ¶		skipping to change at page 32, line 25 ¶
	these priority ports.		these priority ports.
	6.2.3. Interoperability Results		6.2.3. Interoperability Results
	All implementations were found to be interoperable with each other.		All implementations were found to be interoperable with each other.
	All scenarios were tested successfully.		All scenarios were tested successfully.
	The following issues were found and dealt with.		The following issues were found and dealt with.
	1. Some messages were sent to the wrong priority channels. There		1. Some messages were sent on the wrong priority channels. There
	was some ambiguities on the SCTP-TML document on what must be		were some ambiguities on the SCTP-TML document on how to deal
	the correct response from the CE and FE. Should it respond in		with such a situation. The possibilities were: an FE response
	the same channel, should it respond in the correct channel, or		on the same (wrong) channel as a CE query; on the correctly
	should it drop the packet? This has been corrected by changing		documented channel for the message; or to simply drop the
	the word recommended to MUST in the SCTP-TML document regarding		packet. This has been corrected by mandating the message to
	priority channel messaging .		channel mapping to be a MUST in the SCTP-TML document [RFC5811]
			before it was published as an RFC.
	2. At some point, a CE sent a TearDown message to the FE. The CE		2. At some point, a CE sent a TearDown message to the FE. The CE
	expected the FE to shut down the connection, and the FE waited		expected the FE to shut down the connection, and the FE waited
	the CE to shut down the connection and were caught in a		the CE to shut down the connection and were caught in a
	deadlock. This was a code bug and was fixed.		deadlock. This was a code bug and was fixed.
	3. Sometimes the association setup message, only on the remote		3. Sometimes, only when the CE and FE were remote to each other
	connection test, although sent, was not received by the other		(one being in China and another in Greece), the association
	end and made impossible the association. This was caused by		setup message was not received by the CE side and therefore an
	network problems.		association never completed. This was not an implementation
			issue, rather it was a network issue. This issue is solved with
			the retransmission of the non delivered messages.
	4. An implementation did not take into account that the padding in		4. An implementation did not take into account that the padding in
	TLVs MUST NOT be included in the length of the TLV. This was a		TLVs MUST NOT be included in the length of the TLV. This was a
	code bug and was fixed.		code bug and was fixed.
	5. EM Flag was set to reserved by a CE and was not ignored by the		5. EM Flag was set to reserved by a CE and was not ignored by the
	FE. This was a code bug and was fixed.		FE. This was a code bug and was fixed.
	6. After the FEHBPolicy was set to 1 the FE didn't send any		6. After the FEHBPolicy was set to 1 the FE didn't send any
	HeartBeats. This was a code bug and was fixed.		HeartBeats. This was a code bug and was fixed.
	skipping to change at page 34, line 21 ¶		skipping to change at page 33, line 24 ¶
	heartbeats, this was a success, but this is an implementation		heartbeats, this was a success, but this is an implementation
	issue implementers should keep in mind. This is a SCTP options		issue implementers should keep in mind. This is a SCTP options
	issue. Nothing was needed to be done.		issue. Nothing was needed to be done.
	9. A CE crashed due to unknown LFBSelector values. This was a code		9. A CE crashed due to unknown LFBSelector values. This was a code
	bug and was fixed.		bug and was fixed.
	10. With the remote connection from China, which was behind a NAT,		10. With the remote connection from China, which was behind a NAT,
	to Greece there were a lot of ForCES packet retransmission. The		to Greece there were a lot of ForCES packet retransmission. The
	problem is that packets like Heartbeats were retransmitted.		problem is that packets like Heartbeats were retransmitted.
	This was a SCTP issue. SCTP-PR was needed to be used.		This was an implementation issue regarding SCTP usage
			implementers should keep in mind. SCTP-PR option was needed to
			be used. Nothing was needed to be done.
	The interoperability test went so well that an additional extended		The interoperability test went so well that an additional extended
	test was added to test for batching messages. This test was also		test was added to test for batching messages. This test was also
	done successfully.		done successfully.
	7. Acknowledgements		7. Acknowledgements
	The authors like to give thanks to Professors Odysseas Koufopavlou		The authors like to give thanks to Professors Odysseas Koufopavlou
	and Spyros Denazis, and the Department of Electrical and Computer		and Spyros Denazis, and the Department of Electrical and Computer
	Engineering in the University of Patras who hosted the ForCES		Engineering in the University of Patras who hosted the ForCES
	skipping to change at page 35, line 23 ¶		skipping to change at page 34, line 23 ¶
	Gao, and other participants from Zhejiang Gongshang University which		Gao, and other participants from Zhejiang Gongshang University which
	connected remotely. This allowed the discovery of a series of issues		connected remotely. This allowed the discovery of a series of issues
	that would have been uncaught otherwise.		that would have been uncaught otherwise.
	The authors would like to thank also Hideaki Iwata and Yoshinobu		The authors would like to thank also Hideaki Iwata and Yoshinobu
	Morimoto for participating locally at the interoperability test and		Morimoto for participating locally at the interoperability test and
	also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for		also Hiroki Date and Hidefumi Otsuka all part of NTT Japan for
	contributing to the interoperability test.		contributing to the interoperability test.
	Additionally thanks are given to Xinping Wang for her help in writing		Additionally thanks are given to Xinping Wang for her help in writing
	the interoperability draft an Fenggen Jia for extending the Ethereal		the interoperability draft and Fenggen Jia for extending the Ethereal
	protocol analyzer.		protocol analyzer.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	For Security considerations please see [I-D.ietf-forces-protocol] and		No security elements of the protocol or the SCTP TML [RFC5811]
	[I-D.ietf-forces-sctptml]		specification were tested.
			The survey indicated that no security elements were implemented but
			all participants indicated their intention to implement
			For security considerations regarding the ForCES Protocol and the
			SCTP-TML please see [RFC5810] and [RFC5811]
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-forces-model]		[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
	Halpern, J. and J. Salim, "ForCES Forwarding Element		W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
	Model", draft-ietf-forces-model-16 (work in progress),		Control Element Separation (ForCES) Protocol
	October 2008.		Specification", RFC 5810, March 2010.
	[I-D.ietf-forces-protocol]		[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
	Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,		Layer (TML) for the Forwarding and Control Element
	Khosravi, H., and W. Wang, "ForCES Protocol		Separation (ForCES) Protocol", RFC 5811, March 2010.
	Specification", draft-ietf-forces-protocol-22 (work in
	progress), March 2009.
	[I-D.ietf-forces-sctptml]		[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
	Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping		Element Separation (ForCES) Forwarding Element Model",
	Layer) for ForCES protocol", draft-ietf-forces-sctptml-08		RFC 5812, March 2010.
	(work in progress), January 2010.
	10.2. Informative References		10.2. Informative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,
	July 2003.
	[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation		[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
	of IP Control and Forwarding", RFC 3654, November 2003.		of IP Control and Forwarding", RFC 3654, November 2003.
	[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,		[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
	"Forwarding and Control Element Separation (ForCES)		"Forwarding and Control Element Separation (ForCES)
	Framework", RFC 3746, April 2004.		Framework", RFC 3746, April 2004.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.
	[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation		[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation
	and Implementation Reports for Advancement to Draft		and Implementation Reports for Advancement to Draft
	Standard", BCP 9, RFC 5657, September 2009.		Standard", BCP 9, RFC 5657, September 2009.
	[ethereal]		[ethereal]
	"Ethereal is a protocol analyzer. The specific ethereal		"Ethereal is a protocol analyzer. The specific ethereal
	that was used is an updated Ethereal, by Fenggen Jia, that		that was used is an updated Ethereal, by Fenggen Jia, that
	can analyze and decode the ForCES protocol messages.", <ht		can analyze and decode the ForCES protocol messages.", <ht
	tp://peach.ease.lsoft.com/scripts/		tp://peach.ease.lsoft.com/scripts/
	wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=1048>.		wa.exe?A2=ind0906&L=FORCES&T=0&F=&S=&P=1048>.
End of changes. 29 change blocks.
	121 lines changed or deleted		112 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/