< draft-bryant-pwe3-packet-pw-03.txt		draft-bryant-pwe3-packet-pw-04.txt >
	Network Working Group S. Bryant, Ed.		Network Working Group S. Bryant, Ed.
	Internet-Draft L. Martini		Internet-Draft L. Martini
	Intended status: BCP G. Swallow		Intended status: BCP G. Swallow
	Expires: September 9, 2010 Cisco Systems		Expires: January 9, 2011 Cisco Systems
	A. Malis		A. Malis
	Verizon Communications		Verizon Communications
	March 8, 2010		July 8, 2010
	Packet Pseudowire Encapsulation over an MPLS PSN		Packet Pseudowire Encapsulation over an MPLS PSN
	draft-bryant-pwe3-packet-pw-03.txt		draft-bryant-pwe3-packet-pw-04.txt
	Abstract		Abstract
	This document describes a pseudowire mechanism that is used to		This document describes a pseudowire mechanism that is used to
	transport a packet service over an MPLS PSN is the case where the		transport a packet service over an MPLS PSN is the case where the
	client LSR and the server PE are co-resident in the same equipment.		client LSR and the server PE are co-resident in the same equipment.
	This pseudowire mechanism may be used to carry all of the required		This pseudowire mechanism may be used to carry all of the required
	layer 2 and layer 3 protocols between the pair of client LSRs.		layer 2 and layer 3 protocols between the pair of client LSRs.
	Requirements Language		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 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	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 January 9, 2011.
	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 September 9, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Network Reference Model . . . . . . . . . . . . . . . . . . . 3		2. Network Reference Model . . . . . . . . . . . . . . . . . . . 3
	3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4		3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4
	4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5		4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Design Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. Encapsulation Approaches Considered . . . . . . . . . . . . . 7		6. Encapsulation Approaches Considered . . . . . . . . . . . . . 7
	6.1. A Protocol Identifier in the Control Word . . . . . . . . 7		6.1. A Protocol Identifier in the Control Word . . . . . . . . 7
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 26 ¶
	+-------------------------------+		+-------------------------------+
	| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)		| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
	+-------------------------------+		+-------------------------------+
	Figure 3: Encapsulation of a pseudowire with a pseudowire load		Figure 3: Encapsulation of a pseudowire with a pseudowire load
	balancing label		balancing label
	In the PID Label approach a new Label Distribution protocol (LDP)		In the PID Label approach a new Label Distribution protocol (LDP)
	Forwarding Equivalence Class (FEC) element is used to signal the		Forwarding Equivalence Class (FEC) element is used to signal the
	mapping between protocol type and the PID label. This approach		mapping between protocol type and the PID label. This approach
	complies with RFC3031 and is the approach described in Section 3.4.3		complies with RFC3031.
	of [I-D.ietf-mpls-tp-framework] .
			A similar approach to PID label is described in Section 3.4.5 of
			[I-D.ietf-mpls-tp-framework]. In this case when the client is a
			network layer packet service such as IP or MPLS, a service label and
			demultiplexer label (which may be combined) is used to provide the
			necessary identifications needed to carry this traffic over an LSP.
	The authors surveyed the hardware designs produced by a number of		The authors surveyed the hardware designs produced by a number of
	companies across the industry and concluded that whilst the approach		companies across the industry and concluded that whilst the approach
	complies with the MPLS architecture, it may conflict with a number of		complies with the MPLS architecture, it may conflict with a number of
	designer's interpretation of the existing MPLS architecture. This		designer's interpretation of the existing MPLS architecture. This
	led to concerns that the approach may result in unexpected		led to concerns that the approach may result in unexpected
	difficulties in the future. Specifically there is an assumption in		difficulties in the future. Specifically there is an assumption in
	many designs that a forwarding decision should be made on the basis		many designs that a forwarding decision should be made on the basis
	of a single label. Whilst the approach is attractive, it cannot be		of a single label. Whilst the approach is attractive, it cannot be
	supported by many commodity chip sets and this would require new		supported by many commodity chip sets and this would require new
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 17 ¶
	[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,		[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
	"Encapsulation Methods for Transport of Ethernet over MPLS		"Encapsulation Methods for Transport of Ethernet over MPLS
	Networks", RFC 4448, April 2006.		Networks", RFC 4448, April 2006.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-mpls-tp-framework]		[I-D.ietf-mpls-tp-framework]
	Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.		Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
	Berger, "A Framework for MPLS in Transport Networks",		Berger, "A Framework for MPLS in Transport Networks",
	draft-ietf-mpls-tp-framework-10 (work in progress),		draft-ietf-mpls-tp-framework-12 (work in progress),
	February 2010.		May 2010.
	[I-D.ietf-pwe3-fat-pw]		[I-D.ietf-pwe3-fat-pw]
	Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,		Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
	J., and S. Amante, "Flow Aware Transport of Pseudowires		J., and S. Amante, "Flow Aware Transport of Pseudowires
	over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in		over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in
	progress), January 2010.		progress), January 2010.
	[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for		[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
	Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,		Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
	September 2004.		September 2004.
End of changes. 9 change blocks.
	19 lines changed or deleted		18 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/