draft-ietf-detnet-tsn-vpn-over-mpls-03.txt		draft-ietf-detnet-tsn-vpn-over-mpls-04.txt
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: December 10, 2020 A. Malis		Expires: May 6, 2021 A. Malis
	Malis Consulting		Malis Consulting
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	D. Fedyk		D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	June 8, 2020		November 2, 2020
	DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS		DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
	draft-ietf-detnet-tsn-vpn-over-mpls-03		draft-ietf-detnet-tsn-vpn-over-mpls-04
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	TSN networks are interconnected over a DetNet MPLS Network.		TSN networks are interconnected over a DetNet MPLS Network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted 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.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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."
	This Internet-Draft will expire on December 10, 2020.		This Internet-Draft will expire on May 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3		2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4		3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4
	4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6		4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6
	4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7		4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7
	5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8		5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8
	5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8		5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8
	5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 10		5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9
	5.3. Edge Node DetNet Service and Forwarding Sub-Layer		5.3. Edge Node DetNet Service and Forwarding Sub-Layer
	Procedures . . . . . . . . . . . . . . . . . . . . . . . 10		Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Controller Plane (Management and Control) Considerations . . 11		6. Controller Plane (Management and Control) Considerations . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	The DetNet MPLS data plane builds on MPLS Traffic Engineering		The DetNet MPLS data plane builds on MPLS Traffic Engineering
	encapsulations and mechanisms to provide a forwarding sub-layer that		encapsulations and mechanisms to provide a forwarding sub-layer that
	is responsible for providing resource allocation and explicit routes.		is responsible for providing resource allocation and explicit routes.
	The forwarding sub-layer is supported by one or more forwarding		The forwarding sub-layer is supported by one or more forwarding
	labels (F-Labels).		labels (F-Labels).
	DetNet edge/relay nodes are DetNet service sub-layer aware,		DetNet edge/relay nodes are DetNet service sub-layer aware,
	understand the particular needs of DetNet flows and provide both		understand the particular needs of DetNet flows and provide both
	DetNet service and forwarding sub-layer functions. They add, remove		DetNet service and forwarding sub-layer functions. They add, remove
	and process d-CWs, S-Labels and F-labels as needed. MPLS enabled		and process d-CWs, S-Labels and F-labels as needed. MPLS DetNet
	DetNet nodes can enhance the reliability of delivery by enabling the		nodes and transit nodes include DetNet forwarding sub-layer
	replication of packets where multiple copies, possibly over multiple
	paths, are forwarded through the DetNet domain. They can also
	eliminate surplus previously replicated copies of DetNet packets.
	MPLS (DetNet) nodes also include DetNet forwarding sub-layer
	functions, support for notably explicit routes, and resources		functions, support for notably explicit routes, and resources
	allocation to eliminate (or reduce) congestion loss and jitter.		allocation to eliminate (or reduce) congestion loss and jitter.
			Unlike other DetNet node types, transit nodes provide no service sub-
	DetNet transit nodes reside wholly within a DetNet domain, and also		layer processing.
	provide DetNet forwarding sub-layer functions in accordance with the
	performance required by a DetNet flow carried over an LSP. Unlike
	other DetNet node types, transit nodes provide no service sub-layer
	processing.
	4.2. TSN over DetNet MPLS Encapsulation		4.2. TSN over DetNet MPLS Encapsulation
	The basic encapsulation approach is to treat a TSN Stream as an App-		The basic encapsulation approach is to treat a TSN Stream as an App-
	flow from the DetNet MPLS perspective. The corresponding example		flow from the DetNet MPLS perspective. The corresponding example
	shown in Figure 3.		shown in Figure 3.
	/-> +------+ +------+ +------+ TSN ^ ^		/-> +------+ +------+ +------+ TSN ^ ^
	| | X | | X | | X |<- Appli : :		| | X | | X | | X |<- Appli : :
	App-Flow <-+ +------+ +------+ +------+ cation : :(1)		App-Flow <-+ +------+ +------+ +------+ cation : :(1)
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 32 ¶
	5.1. Edge Node TSN Procedures		5.1. Edge Node TSN Procedures
	The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1		The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
	Working Group have defined (and are defining) a number of amendments		Working Group have defined (and are defining) a number of amendments
	to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and		to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
	bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]		bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]
	defines packet replication and elimination functions for a TSN		defines packet replication and elimination functions for a TSN
	network.		network.
	The implementation of TSN entity (i.e., TSN packet processing		The implementation of TSN entity (i.e., TSN packet processing
	functions) MUST be compliant with the relevant IEEE 802.1 standards.		functions) must be compliant with the relevant IEEE 802.1 standards.
	TSN specific functions are executed on the data received by the		TSN specific functions are executed on the data received by the
	DetNet Edge Node from the connected CE before forwarded to connected		DetNet Edge Node from the connected CE before forwarded to connected
	CE(s) or presentation to the DetNet Service Proxy function for		CE(s) or presentation to the DetNet Service Proxy function for
	transmission across the DetNet domain, or on the data received from a		transmission across the DetNet domain, or on the data received from a
	DetNet PW by a PE before it is output on the Attachment Circuit(s)		DetNet PW by a PE before it is output on the Attachment Circuit(s)
	(AC).		(AC).
	TSN packet processing function(s) of Edge Nodes (T-PE) are belonging		TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
	to the native service processing (NSP) [RFC3985] block. This is		to the native service processing (NSP) [RFC3985] block. This is
	similar to other functionalities being defined by standard bodies		similar to other functionalities being defined by standard bodies
	other than the IETF (for example in case of Ethernet: stripping,		other than the IETF (for example in case of Ethernet: stripping,
	overwriting or adding VLAN tags, etc.). Depending on the TSN role of		overwriting or adding VLAN tags, etc.). Depending on the TSN role of
	the Edge Node in the end-to-end TSN service selected TSN functions		the Edge Node in the end-to-end TSN service selected TSN functions
	are supported.		are supported.
	When a PE receives a packet from a CE, on a given AC with DetNet		When a PE receives a packet from a CE, on a given AC with DetNet
	service, it MUST first check via Stream Identification (see Clause 6.		service, it first checks via Stream Identification (see Clause 6. of
	of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])		IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	whether the packet belongs to a configured TSN Stream (i.e., App-flow		whether the packet belongs to a configured TSN Stream (i.e., App-flow
	from DetNet perspective). If no Stream ID is matched and no other		from DetNet perspective). If no Stream ID is matched and no other
	(VPN) service is configured for the AC then packet MUST be dropped.		(VPN) service is configured for the AC then packet MUST be dropped.
	If there is a matching TSN Stream then the Stream-ID specific TSN		If there is a matching TSN Stream then the Stream-ID specific TSN
	functions MUST be executed (e.g., ingress policing, header field		functions are executed (e.g., ingress policing, header field
	manipulation in case of active Stream Identification, FRER, etc.).		manipulation in case of active Stream Identification, FRER, etc.).
	Source MAC lookup MAY also be used for local MAC address learning.		Source MAC lookup may also be used for local MAC address learning.
	If the PE decides to forward the packet, the packet MUST be forwarded		If the PE decides to forward the packet, the packet MUST be forwarded
	according to the TSN Stream specific configuration to connected CE(s)		according to the TSN Stream specific configuration to connected CE(s)
	(in case of local bridging) and/or to the DetNet Service Proxy (in		(in case of local bridging) and/or to the DetNet Service Proxy (in
	case of forwarding to remote CE(s) required). If there are no TSN		case of forwarding to remote CE(s) required). If there are no TSN
	Stream specific forwarding configurations the PE MUST flood the		Stream specific forwarding configurations the PE MUST flood the
	packet to other locally attached CE(s) and to the DetNet Service		packet to other locally attached CE(s) and to the DetNet Service
	Proxy. If the administrative policy on the PE does not allow		Proxy. If the administrative policy on the PE does not allow
	flooding the PE MUST drop the packet.		flooding the PE MUST drop the packet.
	When a TSN entity of the PE receives a packet from the DetNet Service		When a TSN entity of the PE receives a packet from the DetNet Service
	Proxy, it MUST first check via Stream Identification (see Clause 6.		Proxy, it first checks via Stream Identification (see Clause 6. of
	of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])		IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	whether the packet belongs to a configured TSN Stream. If no Stream		whether the packet belongs to a configured TSN Stream. If no Stream
	ID is matched then packet MUST be dropped. If there is a matching		ID is matched then packet is dropped. If there is a matching TSN
	TSN Stream then the Stream ID specific TSN functions MUST be executed		Stream then the Stream ID specific TSN functions are executed (e.g.,
	(e.g., header field manipulation in case of active Stream		header field manipulation in case of active Stream Identification,
	Identification, FRER, etc.). Source MAC lookup MAY also be used for		FRER, etc.). Source MAC lookup may also be used for local MAC
	local MAC address learning.		address learning.
	If the PE decides to forward the packet, the packet MUST be forwarded		If the PE decides to forward the packet, the packet is forwarded
	according to the TSN Stream specific configuration to connected		according to the TSN Stream specific configuration to connected
	CE(s). If there are no TSN Stream specific forwarding configurations		CE(s). If there are no TSN Stream specific forwarding configurations
	the PE MUST flood the packet to locally attached CE(s). If the		the PE floods the packet to locally attached CE(s). If the
	administrative policy on the PE does not allow flooding the PE MUST		administrative policy on the PE does not allow flooding the PE drops
	drop the packet.		the packet.
	Implementations of this document SHALL use management and control		Implementations of this document SHALL use management and control
	information to ensure TSN specific functions of the Edge Node		information to ensure TSN specific functions of the Edge Node
	according to the expectations of the connected TSN network.		according to the expectations of the connected TSN network.
	5.2. Edge Node DetNet Service Proxy Procedures		5.2. Edge Node DetNet Service Proxy Procedures
	The Service Proxy function maps between App-flows and DetNet flows.		The Service Proxy function maps between App-flows and DetNet flows.
	The DetNet Edge Node TSN entity MUST support the TSN Stream		The DetNet Edge Node TSN entity MUST support the TSN Stream
	identification functions and the related managed objects as defined		identification functions and the related managed objects as defined
	skipping to change at page 11, line 51 ¶		skipping to change at page 11, line 42 ¶
	o TSN related configuration information according to the TSN role of		o TSN related configuration information according to the TSN role of
	the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and		the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
	[IEEEP8021CBdb].		[IEEEP8021CBdb].
	o DetNet MPLS related configuration information according to the		o DetNet MPLS related configuration information according to the
	DetNet role of the DetNet MPLS node, as per		DetNet role of the DetNet MPLS node, as per
	[I-D.ietf-detnet-mpls].		[I-D.ietf-detnet-mpls].
	o App-Flow identification information to map received TSN Stream(s)		o App-Flow identification information to map received TSN Stream(s)
	to the DetNet flow. Parameters fo TSN stream identification are		to the DetNet flow. Parameters of TSN stream identification are
	defined in [IEEE8021CB] and [IEEEP8021CBdb].		defined in [IEEE8021CB] and [IEEEP8021CBdb].
	This information MUST be provisioned per DetNet flow.		This information MUST be provisioned per DetNet flow.
			Mappings between DetNet and TSN management and control planes are out
			of scope of the document. Some of the challanges are highligthed
			below.
	MPLS DetNet Edge nodes are member of both the DetNet domain and the		MPLS DetNet Edge nodes are member of both the DetNet domain and the
	connected TSN network. From the TSN network perspective the MPLS		connected TSN network. From the TSN network perspective the MPLS
	(DetNet) Edge node has a "TSN relay node" role, so TSN specific		(DetNet) Edge node has a "TSN relay node" role, so TSN specific
	management and control plane functionalities must be implemented.		management and control plane functionalities must be implemented.
	There are many similarities in the management plane techniques used		There are many similarities in the management plane techniques used
	in DetNet and TSN, but that is not the case for the control plane		in DetNet and TSN, but that is not the case for the control plane
	protocols. For example, RSVP-TE and MSRP behaves differently.		protocols. For example, RSVP-TE and MSRP behaves differently.
	Therefore management and control plane design is an important aspect		Therefore management and control plane design is an important aspect
	of scenarios, where mapping between DetNet and TSN is required.		of scenarios, where mapping between DetNet and TSN is required.
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 34 ¶
	Christophe Mangin and Jouni Korhonen for their various contributions		Christophe Mangin and Jouni Korhonen for their various contributions
	to this work.		to this work.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-detnet-mpls]		[I-D.ietf-detnet-mpls]
	Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,		Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
	and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-		and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
	detnet-mpls-06 (work in progress), April 2020.		detnet-mpls-13 (work in progress), October 2020.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-detnet-data-plane-framework]		[I-D.ietf-detnet-data-plane-framework]
	Varga, B., Farkas, J., Berger, L., Malis, A., and S.		Varga, B., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-		Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
	data-plane-framework-06 (work in progress), May 2020.		data-plane-framework-06 (work in progress), May 2020.
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Mizrahi, T. and E. Grossman, "Deterministic Networking		Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
	(DetNet) Security Considerations", draft-ietf-detnet-		Networking (DetNet) Security Considerations", draft-ietf-
	security-10 (work in progress), May 2020.		detnet-security-12 (work in progress), October 2020.
	[IEEE802.1AE-2018]		[IEEE802.1AE-2018]
	IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC		IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
	Security (MACsec)", 2018,		Security (MACsec)", 2018,
	<https://ieeexplore.ieee.org/document/8585421>.		<https://ieeexplore.ieee.org/document/8585421>.
	[IEEE8021CB]		[IEEE8021CB]
	Finn, N., "Draft Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks - Seamless Redundancy", IEEE P802.1CB		networks - Frame Replication and Elimination for
	/D2.1 P802.1CB, December 2015,		Reliability (IEEE Std 802.1CB-2017)", 2017,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://standards.ieee.org/about/get/>.
	1CB-d2-1.pdf>.
	[IEEE8021Q]		[IEEE8021Q]
	IEEE 802.1, "Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks--Bridges and Bridged Networks (IEEE Std 802.1Q-		networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
	2014)", 2014, <http://standards.ieee.org/about/get/>.		2018)", 2018, <http://standards.ieee.org/about/get/>.
	[IEEEP8021CBdb]		[IEEEP8021CBdb]
	Mangin, C., "Extended Stream identification functions",		Mangin, C., "Extended Stream identification functions",
	IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,		IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://www.ieee802.org/1/files/private/db-drafts/d1/802-
	1CB-d2-1.pdf>.		1CBdb-d1-0.pdf>.
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
	Edge-to-Edge (PWE3) Architecture", RFC 3985,		Edge-to-Edge (PWE3) Architecture", RFC 3985,
	DOI 10.17487/RFC3985, March 2005,		DOI 10.17487/RFC3985, March 2005,
	<https://www.rfc-editor.org/info/rfc3985>.		<https://www.rfc-editor.org/info/rfc3985>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
End of changes. 22 change blocks.
	47 lines changed or deleted		42 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/