< draft-thubert-intarea-schc-over-ppp-00.txt		draft-thubert-intarea-schc-over-ppp-01.txt >
	LPWAN P. Thubert, Ed.		LPWAN P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 5172 (if approved) 1 July 2020		Updates: 5172 (if approved) 1 September 2020
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 2 January 2021		Expires: 5 March 2021
	SCHC over PPP		SCHC over PPP
	draft-thubert-intarea-schc-over-ppp-00		draft-thubert-intarea-schc-over-ppp-01
	Abstract		Abstract
	This document extends RFC 5172 to signal the use of SCHC as the		This document extends RFC 5172 to signal the use of SCHC as the
	compression method between a pair of nodes over PPP. Combined with		compression method between a pair of nodes over PPP. Combined with
	RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi.		RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 2 January 2021.		This Internet-Draft will expire on 5 March 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Extending RFC 5172 . . . . . . . . . . . . . . . . . . . . . 3		3. Extending RFC 5172 . . . . . . . . . . . . . . . . . . . . . 3
	4. Profiling SCHC for high speed links . . . . . . . . . . . . . 3		4. Profiling SCHC for high speed links . . . . . . . . . . . . . 4
	4.1. Mapping the SCHC Architecture . . . . . . . . . . . . . . 4		4.1. Mapping the SCHC Architecture . . . . . . . . . . . . . . 4
	4.2. SCHC Parameters . . . . . . . . . . . . . . . . . . . . . 4		4.2. SCHC Parameters . . . . . . . . . . . . . . . . . . . . . 5
	4.2.1. Resulting Packet Format . . . . . . . . . . . . . . . 5		4.2.1. Resulting Packet Format . . . . . . . . . . . . . . . 6
	4.3. Security Considerations . . . . . . . . . . . . . . . . . 6		4.3. Security Considerations . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Normative References . . . . . . . . . . . . . . . . . . . . 7		7. Normative References . . . . . . . . . . . . . . . . . . . . 8
	8. Informative References . . . . . . . . . . . . . . . . . . . 7		8. Informative References . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Point-to-Point Protocol (PPP) [RFC5172] provides a standard		The Point-to-Point Protocol (PPP) [RFC5172] provides a standard
	method of encapsulating network-layer protocol information over		method of encapsulating network-layer protocol information over
	point-to-point links. "A Method for Transmitting PPP Over Ethernet		serial (point-to-point and bus) links. "A Method for Transmitting
	(PPPoE)" [RFC2516] transports PPP over Ethernet between a pair of		PPP Over Ethernet (PPPoE)" [RFC2516] transports PPP over Ethernet
	nodes. It is compatible with a translating bridge to Wi-Fi, and		between a pair of nodes. It is compatible with a translating bridge
	therefore enables PPP over Wi-Fi as well.		to Wi-Fi, and therefore enables PPP over Wi-Fi as well.
	PPP also defines an extensible Link Control Protocol, and proposes a		PPP also proposes an extensible Link Control Protocol and a family of
	family of Network Control Protocols (NCPs) for establishing and		Network Control Protocols (NCPs) for establishing and configuring
	configuring different network-layer protocols. "IP Version 6 over		different network-layer protocols. "IP Version 6 over PPP" [RFC5072]
	PPP" [RFC5072] defines the IPv6 Control Protocol (IPV6CP) , which is		specifies the IPv6 Control Protocol (IPV6CP), which is an NCP for a
	an NCP for a PPP link, and allows for the negotiation of desirable		PPP link, and allows for the negotiation of desirable parameters for
	parameters for an IPv6 interface over PPP.		an IPv6 interface over PPP. "Negotiation for IPv6 Datagram
			Compression Using IPv6 Control Protocol" [RFC5172] defines the IPv6
			datagram compression option that can be negotiated by a node on the
			link through the IPV6CP.
	"Negotiation for IPv6 Datagram Compression Using IPv6 Control		The "Static Context Header Compression (SCHC) and fragmentation for
	Protocol" [RFC5172] defines the IPv6 datagram compression option that		LPWAN, application to UDP/IPv6" [SCHC] is a new technology that can
	can be negotiated by a node on the link through the IPV6CP. The		provide an extreme compression performance but requires a same state
	"Static Context Header Compression (SCHC) and fragmentation for		to be provisionned on both ends before it can be operated. To enable
	LPWAN, application to UDP/IPv6" [SCHC] is a compression and		SCHC over PPP and therefore Ethernet and Wi-Fi, this specification
	fragmentation technique that was defined after the publication of		extends [RFC5172] to signal SCHC as an additional compression method
	[RFC5172]. In order to enable SCHC over PPP and therefore Ethernet		for use over PPP.
	and Wi-Fi, [RFC5172] must be extended to signal SCHC as an additional
	compression method for use over PPP.		An example use case for SCHC over PPP over Ethernet (SCHCoPPPoE) is
			to apply SCHC to periodic flows and maintain them at a protocol-
			independant size and rate. The constant size may be too small for a
			particular flow or protocol. The SCHC fragmentation can then be used
			to transport a protocol data unit (PDU) as N compressed SCHC
			fragments, in which case the effective PDU rate is the TSN frame rate
			divided by N.
			This can be useful to streamline the frames and simplifies the
			scheduling of Deterministic Networking [DetNet] and Operational
			Technology (OT) control flows over IEEE Std 802.1 Time-Sensitive
			Networking (TSN) [IEEE802.1TSNTG] or one of the [RAW Technologies].
	2. BCP 14		2. BCP 14
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Extending RFC 5172		3. Extending RFC 5172
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 36 ¶
	+----------+ Wi-Fi / +----------+ ....		+----------+ Wi-Fi / +----------+ ....
	| IP | Ethernet | IP | .. )		| IP | Ethernet | IP | .. )
	| Host +-----/------+ Router +----------( Internet )		| Host +-----/------+ Router +----------( Internet )
	| SCHC C/D | Serial | SCHC C/D | ( )		| SCHC C/D | Serial | SCHC C/D | ( )
	+----------+ +----------+ ...		+----------+ +----------+ ...
	<-- SCHC -->		<-- SCHC -->
	over PPP		over PPP
	Figure 2: Typical Deployment		Figure 2: Typical Deployment
	The assumption for this document is that the SCHC Fragmenter/		The SCHC Fragmenter/Reassembler (F/R) is generally not needed,
	Reassembler (F/R) is generally not needed, because the maximum		because the maximum transmission unit (MTU) is expected to be large
	transmission unit (MTU) is expected to be large enough and SCHC only		enough and SCHC only reduces the frame size vs. native IP. But it
	reduces the frame size vs. native IP.		may be used to obtain a small protocol-independant frame size for the
			compressed packets, possibly way smaller than MTU.
	An example use case for SCHC over PPP over Ethernet (PPPoE) would be
	to apply SCHC to streamline traffic by reducing the size of the
	frames and maintain them to a constant size and constant rate, e.g.,
	to simplify the scheduling of [DetNet] packets over TSN or one of the
	[RAW Technologies]. Scheduling on DetNet links introduces a form of
	duty cycle, but that does not affect the SCHC operation, since
	fragmentation is not provided.
	A context may be generated for a particular upper layer application,		A context may be generated for a particular upper layer application,
	such as a control loop using an industrial automation protocol, to		such as a control loop using an industrial automation protocol, to
	protect the particular flow with a DetNet service. The context can		protect the particular flow with a DetNet service. The context can
	be asymetric, e.g., when connecting a master and a slave, a client		be asymetric, e.g., when connecting a primary and a secondary
	and a server, or a programmable logic controller with a sensor or an		endpoints, a client and a server, or a programmable logic controller
	actuator.		with a sensor or an actuator.
	4.2. SCHC Parameters		4.2. SCHC Parameters
	Compared to typical LPWANs, most serial links and emulations such as		Compared to typical LPWANs, most serial links and emulations such as
	PPPoE are very fast and most of the constraints can be alleviated.		PPPoE are very fast and most of the constraints can be alleviated.
	For this reason, the SCHC profile for PPP is defined as follows:		For this reason, the SCHC profile for PPP is defined as follows:
	RuleID numbering scheme: Rules are of a fixed size of two bytes,		RuleID numbering scheme: The RuleID for a compression rule is
	which allows for more than 65000 different Rules within one		expressed as 2 bytes. The first (leftmost) 2 bits of that RuleId
	session. Since this specification does not leverage the SCHC		MUST be set to 0 This leaves 14 bits to index the rule. A SCHC
	fragmentation, a SCHC packet is always in the form:		compressed packet is always in the form:
	|------- Compressed Header -------|		0 1
	+---------------------------------+--------------------+		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	| RuleID | Compression Residue | Payload |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~
	+---------------------------------+--------------------+		|0 0 RuleID | Compression Residue | Payload
	< 2bytes >		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~
			|------- Compressed Header (byte aligned) ------------|
	Figure 3: SCHC Packet		Figure 3: SCHC Compressed Packet
			This specification only supports the No-ACK Mode of SCHC
			fragmentation as specified in section 8.4.1 of [SCHC]. The SCHC
			Fragment Header is 2 bytes long.
			The RuleID for a fragmenation rule is expressed as 4 bits. The
			bits MUST all set to 1 for a fragmentation rule in No-ACK Mode.
			The DTag field is 11 bits long (T=11) and the FCN field is one bit
			(N=1), which is set to 1 on the last fragment as illustrated in
			Appendix B of [SCHC] and to 0 otherwise. There is no W field
			(M=0).
			0 1
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~
			|1 1 1 1| DTag |F| Fragment Payload | padding
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~
			|--------- T ---------|N|
			|---- SCHC Fragment Header ----|
			Figure 4: SCHC Fragment
			The No-ACK mode has been designed under the assumption that data
			unit out-of-sequence delivery does not occur between the entity
			performing fragmentation and the entity performing reassembly and
			a DetNet PREOF function might be needed to reorder the fragments.
	Maximum packet size: MAX_PACKET_SIZE is aligned to the PPP Link MTU.		Maximum packet size: MAX_PACKET_SIZE is aligned to the PPP Link MTU.
	Padding: The L2 word is one byte, so padding is up to the next byte		Padding: The Compression Residue MUST be aligned to the L2 word.
	boundary. The padding bit is a 0.		For Ethernet, the L2 word is one byte, so padding is needed up to
			the next byte boundary. If a compression rule produces a residue
			that is not byte aligned, then it is implicitly terminated with a
			statement that indicates padding till the next byte boundary. The
			padding bit is 0.
	4.2.1. Resulting Packet Format		4.2.1. Resulting Packet Format
	In the case of PPPoE, the sequence of compression and encapsulation		In the case of PPPoE, the sequence of compression and encapsulation
	is as follows:		is as follows:
	A packet (e.g., an IPv6 packet)		A packet (e.g., an IPv6 packet)
	| ^ (padding bits		| ^ (padding bits
	v | dropped)		v | dropped)
	+------------------+ +--------------------+		+------------------+ +--------------------+
	| SCHC Compression | | SCHC Decompression |		| SCHC Compression | | SCHC Decompression |
	+------------------+ +--------------------+		+------------------+ +--------------------+
	| ^		| ^
	| (No fragmentation) |		+-- No -+ |
			| fragmentation | +------------------>+
			v | | |
			+--------------------+ | | +-------------------+
			| SCHC Fragmentation | | | | SCHC Reassembly |
			+--------------------+ | | +-------------------+
			| | | ^
			+<------------------+ | No |
			| +-- fragmentation -+
	v |		v |
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	| PPP Session encaps | | PPP Session decaps |		| PPP Session encaps | | PPP Session decaps |
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	| ^		| ^
	| |		| |
	v |		v |
	+------------------+ +------------------+		+------------------+ +------------------+
	| PPPoE(oE) encaps | | PPPoE(oE) encaps |		| PPPoE(oE) encaps | | PPPoE(oE) encaps |
	+------------------+ +------------------+		+------------------+ +------------------+
	| ^		| ^
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	Sender Receiver		Sender Receiver
	Figure 4: Stack Operation		Figure 5: Stack Operation (no fragment)
	In the case of PPPoE, a frame that transports an IPv6 packet		In the case of PPPoE, a frame that transports an IPv6 packet
	compressed with SCHC shows as follows:		compressed with SCHC with no fragmentation shows as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 |		| Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID | Length |		| Session ID | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PPP Protocol (IPv6CP) = 0x8057 | SCHC Rule |		| PPP Protocol (IPv6) = 0x0057 |0|0| SCHC RuleID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	... Compression ...		... Compression ...
	| Residue +-+-+-+		| Residue +-+-+-+
	| | Pad |		| | Pad |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |		| |
	| Uncompressed |		| Uncompressed |
	... Original ...		... Original ...
	| Payload |		| Payload |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: SCHC over PPP over Ethernet Format		Figure 6: SCHC over PPP over Ethernet Format
	4.3. Security Considerations		4.3. Security Considerations
	This draft enables to use the SCHC compression and fragmentation over		This draft enables to use the SCHC compression and fragmentation over
	PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the		PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the
	possible threats against SCHC listed in the "Security considerations"		possible threats against SCHC listed in the "Security considerations"
	section of [SCHC].		section of [SCHC].
	5. IANA Considerations		5. IANA Considerations
	skipping to change at page 8, line 8 ¶		skipping to change at page 9, line 8 ¶
	Zúñiga, "SCHC: Generic Framework for Static Context Header		Zúñiga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/info/rfc8724>.		<https://www.rfc-editor.org/info/rfc8724>.
	8. Informative References		8. Informative References
	[SCHC_DATA_MODEL]		[SCHC_DATA_MODEL]
	Minaburo, A. and L. Toutain, "Data Model for Static		Minaburo, A. and L. Toutain, "Data Model for Static
	Context Header Compression (SCHC)", Work in Progress,		Context Header Compression (SCHC)", Work in Progress,
	Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-02,		Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-03,
	28 February 2020, <https://tools.ietf.org/html/draft-ietf-		10 July 2020, <https://tools.ietf.org/html/draft-ietf-
	lpwan-schc-yang-data-model-02>.		lpwan-schc-yang-data-model-03>.
	[RAW Technologies]		[RAW Technologies]
	Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,		Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
	and J. Farkas, "Reliable and Available Wireless		and J. Farkas, "Reliable and Available Wireless
	Technologies", Work in Progress, Internet-Draft, draft-		Technologies", Work in Progress, Internet-Draft, draft-
	thubert-raw-technologies-05, 18 May 2020,		thubert-raw-technologies-05, 18 May 2020,
	<https://tools.ietf.org/html/draft-thubert-raw-		<https://tools.ietf.org/html/draft-thubert-raw-
	technologies-05>.		technologies-05>.
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.		<https://www.rfc-editor.org/info/rfc7951>.
	[DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas,		[DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
			[IEEE802.1TSNTG]
			IEEE, "Time-Sensitive Networking (TSN) Task Group",
			<https://1.ieee802.org/tsn/>.
	Author's Address		Author's Address
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	06254 Mougins - Sophia Antipolis		06254 Mougins - Sophia Antipolis
	France		France
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
End of changes. 22 change blocks.
	67 lines changed or deleted		117 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/