< draft-ietf-pwe3-fcs-retention-03.txt		draft-ietf-pwe3-fcs-retention-04.txt >
	Internet Draft Andrew G. Malis		Internet Draft Andrew G. Malis
	Document: draft-ietf-pwe3-fcs-retention-03.txt Tellabs		Document: draft-ietf-pwe3-fcs-retention-04.txt Tellabs
	Expires: August 2005 David Allan		Expires: March 2006 David Allan
	Nortel Networks		Nortel Networks
	Nick Del Regno		Nick Del Regno
	MCI		MCI
	February 2005		September 2005
	PWE3 Frame Check Sequence Retention		PWE3 Frame Check Sequence Retention
	IPR Statement		IPR Statement
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	or will be disclosed, and any of which I become aware will be		have been or will be disclosed, and any of which he or she becomes
	disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Status of this Memo		Status of this Memo
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress".		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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Abstract		Abstract
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Ethernet, Frame Relay, and HDLC pseudowires.		Ethernet, Frame Relay, and HDLC pseudowires.
	Table of Contents		Table of Contents
	1. Intellectual Property Statement...............................2		1. Intellectual Property Statement...............................2
	2. Specification of Requirements.................................2		2. Specification of Requirements.................................2
	3. Overview......................................................2		3. Overview......................................................2
	4. Signaling FCS Retention With MPLS-based Pseudowires...........4		4. Signaling FCS Retention With MPLS-based Pseudowires...........4
	5. Signaling FCS Retention With L2TPv3-based Pseudowires.........5		5. Signaling FCS Retention With L2TPv3-based Pseudowires.........5
	6. Security Considerations.......................................5		6. Security Considerations.......................................5
	PWE3 FCS Retention February 2005		PWE3 FCS Retention September 2005
	7. Applicability Statement.......................................6		7. Applicability Statement.......................................6
	8. IANA Considerations...........................................6		8. IANA Considerations...........................................6
	9. Acknowledgement...............................................7		9. Acknowledgement...............................................7
	10. Normative References.........................................7		10. Normative References.........................................7
	11. Full Copyright Statement.....................................8		11. Full Copyright Statement.....................................8
	12. Authors' Addresses...........................................8		12. Authors' Addresses...........................................8
	1. Intellectual Property Statement		1. 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		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology		to pertain to the implementation or use of the technology described
	described in this document or the extent to which any license		in this document or the extent to which any license under such
	under such rights might or might not be available; nor does it		rights might or might not be available; nor does it represent that
	represent that it has made any independent effort to identify any		it has made any independent effort to identify any such rights.
	such rights. Information on the procedures with respect to rights		Information on the procedures with respect to rights in RFC
	in RFC documents can be found in BCP 78 and BCP 79.		documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention		The IETF invites any interested party to bring to its attention any
	any copyrights, patents or patent applications, or other		copyrights, patents or patent applications, or other proprietary
	proprietary rights that may cover technology that may be required		rights that may cover technology that may be required to implement
	to implement this standard. Please address the information to the		this standard. Please address the information to the IETF at ietf-
	IETF at ietf-ipr@ietf.org.		ipr@ietf.org.
	2. Specification of Requirements		2. Specification of Requirements
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [6].		this document are to be interpreted as described in RFC 2119 [6].
	3. Overview		3. Overview
	The specifications for Ethernet, Frame Relay, HDLC, and PPP		The specifications for Ethernet, Frame Relay, HDLC, and PPP
	pseudowire encapsulation [1] [2] [3] include a mode of use where		pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode
	frames are transparently delivered across the pseudowire without		of use where frames are transparently delivered across the
	any header or other alterations by the pseudowire ingress or egress		pseudowire without any header or other alterations by the
	Provider Edge (PE). [Note that this mode is inherent for HDLC and		pseudowire ingress or egress Provider Edge (PE). [Note that this
	PPP Pseudowires.]		mode is inherent for HDLC and PPP Pseudowires.]
	PWE3 FCS Retention February 2005		PWE3 FCS Retention September 2005
	However, these specifications all specify that the original Frame		However, these specifications all specify that the original Frame
	Check Sequence (FCS) be removed at ingress and regenerated at		Check Sequence (FCS) be removed at ingress and regenerated at
	egress, which means that the frames may be subject to unintentional		egress, which means that the frames may be subject to unintentional
	alteration during their traversal of the pseudowire from the		alteration during their traversal of the pseudowire from the
	ingress to the egress PE. Thus, the pseudowire cannot be		ingress to the egress PE. Thus, the pseudowire cannot be
	absolutely guaranteed to be "transparent" in nature.		absolutely guaranteed to be "transparent" in nature.
	To be more precise, pseudowires, as currently defined, leave the		To be more precise, pseudowires, as currently defined, leave the
	payload vulnerable to undetected errors caused by the encapsulating		payload vulnerable to undetected errors caused by the encapsulating
	network. As defined for MPLS, not only can a PW-aware device		network. Not only can a PW-aware device internally corrupt an
	internally corrupt an encapsulated payload, but ANY MPLS LSR in the		encapsulated payload, but ANY LSR or router in the path can corrupt
	path can corrupt the encapsulated payload. In the event of such		the encapsulated payload. In the event of such corruption, there is
	corruption, there is no way to detect the corruption through		no way to detect the corruption through the path of the pseudowire.
	the path of the pseudowire. Further, because the FCS is calculated		Further, because the FCS is calculated upon network egress, any
	upon network egress, any corruption will pass transparently through		corruption will pass transparently through ALL Layer 2 switches
	ALL Layer 2 switches(Ethernet and Frame Relay) through which the		(Ethernet and Frame Relay) through which the packets travel. Only
	packets travel. Only at the endpoint, assuming the corrupted packet		at the endpoint, assuming the corrupted packet even reaches the
	even reaches the correct endpoint, can the packet be discarded, and		correct endpoint, can the packet be discarded, and depending on the
	depending on the contents of the packet, the corruption may not		contents of the packet, the corruption may not ever be detected.
	ever be detected.
	Not only does the encapsulation technique leave the payload		Not only does the encapsulation technique leave the payload
	unprotected, it also subverts the error checking mechanisms already		unprotected, it also subverts the error checking mechanisms already
	in place in SP and customer networks by calculating FCS on		in place in SP and customer networks by calculating FCS on
	questionable data.		questionable data.
	In a perfect network comprising perfect equipment, this is not an		In a perfect network comprising perfect equipment, this is not an
	issue. However, as there is no such thing, it is an issue. SPs		issue. However, as there is no such thing, it is an issue. SPs
	should have the option of saving overhead by yielding the ability		should have the option of saving overhead by yielding the ability
	to detect faults. Equally, SPs should have the option to sacrifice		to detect faults. Equally, SPs should have the option to sacrifice
	the overhead of carrying the original FCS end-to-end to ensure the		the overhead of carrying the original FCS end-to-end to ensure the
	ability to detect faults in the encapsulating network.		ability to detect faults in the encapsulating network.
	This document defines such a mechanism to allow the ingress PE to		This document defines such a mechanism to allow the ingress PE to
	retain the original frame FCS on ingress to the network, and		retain the original frame FCS on ingress to the network, and
	relieves the egress PE of the task of regenerating the FCS.		relieves the egress PE of the task of regenerating the FCS.
	This in an OPTIONAL mechanism for pseudowire implementations. For		This is an OPTIONAL mechanism for pseudowire implementations. For
	interoperability with systems that do not implement this document,		interoperability with systems that do not implement this document,
	the default behavior is that the FCS is removed at the ingress PE		the default behavior is that the FCS is removed at the ingress PE
	and regenerated at the egress PE, as specified in [1], [2], and		and regenerated at the egress PE, as specified in [1], [2], and
	[3].		[3].
			This capability may be used only with Ethernet pseudowires that use
			"raw mode" [1], Frame Relay pseudowires that use "port mode" [2]
			[3], and HDLC and PPP pseudowires [3].
	Note that this mechanism is not intended to carry errored frames		Note that this mechanism is not intended to carry errored frames
	through the pseudowire; as usual, the FCS MUST be examined at the		through the pseudowire; as usual, the FCS MUST be examined at the
			PWE3 FCS Retention September 2005
	ingress PE and errored frames MUST be discarded. The FCS MAY also		ingress PE and errored frames MUST be discarded. The FCS MAY also
	be examined by the egress PE; if this is done, errored frames MUST		be examined by the egress PE; if this is done, errored frames MUST
	PWE3 FCS Retention February 2005
	be discarded. The egress PE MAY also wish to generate an alarm or		be discarded. The egress PE MAY also wish to generate an alarm or
	count the number of errored frames.		count the number of errored frames.
	4. Signaling FCS Retention With MPLS-based Pseudowires		4. Signaling FCS Retention With MPLS-based Pseudowires
	When using the signaling procedures in [4], there is a Pseudowire		When using the signaling procedures in [4], there is a Pseudowire
	Interface Parameter Identifier value used to signal the desire to		Interface Parameter Sub-TLV type used to signal the desire to
	retain the FCS when advertising a VC label [5]:		retain the FCS when advertising a VC label [5]:
	Parameter ID ID Length Description		Parameter Length Description
	0x0A 4 FCS Retention Indicator		0x0A 4 FCS Retention Indicator
	The presence of this parameter ID indicates that the egress PE		The presence of this parameter indicates that the egress PE
	requests the ingress PE to retain the FCS for the VC label being		requests the ingress PE to retain the FCS for the VC label being
	advertised. It does not obligate the ingress PE to retain the FCS;		advertised. It does not obligate the ingress PE to retain the FCS;
	it is simply an indication that the ingress PE MAY retain the FCS.		it is simply an indication that the ingress PE MAY retain the FCS.
	The sender MUST NOT retain the FCS if this parameter ID is not		The sender MUST NOT retain the FCS if this parameter is not present
	present in the VC FEC element.		in the VC FEC element.
	The parameter includes a 16-bit FCS length field, which indicates		The parameter includes a 16-bit FCS length field, which indicates
	the length of the original FCS being retained. For Ethernet		the length of the original FCS being retained. For Ethernet
	pseudowires, this length will always be set to 4. For HDLC, PPP,		pseudowires, this length will always be set to 4. For HDLC, PPP,
	and Frame Relay pseudowires, this length will be set to either 2 or		and Frame Relay pseudowires, this length will be set to either 2 or
	4. Since the FCS length on these interfaces is a local setting,		4. Since the FCS length on these interfaces is a local setting,
	retaining the FCS only makes sense if the FCS length is identical		retaining the FCS only makes sense if the FCS length is identical
	on both ends of the pseudowire. Including the FCS length in this		on both ends of the pseudowire. Including the FCS length in this
	parameter allows the PEs to ensure that the FCS is only retained		parameter allows the PEs to ensure that the FCS is only retained
	when it makes sense.		when it makes sense.
	Since unknown parameter IDs are silently ignored [4], backwards		Since unknown parameters are silently ignored [4], backwards
	compatibility with systems that do not implement this document is		compatibility with systems that do not implement this document is
	provided by requiring that the FCS is retained ONLY if the FCS		provided by requiring that the FCS is retained ONLY if the FCS
	Retention Indicator with an identical setting for the FCS length		Retention Indicator with an identical setting for the FCS length
	has been included in the advertisements for both directions on a		has been included in the advertisements for both directions on a
	pseudowire.		pseudowire.
	If the ingress PE recognizes the FCS Retention Indicator parameter		If the ingress PE recognizes the FCS Retention Indicator parameter,
	ID, but does not wish to retain the FCS with the indicated length,		but does not wish to retain the FCS with the indicated length, it
	it need only issue its own label mapping message for the opposite		need only issue its own label mapping message for the opposite
	direction without including the FCS Retention Indicator. This will		direction without including the FCS Retention Indicator. This will
	prevent FCS retention in either direction.		prevent FCS retention in either direction.
	If PWE3 signaling [4] is not in use for a pseudowire, then whether		If PWE3 signaling [4] is not in use for a pseudowire, then whether
	or not the FCS is to be retained MUST be identically provisioned in		or not the FCS is to be retained MUST be identically provisioned in
	both PEs at the pseudowire endpoints. If there is no provisioning		both PEs at the pseudowire endpoints. If there is no provisioning
	support for this option, the default behavior is to remove the FCS.		support for this option, the default behavior is to remove the FCS.
	PWE3 FCS Retention February 2005		PWE3 FCS Retention September 2005
	5. Signaling FCS Retention With L2TPv3-based Pseudowires		5. Signaling FCS Retention With L2TPv3-based Pseudowires
	When using the signaling procedures in [7], the FCS Retention AVP,		When using the signaling procedures in [7], the FCS Retention AVP,
	Attribute Type L2TP-TBA-1, is used.		Attribute Type L2TP-TBA-1, is used.
	The Attribute Value field for this AVP has the following format:		The Attribute Value field for this AVP has the following format:
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FCS Length |		| FCS Length |
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	and Frame Relay pseudowires, this length will be set to either 2 or		and Frame Relay pseudowires, this length will be set to either 2 or
	4. Since the FCS length on these interfaces is a local setting,		4. Since the FCS length on these interfaces is a local setting,
	retaining the FCS only makes sense if the FCS length is identical		retaining the FCS only makes sense if the FCS length is identical
	on both ends of the pseudowire. Including the FCS length in this		on both ends of the pseudowire. Including the FCS length in this
	AVP allows the PEs to ensure that the FCS is only retained when it		AVP allows the PEs to ensure that the FCS is only retained when it
	makes sense.		makes sense.
	The Length of this AVP is 8. The M bit for this AVP MUST be set to		The Length of this AVP is 8. The M bit for this AVP MUST be set to
	0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).		0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).
	6. Security Considerations		6. Security Considerations
	This mechanism enhances the data integrity of transparent Ethernet,		This mechanism enhances the data integrity of transparent Ethernet,
	Frame Relay, and HDLC pseudowires, because the original FCS, as		Frame Relay, and HDLC pseudowires, because the original FCS, as
	generated by the Customer Edge (CE), is included in the		generated by the Customer Edge (CE), is included in the
	encapsulation. When the encapsulated payload passes FCS checking		encapsulation. When the encapsulated payload passes FCS checking
	at the destination CE, it is clear that the payload was not altered		at the destination CE, it is clear that the payload was not altered
	during its transmission through the network (or at least to the		during its transmission through the network (or at least to the
			PWE3 FCS Retention September 2005
	accuracy of the original FCS; but that is demonstratably better		accuracy of the original FCS; but that is demonstratably better
	than no FCS at all).		than no FCS at all).
	PWE3 FCS Retention February 2005
	Of course, nothing comes for free; this requires the additional		Of course, nothing comes for free; this requires the additional
	overhead of carrying the original FCS (in general, either two or		overhead of carrying the original FCS (in general, either two or
	four octets per payload packet).		four octets per payload packet).
	This signaling is backwards compatible and interoperable with		This signaling is backwards compatible and interoperable with
	systems that do not implement this document.		systems that do not implement this document.
	7. Applicability Statement		7. Applicability Statement
	In general, this document is intended to further extend the		In general, this document is intended to further extend the
	applicability of the services defined by [1], [2], and [3] to make		applicability of the services defined by [1], [2], and [3] to make
	them more suitable for use in deployments where data integrity is		them more suitable for use in deployments where data integrity is
	an issue (or at least, is as much an issue as in the original		an issue (or at least, is as much an issue as in the original
	services that defined the FCS usage in the first place). There are		services that defined the FCS usage in the first place). There are
	some situations where this extension is not necessary, such as		some situations where this extension is not necessary, such as
	where the inner payloads have their own error-checking capabilities		where the inner payloads have their own error-checking capabilities
	(such as TCP). But for inner payloads that do rely on the error-		(such as TCP). But for inner payloads that do rely on the error-
	detecting capabilities of the link layer (such as SNA), this		detecting capabilities of the link layer (such as SNA), this
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 46 ¶
	Other mechanisms may include the use of end-to-end IPSec between		Other mechanisms may include the use of end-to-end IPSec between
	the PEs, or internal mechanisms in the P routers to assure the		the PEs, or internal mechanisms in the P routers to assure the
	integrity of packets as they are switched between ingress and		integrity of packets as they are switched between ingress and
	egress interfaces. Service providers may wish to compare the		egress interfaces. Service providers may wish to compare the
	relative strengths of each approach when planning their pseudowire		relative strengths of each approach when planning their pseudowire
	deployments; however, an argument can be made that it may be		deployments; however, an argument can be made that it may be
	wasteful for a SP to use an end-to-end integrity mechanism that is		wasteful for a SP to use an end-to-end integrity mechanism that is
	STRONGER than the FCS generated by the source CE and checked by the		STRONGER than the FCS generated by the source CE and checked by the
	destination CE.		destination CE.
	8. IANA Considerations		8. IANA Considerations
	This document does not specify any new registries for IANA to		This document does not specify any new registries for IANA to
	maintain.		maintain.
	This document requires IANA to allocate a PWE3 Virtual Circuit FEC		Note that [5] allocates the FCS Retention Indicator interface
	element parameter ID [5].		parameter, so no further IANA action is required.
	PWE3 FCS Retention February 2005		PWE3 FCS Retention September 2005
	This specification also requires one value within the L2TP "Control		This specification does require IANA to assign one value within the
	Message Attribute Value Pairs" section to be assigned by IANA as		L2TP "Control Message Attribute Value Pairs" section as per [8].
	per [8]. The new AVP is encoded as L2TP-TBA-1 in this document, and		The new AVP is encoded as L2TP-TBA-1 in this document, and should
	should be referred to in the IANA L2TP parameters registry as "FCS		be referred to in the IANA L2TP parameters registry as "FCS
	Retention."		Retention."
	9. Acknowledgement		9. Acknowledgement
	The authors would like to thank Mark Townsley for the text in		The authors would like to thank Mark Townsley for the text in
	section 5.		section 5.
	10. Normative References		10. Normative References
	[1] Martini, L. et al, "Encapsulation Methods for Transport of		[1] Martini, L. et al, "Encapsulation Methods for Transport
	Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3-		of Ethernet Frames Over IP and MPLS Networks", draft-ietf-
	ethernet-encap-08.txt, September 2004, work in progress		pwe3-ethernet-encap-10.txt, June 2005, work in progress
	[2] Martini, L. et al, "Frame Relay Encapsulation over Pseudo-		[2] Martini, L. et al, "Frame Relay Encapsulation over
	Wires", draft-ietf-pwe3-frame-relay-03.txt, August 2004,		Pseudo-Wires", draft-ietf-pwe3-frame-relay-05.txt, April
	work in progress		2005, work in progress
	[3] Martini, L. et al, "Encapsulation Methods for Transport of		[3] Martini, L. et al, "Encapsulation Methods for Transport
	PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3-		of PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-
	hdlc-ppp-encap-mpls-03.txt, April 2004, work in progress		pwe3-hdlc-ppp-encap-mpls-05.txt, May 2005, work in progress
	[4] Martini, L. et al, "Transport of Layer 2 Frames Over MPLS",		[4] Martini, L. et al, "Pseudowire Setup and Maintenance using the
	draft-ietf-pwe3-control-protocol-14.txt, December 2004, work		Label Distribution Protocol", draft-ietf-pwe3-control-protocol-
	in progress		17.txt, June 2005, work in progress
	[5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge to		[5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge
	Edge Emulation (PWE3)", draft-ietf-pwe3-iana-		to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-
	allocation-07.txt, October 2004, work in progress		11.txt, June 2005, work in progress
	[6] Bradner, S., "Key words for use in RFCs to Indicate		[6] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[7] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling		[7] Lau, J., et al, "Layer Two Tunneling Protocol - Version
	Protocol (Version 3)", work in progress, draft-ietf-l2tpext-		3 (L2TPv3)", RFC 3931, March 2005.
	l2tp-base-15.txt, December 2004, work in progress
	[8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet		[8] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
	Assigned Numbers Authority (IANA) Considerations Update",		Internet Assigned Numbers Authority (IANA)
	RFC 3438, December 2002.		Considerations Update", RFC 3438, December 2002.
	PWE3 FCS Retention February 2005		[9] Aggarwal, R. et al, "Transport of Ethernet Frames over L2TPv3",
			draft-ietf-l2tpext-pwe3-ethernet-03.txt, April 2005, work in
			progress
			PWE3 FCS Retention September 2005
	11. Full Copyright Statement		[10]Townsley, W. et al, "Frame-Relay over L2TPv3", draft-ietf-
			l2tpext-pwe3-fr-06.txt, June 2005, work in progress
	Copyright (C) The Internet Society (2005). This document is		[11]Pignataro, C. et al, "HDLC Frames over L2TPv3", draft-ietf-
	subject to the rights, licenses and restrictions contained in BCP		l2tpext-pwe3-hdlc-06.txt, June 2005, work in progress
	78 and except as set forth therein, the authors retain all their
	rights.		11. Full Copyright Statement
			Copyright (C) The Internet Society (2005).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.		PARTICULAR PURPOSE.
	12. Authors' Addresses		12. Authors' Addresses
	Andrew G. Malis		Andrew G. Malis
	Tellabs		Tellabs
	90 Rio Robles Dr.		90 Rio Robles Dr.
	San Jose, CA 95134		San Jose, CA 95134
	Email: Andy.Malis@tellabs.com		Email: Andy.Malis@tellabs.com
	David Allan		David Allan
	Nortel Networks		Nortel Networks
	3500 Carling Ave.		3500 Carling Ave.
End of changes. 49 change blocks.
	99 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/