< draft-ietf-pwe3-requirements-00.txt		draft-ietf-pwe3-requirements-01.txt >
	Internet Draft XiPeng Xiao		Internet Draft XiPeng Xiao
	Document: draft-ietf-pwe3-requirements-00.txt Photuris Inc.		Document: draft-ietf-pwe3-requirements-01.txt Photuris Inc.
	Expires: November 17, 2001 Danny McPherson		Expires: January 2002 Danny McPherson
	Amber Networks		Amber Networks
	Prayson Pate		Prayson Pate
	Overture Networks, Inc.		Overture Networks, Inc.
	Craig White		Craig White
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks, Inc.		Juniper Networks, Inc.
			Vijay Gill
			Metromedia Fiber Network, Inc.
			Thomas D. Nadeau
			Cisco Systems, Inc.
	Requirements for		Requirements for Pseudo-Wre Emulation Edge-to-Edge (PWE3)
	Pseudo Wire Emulation Edge-to-Edge (PWE3)		draft-ietf-pwe3-requirements-01.txt
	draft-ietf-pwe3-requirements-00.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	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
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	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
	This document describes generic requirements for Pseudo-Wire		This document describes generic requirements for Pseudo-Wire
	Emulation Edge to Edge. It provides guidelines for other working		Emulation Edge to Edge (PWE3). It provides guidelines for other
	group documents that will define mechanisms for providing pseudo-wire		working group documents that will define mechanisms for providing
	emulation of specific services such as Ethernet, PPP, (Cisco) HDLC,		pseudo-wire emulation of specific services such as Ethernet, ATM,
	ATM, Frame Relay and TDM. It should be noted that the PWE3 Working		Frame Relay, TDM, and MPLS. It should be noted that the PWE3 Working
	Group (WG) standardizes mechanisms that can be used to provide		Group (PWE3 WG) standardizes mechanisms that can be used to provide
	pseudo-wire emulation services, but not the services themselves.		PWE3 services, but not the services themselves.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	Table of Contents		Table of Contents
	1 Introduction ................................................. 4		1 Introduction ................................................. 4
	1.1 Reference Model of Pseudo-Wire Emulation Edge to Edge		1.1 Reference Model of PWE3 .................................... 4
	(PWE3) .................................................... 4
	1.2 Terminology ................................................ 5		1.2 Terminology ................................................ 5
	2 PDU Encapsulation ............................................ 6		2 PDU Encapsulation ............................................ 6
	2.1 Conveyance of Necessary L2/L1 Header Information ........... 6		2.1 Conveyance of Necessary L2/L1 Header Information ........... 7
	2.2 Location of the Pseudo-Wire Header ......................... 6		2.2 PDU Length ................................................. 7
	2.3 PDU Length ................................................. 6		2.3 Encapsulation of Control Messages of the Native Services
	2.4 Encapsulation of Signaling Messages of the Native		........................................................... 7
	Services .................................................. 7		2.4 Support for Circuit Multiplexing ........................... 7
	2.5 Timing Information ......................................... 7		2.5 Packet Ordering ............................................ 7
	2.6 Support for Circuit Multiplexing ........................... 7		2.6 Packet Duplication ......................................... 7
	2.7 Packet Ordering ............................................ 7		3 Carrying the PW PDUs over a Packet-Switched Network .......... 8
	3 Packet Transport ............................................. 7		3.1 Setup of Pseudo-Wires ...................................... 8
	3.1 Setup of Pseudo-Wires ...................................... 7
	3.2 Pseudo-Wire MTU ............................................ 8		3.2 Pseudo-Wire MTU ............................................ 8
	3.3 Transport of Signaling Messages of the Native Services ..... 8		3.3 Carrying Control Messages of the Native Services ........... 8
	3.4 Transport Efficiency ....................................... 9		3.4 PSN Tunnel Header Overhead ................................. 9
	4 Faithfulness of Emulated Services ............................ 9		4 Faithfulness of Emulated Services ............................ 9
	4.1 Characteristics of an Emulated Service ..................... 9		4.1 Characteristics of an Emulated Service ..................... 9
	4.2 Service Quality of Emulated Services ....................... 10		4.2 Service Quality of Emulated Services ....................... 10
	4.3 Signaling of Native Services ............................... 10
	5 Maintenance of Emulated Services ............................. 10		5 Maintenance of Emulated Services ............................. 10
	5.1 Signaling of Status Changes of an Emulated Service ......... 10		5.1 Keep-alive ................................................. 10
	5.1.1 Up/Down Notification ..................................... 10		5.2 Status Monitoring .......................................... 10
	5.1.2 Packet Loss and/or Out-of-order Delivery ................. 11		5.3 Notification of Status Changes ............................. 11
	5.1.3 Other Status Signaling ................................... 11		5.3.1 Up/Down Notification ..................................... 11
	5.1.4 Collective Status Signaling .............................. 11		5.3.2 Misconnection and Payload Mistype ........................ 11
	5.2 Clock Recovery ............................................. 12		5.3.3 Packet Loss, Corruption, and Out-of-order Delivery ....... 11
			5.3.4 Other Status Notification ................................ 11
			5.3.5 Collective Status Notification ........................... 11
			5.4 Clock Recovery ............................................. 12
	6 Management of Emulated Services .............................. 12		6 Management of Emulated Services .............................. 12
	6.1 MIB ........................................................ 12		6.1 MIBs ....................................................... 12
	6.2 Pseudo-Wire Traceroute ..................................... 12		6.2 General MIB Requirements ................................... 12
	7 Scalability .................................................. 12		6.3 Configuration and Provisioning ............................. 13
	8 Other Generic Requirements ................................... 13		6.4 Performance Monitoring ..................................... 13
			6.5 Fault Management and Notifications ......................... 13
			6.6 Pseudo-Wire Traceroute ..................................... 13
			7 Scalability .................................................. 13
			8 Other Generic Requirements ................................... 14
			8.1 RFC 2914 Conformance ....................................... 14
	9 Non-Requirements ............................................. 14		9 Non-Requirements ............................................. 14
	10 Quality of Service (QoS) Considerations ..................... 14		10 Quality of Service (QoS) Considerations ..................... 15
	11 Inter-domain Pseudo-Wires ................................... 15		11 Inter-domain Pseudo-Wires ................................... 15
	12 Security Considerations ..................................... 15		12 Security Considerations ..................................... 15
	12.1 Security Considerations for the Signaling/Control		12.1 Security Considerations for the Signaling/Control
	Channel ................................................... 15		Channel ................................................... 15
	12.2 Security Considerations for the Encapsulated PDUs ......... 15		12.2 Security Considerations for the PW PDUs ................... 15
	13 Deployment Considerations ................................... 15		13 Deployment Considerations ................................... 16
	14 Acknowledgments ............................................. 15		14 Acknowledgments ............................................. 16
	15 References .................................................. 15		15 References .................................................. 16
	16 Authors' Addresses .......................................... 16		16 Authors' Addresses .......................................... 17
	17 Full Copyright Section ...................................... 18		17 Full Copyright Section ...................................... 19
	1. Introduction		1. Introduction
	1.1. Reference Model of Pseudo-Wire Emulation Edge to Edge (PWE3)		1.1. Reference Model of PWE3
	To provide pseudo-wire emulation, two end-services of the same type		To provide pseudo-wire emulation (PWE), two pseudo-wire end-services
	are first configured between each service endpoint (SE) and the		(PWESs) of the same type are first configured between each customer
	corresponding PWE3 Edge (PE) device (See Figure 1). An end-service		edge (CE) device and the corresponding provider edge (PE) device (See
	is either:		Figure 1). A PWES is either:
	- an Ethernet link between two ports or two VLANs, or		- an Ethernet link or a VLAN link between two ports, or
	- a PPP link, or
	- a (Cisco) HDLC link, or
	- an ATM VC or VP, or		- an ATM VC or VP, or
	- a Frame Relay VC, or		- a Frame Relay VC, or
	- a TDM circuit.		- a TDM circuit, or
			- an MPLS LSP.
	A connection is then set up between the two PEs to connect these two		A connection is then set up between the two PEs to connect these two
	end-services. This connection is called a pseudo-wire in the PWE3		PWESs. This connection is called a pseudo-wire (PW) in the PWE3
	context. During the setup of a pseudo-wire, the two pseudo-wire		context. During the setup of a PW, the two PEs will be configured or
	endpoints will exchange information about the service to be emulated		will automatically exchange information about the service to be
	so that later they know how to handle packets coming from the other		emulated so that later they know how to process packets coming from
	end of the pseudo-wire. After the pseudo-wire is set up, layer-2		the other end. After the PW is set up, layer-2 (e.g. Ethernet, ATM,
	(e.g. Ethernet, ATM and Frame Relay) or layer-1 (e.g. SONET/SDH) PDUs		Frame Relay and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES
	of frames from an end-service are encapsulated at the pseudo-wire		are encapsulated at the PW ingress. The encapsulated PDUs are then
	ingress. The encapsulated PDUs are then transported over the pseudo-		sent over the PW to the egress, where L2 or L1 headers are re-
	wire to the egress, where L2 or L1 header information is re-
	constructed and the resulted frames are forwarded in their native		constructed and the resulted frames are forwarded in their native
	format to the other end-service.		format to the other CE.
	|<--------- pseudo-wire -------->|		|<------- Pseudo Wire ------>|
	end- | | end-		| |
	+-----+ service +------+ +------+ service +-----+		| |<-- PSN Tunnel -->| |
	| SE1 |---------| PE1 |..................| PE2 |---------| SE2 |		PW V V V V PW
	+-----+ +------+ +------+ +-----+		End Service+----+ +----+ End Service
	service PW endpoint 1 PW endpoint 2 service		+-----+ | | PE1|==================| PE2| | +-----+
	endpoint 1 endpoint 2		| |----------|............PW1.............|----------| |
	| |		| CE1 | | | | | | | | CE2 |
	|<---------------- emulated service ---------------->|		| |----------|............PW2.............|----------| |
			+-----+ | | |==================| | | +-----+
			^ +----+ +----+ | ^
			| Provider Edge 1 Provider Edge 2 |
			| |
			|<-------------- Emulated Service ---------------->|
	Figure 1: Pseudo-Wire Reference Model		Customer Customer
			Edge 1 Edge 2
	Different carriers may choose different types of pseudo-wires. For		Figure 1: PWE3 Reference Model
	example, carriers may choose to use GRE tunnels [GRE], L2TP tunnels
	[L2TP], or MPLS LSPs [MPLS] as pseudo-wires. This document does not
	assume that a particular type of pseudo-wires is used. Instead, it
	describes generic requirements that apply to all pseudo-wires, for
	all services including Ethernet, PPP, (Cisco) HDLC, ATM, Frame Relay
	and TDM.
	This document is not an introductory document. Readers are assumed to		This document does not assume that a particular type of PWs is used.
	be familiar with the PWE3 framework document [PATE], especially the		Instead, it describes generic requirements that apply to all PWs, for
	architecture assumptions stated in that document.		all services including Ethernet, ATM, Frame Relay, TDM and MPLS.
			This document is not an introductory document. For an architecture
			overview of PWE3, readers should refer to the PWE3 framework document
			[PATE].
	1.2. Terminology		1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
	"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 RFC 2119.		document are to be interpreted as described in RFC 2119.
	Below are the definitions for the terms used throughout the document.		Below are the definitions for the terms used throughout the document.
	End-Service An End-Service is either an Ethernet link		Packet Switched Network
	between two ports or two VLANs, or a PPP		A Packet Switched Network (PSN) is a network
	link, or a (Cisco) HDLC link, or an ATM VC or		using IP, MPLS or L2TP as the unit of
	VP, or a Frame Relay VC, or a TDM circuit.		switching.
	Pseudo-Wire Emulation Pseudo-Wire Emulation is an approach to		Pseudo Wire Emulation Edge to Edge
	emulate the essential attributes of a service		Pseudo Wire Emulation Edge to Edge (PWE3) is a
	over a packet network so that two remote		mechanism that emulates the essential
	end-services appear directly connected by a		attributes of a service (such as a T1 leased
	wire.		line or Frame Relay) over a PSN.
	Emulated Service An Emulated Service is a service that is		Customer Edge A Customer Edge (CE) is a device where one end
	provided via pseudo-wire emulation.		of an emulated service originates and
			terminates. The CE is not aware that it is
			using an emulated service rather than a "real"
			service.
	Service Endpoint A Service Endpoint (SE) is a device where one		Provider Edge A Provider Edge (PE) is a device that provides
	end of an emulated service terminates.		PWE3 to a CE.
	Pseudo-Wire A Pseudo-Wire is a connection between two		Pseudo Wire A Pseudo Wire (PW) is a connection between two
	end-services.		PEs carried over a PSN. The PE provides the
			adaptation between the CE and the PW.
	Pseudo-Wire Endpoint A Pseudo-Wire Endpoint is a device where one		Pseudo Wire PDU A Pseudo Wire PDU (PW PDU) is a PDU sent on the
	end of a pseudo-wire terminates.		PW that contains all of the data and control
			information necessary to provide the desired
			service.
	Path-oriented A Path-oriented Pseudo-Wire is a pseudo-wire		PSN Tunnel A PSN Tunnel is a tunnel inside which multiple
	Pseudo-Wire for which core network devices must maintain		PWs can be nested so that they are transparent
	state information, for example, an MPLS LSP.		to core network devices.
	Non-path-oriented A Non-path-oriented Pseudo-Wire is a		Path-oriented PW A Path-oriented PW is a PW for which the
	Pseudo-Wire pseudo-wire for which core network devices		network devices of the underlying PSN must
	need not maintain state information, for		maintain state information.
	example, a L2TP tunnel.
	Transport Tunnel A Transport Tunnel is a tunnel inside which		Non-path-oriented PW A Non-path-oriented PW is a PW for which the
	multiple pseudo-wires can be nested so that		network devices of the underlying PSN need not
	they are transparent to core network devices.		maintain state information.
			Service Interworking In Service Interworking, the IWF (Interworking
			Function) between two dissimilar protocols
			(e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP,
			ATM & L2TP, etc.) terminates the protocol used
			in one network and translates (i.e. maps) its
			Protocol Control Information (PCI) to the PCI
			of the protocol used in other network for User,
			Control and Management Plane functions to the
			extent possible. In general, since not all
			functions may be supported in one or other of
			the networks, the translation of PCI may be
			partial or non-existent. However, this should
			not result in any loss of user data since the
			payload is not affected by PCI conversion at
			the service interworking IWF.
			Network Interworking In Network Interworking, the PCI (Protocol
			Control Information) of the protocol and the
			payload information used in two similar
			networks are transferred transparently by an
			IWF of the PE across the PSN. Typically the IWF
			of the PE encapsulates the information which is
			transmitted by means of an adaptation function
			and transfers it transparently to the other
			network.
	2. PDU Encapsulation		2. PDU Encapsulation
	Every pseudo-wire edge device MUST provide service interfaces to use		Every PE MUST provide service interfaces to use common service-
	common service-specific techniques for encapsulating PDUs. It should		specific techniques for encapsulating PDUs from the PWESs. It should
	be noted that the PDUs to be encapsulated may or may not contain L2		be noted that the PDUs to be encapsulated may or may not contain L2
	or L1 header information. This is service specific. Every PWE3		or L1 header information. This is service specific. Every PWE3
	service MUST specify what a PDU is.		service MUST specify what the PDU is.
	A pseudo-wire header must contain sufficient but not excessive		A PW header consists of all the header fields in a PW PDU that are
	information so that the other end of the pseudo-wire, aided with		used by the PW egress to determine how to process the PDU. The header
	information obtained during the pseudo-wire setup process, knows		that is used for sending the PW PDUs from the PW ingress to the
	exactly how to handle the encapsulated PDUs. A pseudo-wire header		egress (e.g. the tunnel label in [MARTINI2]) is not considered as
	consists of all the header fields in an encapsulated PDU that are		part of the PW header. It is called PSN tunnel header.
	used by the pseudo-wire egress to determine how to handled the PDU.
	The header that is used for transporting the encapsulated PDUs from
	the pseudo-wire ingress to the egress (e.g. the tunnel label in
	[MART2]) is not considered as part of the pseudo-wire header. It is
	called transport header instead. It should be noted that transport
	headers are totally different from transport-layer headers (e.g.
	TCP/UDP headers).
	Specific requirements on PDU encapsulation for a PWE3 approach are		Specific requirements on PDU encapsulation for a PWE3 approach are
	listed below.		listed below.
	2.1. Conveyance of Necessary L2/L1 Header Information		2.1. Conveyance of Necessary L2/L1 Header Information
	Sometimes the egress of a pseudo-wire needs some L2 or L1 header		The egress of a PW needs some information, e.g. which native service
	information in order to know how to process the PDUs received. A		the PW PDUs belong to, and possibly some L2 or L1 header information,
	PWE3 approach SHOULD provide some mechanism (e.g. using one or more		in order to know how to process the PDUs received. A PWE3 approach
	control words) for conveying such L2/L1 header information from the		MUST provide some mechanism for conveying such information from the
	pseudo-wire ingress to the egress. The use of these mechanisms can be		PW ingress to the egress. It should be noted that not all such
	REQUIRED or OPTIONAL, depending on services.		information must be carried in the PW header of the PW PDUs. Some
			information (e.g. service type of a PW) can be stored as state
	2.2. Location of the Pseudo-Wire Header		information at the egress during PW setup.
	A pseudo-wire header MUST be between the PDU and the transport
	header. This is necessary for the pseudo-wire egress to locate the
	pseudo-wire header, and to process the PDU.
	2.3. PDU Length		2.2. PDU Length
	A PWE3 approach MUST accommodate variable length PDUs, if variable		A PWE3 approach MUST accommodate variable length PDUs, if variable
	length PDUs are allowed by the native service. For example, a PWE3		length PDUs are allowed by the native service. For example, a PWE3
	approach for Frame Relay MUST accommodate variable length frames.		approach for Frame Relay MUST accommodate variable length frames.
	2.4. Encapsulation of Signaling Messages of the Native Services		2.3. Encapsulation of Control Messages of the Native Services
	PDUs that contain signaling information of the native service SHOULD
	be encapsulated in the same way as data PDUs. This simplifies
	handling at both the ingress and the egress of a pseudo-wire.
	2.5. Timing Information
	Timing information can be essential for the endpoints of a service.		It is desirable that the PEs participate as little as possible in the
	If the original frames contain timing information, the encapsulation		signaling and maintenance of the native services. However, it is up
	mechanism SHOULD not cause loss of such timing information.		to each specific PWE3 approach to specify what the PEs need to do in
	Requirements on clock recovery between pseudo-wire endpoints are		this regard.
	further discussed in the "Maintenance of Emulated Services" section.
	2.6. Support for Circuit Multiplexing		2.4. Support for Circuit Multiplexing
	If a service in its native form is capable of grouping multiple		If a service in its native form is capable of grouping multiple
	circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be		circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be
	provided so that a single pseudo-wire can be used to connect two		provided so that a single PW can be used to connect two end-trunks.
	end-trunks. From encapsulation perspective, the encapsulation header		From encapsulation perspective, the encapsulation header MUST carry
	MUST carry sufficient information, e.g. VCI of each cell, so that the		sufficient information, e.g. VCI of each cell, so that the egress of
	egress of the pseudo-wire can demultiplex individual circuits from		the PW can demultiplex individual circuits from the PW.
	the pseudo-wire.
	2.7. Packet Ordering		2.5. Packet Ordering
	When packets carrying the encapsulated PDUs traverse a pseudo-wire,		When packets carrying the PW PDUs traverse a PW, they may arrive at
	they may arrive at the egress out of order. For some services, the		the egress out of order. For some services, the PW PDUs must be
	encapsulated PDUs must be delivered in order. For such services, some		delivered in order. For such services, some mechanism MUST be
	mechanism MUST be provided to ensure that. Providing a sequence		provided for ensuring in-order delivery. Providing a sequence number
	number in the pseudo-wire header for each packet is one possible		in the PW header for each packet is one possible approach.
	approach. Every specific PWE3 approach MUST define as a mechanism if
	in-order PDU delivery is required.
	3. Packet Transport		2.6. Packet Duplication
	This section describes requirements on how to transport packets		In rare cases, packets traversing a PW may be duplicated. For some
	carrying the encapsulated PDUs over the network that provides PWE3		services, packet duplication is not allowed. For such services some
			mechanism MUST be provided to ensure that duplicated packets will not
			be delivered. The mechanism may or may not be the same as the
			mechanism used to ensure in-order packet delivery.
			3. Carrying the PW PDUs over a Packet-Switched Network
			This section describes requirements on how to send packets carrying
			the PW PDUs over a packet-switched network (PSN) that provides PWE3
	services.		services.
	3.1. Setup of Pseudo-Wires		3.1. Setup of Pseudo-Wires
	A pseudo-wire is a tunnel that connects two end-services. After the		A PW is a tunnel that connects two PWESs. After the L2/L1 PDUs of a
	L2/L1 PDUs of a service are encapsulated, they must be transported		service are encapsulated, they must be sent over the PW to the other
	over the pseudo-wire to the other end-service.		PWES.
	Every PWE3 approach MUST define some signaling mechanism for setting		Every PWE3 approach MUST define some signaling mechanism for setting
	up the pseudo-wires. During the setup process, the pseudo-wire		up the PWs. During the setup process, the PEs need to exchange some
	endpoints need to exchange some information (e.g. learn each other's		information (e.g. learn each other's capability). The signaling
	capability). The signaling mechanism MUST enable the pseudo-wire		mechanism MUST enable the PEs to exchange all necessary information.
	endpoints to exchange all necessary information. For example, both		For example, both endpoints must agree on an encapsulation method. As
	endpoints must agree on an encapsulation method and the MTU size for		another example, in order to support circuit multiplexing using ATM
	the pseudo-wire. As another example, in order to support circuit		VPs, both PEs must agree on using the VCIs in the PW PDUs to
	multiplexing using ATM VPs, both pseudo-wire endpoints must agree on		demultiplex individual VCs from the VP at the PW egress. Which
	using the VCIs in the encapsulated PDUs to demultiplex individual VCs		signaling protocol to use and what information to exchange are
	from the VP at the pseudo-wire egress. Which signaling protocol to		service specific. Every PWE3 approach MUST specify these. Manual
	use and what information to exchange are service specific. Every PWE3		configuration can be considered as a special kind of signaling and is
	approach MUST specify these. Manual configuration can be considered		explicitly allowed.
	as a special kind of signaling and is explicitly allowed.
	This document does not assume a particular type of pseudo-wires. GRE
	tunnels, L2TP tunnels, or MPLS LSPs can all be used. Selection of a
	particular type of pseudo-wires is carrier-dependent and is outside
	scope of the PWE3 WG.
	A pseudo-wire can be either path-oriented or non-path-oriented. The		IP tunnels [MPLSINIP], sessions in a [L2TP] tunnel, or [MPLS] LSPs
	difference is core network devices need to maintain state information		can all be used as PWs. Selection of a particular type of PWs is
	for path-oriented pseudo-wires (e.g. LSPs) but not for non-path-		carrier-dependent and is outside scope of the PWE3 WG.
	oriented ones (e.g. GRE/L2TP tunnels). This has scalability
	implication that is further discussed in the "Scalability" section.
	3.2. Pseudo-Wire MTU		3.2. Pseudo-Wire MTU
	A pseudo-wire MUST be able to be configured with an MTU that is		A PW MUST be able to be configured with an PW_MTU. One way to do this
	sufficient to transport packets whose size equals to the largest PDU		is to set the PW_MTU to (PW_Path_MTU - PW_header -
	size of the native service plus the pseudo-wire header and transport		PSN_tunnel_header). At a PW ingress, if a packet's length exceeds the
	header. At a pseudo-wire ingress, if a packet's length exceeds the		PW_MTU, it MAY be dropped. In this case, the management plane of the
	pseudo-wire MTU, it MUST be dropped. At a pseudo-wire egress, if the		ingress PE MAY be notified. Alternatively, a fragmentation mechanism
	length of a frame that is restored from a PDU exceeds the MTU of		MAY be defined and used. At a PW egress, if the length of a L2/L1
	destination end-service, it MUST be dropped.		frame that is restored from a PW PDU exceeds the MTU of destination
			PWES, it MAY be dropped. In this case, the management plane of the
			egress PE MAY be notified. Alternatively, a fragmentation mechanism
			MAY be defined and used.
	3.3. Transport of Signaling Messages of the Native Services		3.3. Carrying Control Messages of the Native Services
	Some native services use signaling messages for maintaining the		Some native services use control messages for maintaining the
	circuits. These signaling messages may be in-band, e.g. Ethernet flow		circuits. These control messages may be in-band, e.g. Ethernet flow
	control or ATM performance management, or out-of-band, e.g. the		control or ATM performance management, or out-of-band, e.g. the
	signaling VC of an ATM VP (from the perspective of other VCs in that		signaling VC of an ATM VP. If such control messages are lost,
	VP). If such signaling messages are lost, functionality of the		functionality of the services will be significantly affected.
	services will be significantly affected. Therefore, it can be
	desirable to provide higher reliability for transporting signaling
	messages.
	Each PWE3 approach MAY state what approach can be used to ensure that		Therefore, it can be desirable to provide higher reliability for
	signaling messages of the native service will be delivered over the		carrying control messages. What mechanisms to use and how to use
	network with high probability. Differentiating signaling packets from		those mechanisms for providing higher reliability are outside scope
	data packets and giving them preferable forwarding treatment in the		of the PWE3 WG.
	network is one possible approach. Such approaches NEED not be
	defined in a PWE3 approach itself.
	3.4. Transport Efficiency		3.4. PSN Tunnel Header Overhead
	In order to reduce transport header overhead and increase bandwidth		In order to reduce PSN tunnel header overhead, multiple PDUs MAY be
	efficiency, multiple PDUs MAY be concatenated before a transport		concatenated before a PSN tunnel header is added. Each PDU still
	header is added. Each PDU still carries its own pseudo-wire header so		carries its own PW header so that the egress of the PW knows how to
	that the egress of the pseudo-wire knows how to handle it.		process it. However, the benefit of concatenating multiple PDUs for
			header efficiency should be weighed against the resulting larger
			penalty incurred by packet loss.
	4. Faithfulness of Emulated Services		4. Faithfulness of Emulated Services
	An emulated service SHOULD be as similar to the native service as		An emulated service SHOULD be as similar to the native service as
	possible, but it is not REQUIRED that they should be identical. Each		possible, but it is not REQUIRED that they should be identical. The
	difference between an emulated service and the corresponding native		applicability statement of a PWE3 service MUST report any limitations
	service, if any, can be classified as either functional or non-		of the emulated service. All limitations between an emulated service
	functional. Functional differences are those that cause some		and the corresponding native service can be classified as either
	features of the native service to become disabled in the emulated		functional or non-functional. Functional limitations are those that
	one. For example, if an emulated Ethernet service introduces some		cause some features of the native service to become disabled in the
	difference that can cause the Spanning Tree Protocol (STP) to mal-		emulated one. For example, if an emulated Ethernet service introduces
	function, such a difference will be classified as a functional		some difference that can cause the Spanning Tree Protocol (STP) to
			malfunction, such a difference will be classified as a functional
	difference. Other differences are non-functional. For examples,		difference. Other differences are non-functional. For examples,
	differences in service quality between an emulated service and the		differences in service quality between an emulated service and the
	native one are non-functional. In every PWE3 approach:		native one are non-functional.
	- All functional differences and the features disabled MUST be
	pointed out;
	- Non-functional differences SHOULD be pointed out.
	Some basic requirements on faithfulness of an emulated service are		Some basic requirements on faithfulness of an emulated service are
	described below.		described below.
	4.1. Characteristics of an Emulated Service		4.1. Characteristics of an Emulated Service
	Functionally, two service endpoints that are connected by an emulated		Functionally, two CEs that are connected by an emulated service
	service MUST appear directly connected by a native service, although		SHOULD appear directly connected by a native service, although
	service quality of the emulated service may be different from that of		service quality of the emulated service may be different from that of
	a native one. Specifically, this implies (but is not limited to) the		a native one. Specifically, the following requirements MUST be met:
	followings:
	1) It MUST be possible to define type (e.g. Ethernet or PPP, which is		1) It MUST be possible to define type (e.g. Ethernet, which is
	inherited from the native service), speed (e.g. 100Mbps), and MTU		inherited from the native service), speed (e.g. 100Mbps), and MTU
	size for an emulated service.		size for an emulated service.
	2) From the service endpoints' perspective, each emulated service		2) The two endpoints of emulated service #1 and the two endpoints of
	MUST appear as unshared.		emulated service #2 may be connected to the same PE at each end,
			respectively. As a result, the PWs of these two emulated services
	3) If an emulated service fails (either at one of the end-services or		may share the same physical paths between the two PEs. But from
	in the middle of the pseudo-wire), both service endpoints MUST be		the CEs' perspective, each emulated service MUST appear as
	notified reasonably timely. The definition of "reasonable		unshared, that is, a CE MUST NOT be aware of existence of other
	timeliness" is service-dependent.		CEs or other emulated services.
	4) Two service endpoints connected by an emulated service MUST be		3) If an emulated service fails (either at one of the PWESs or in the
	able to establish routing protocol (e.g. IGP) adjacency over the		middle of the PW), both CEs MUST be notified in a timely manner,
	emulated service. To be clear, the Spanning Tree Protocol (STP) is		if they will be notified in the native service. The definition of
	not considered as a routing protocol and requirements on		"timeliness" is service-dependent.
	support/non-support of STP is outside scope of this document.
	5) When desired, an emulated service MUST be able to appear as a		4) If a routing protocol (e.g. IGP) adjacency can be established over
	normal link in the service endpoints' IGP routing table.		a native service, it MUST be possible to be established over an
			emulated service as well. Spanning Tree Protocol (STP) is not
			considered as a routing protocol and requirements on support/non-
			support of STP is outside scope of this document.
	6) The TTL fields of the encapsulated PDUs, if exist, MUST not be		5) The TTL fields of the PW PDUs, if exist, MUST not be changed
	changed inside an emulated service.		inside an emulated service.
	4.2. Service Quality of Emulated Services		4.2. Service Quality of Emulated Services
	It is RECOMMENDED but not REQUIRED that an emulated service provide		It is RECOMMENDED but not REQUIRED that an emulated service provide
	as high service quality as the native service. However, the PWE3 WG		as high service quality as the native service. However, the PWE3 WG
	only defines mechanisms for providing pseudo-wire emulation, not the		only defines mechanisms for providing PW emulation, not the services
	services themselves. What quality to provide for a specific emulated		themselves. What quality to provide for a specific emulated service
	service is a matter between a service provider (SP) and its		is a matter between a service provider (SP) and its customers, and is
	customers, and is outside scope of the PWE3 WG. In fact, different		outside scope of the PWE3 WG. In fact, different SPs can use the same
	SPs can use the same PWE3 approach but different QoS approaches to		PWE3 approach with different QoS mechanisms to provide the same
	provide the same emulated service with different service quality.		emulated service with different service quality.
	4.3. Signaling of Native Services
	A PWE3 approach SHOULD support signaling of the native service. This
	is further discussed in the "Maintenance of Emulated Services"
	section.
	5. Maintenance of Emulated Services		5. Maintenance of Emulated Services
	Every PWE3 approach MUST provide mechanisms for maintaining the		Every PWE3 approach MUST provide mechanisms for maintaining the
	working condition of an emulated service and for signaling any status		working condition of an emulated service.
	changes.
	5.1. Signaling of Status Changes of an Emulated Service		5.1. Keep-alive
	5.1.1. Up/Down Notification		If a native service has keep-alive mechanism, the corresponding
			emulated service MUST define a similar mechanism for keep-alive.
	With pseudo-wire emulation, a failure may occur at a remote place		5.2. Status Monitoring
	such that one or both physical links between the SEs and PEs remains
	up. For example in Figure 1, if the physical link between SE1 and
	PE1 fails, the physical link between SE2 and PE2 will not be affected
	and will remain up. Unless some signaling is done to notify SE2 of
	the remote failure, SE2 will continue to send traffic over the
	emulated service to SE1. Such traffic will be discarded at PE1.
	Therefore, when an emulated service fails (either at an end-service
	or in the middle of the pseudo-wire), both service endpoints MUST be
	notified. Every PWE3 approach MUST provide such a signaling
	mechanism. This functionality is equivalent to failure notification
	of normal links.
	Similarly, every PWE3 approach MUST provide some signaling mechanism		Some native services have mechanisms for status monitoring. For
	so that when a network failure is fixed, all the affected emulated		example, ATM supports OAM for this purpose. For such services, the
	services will change status from "Down" to "Up".		corresponding emulated services MUST specify how to perform status
			monitoring. The mechanisms NEED NOT be defined in this WG. Some
			status monitoring mechanisms defined in other WGs, e.g., [LSPPING] or
			[MPLSOAM], may be leveraged.
	5.1.2. Packet Loss and/or Out-of-order Delivery		5.3. Notification of Status Changes
	A pseudo-wire can incur packet loss and/or out-of-order delivery.		5.3.1. Up/Down Notification
	This can significantly impact the working condition of an emulated
	service. Number of packets lost or delivered out of order in unit
	time can be considered as two new types of "generalized bit error
	rate" of a pseudo-wire. Every PWE3 approach SHOULD provide some
	mechanism so that if either type of "generalized bit error rate"
	exceeds some configured threshold, the pseudo-wire and the emulated
	service will be signaled down.
	5.1.3. Other Status Signaling		If a native service is bi-directional, the corresponding emulated
			service can only be signaled up when the associated PWs, and PSN
			tunnels if any, in both directions are functional.
	A PWE3 approach MAY provide mechanism for other status signaling, if		Because the two CEs of an emulated service are not adjacent, a
	any.		failure may occur at a place such that one or both physical links
			between the CEs and PEs remain up. For example in Figure 1, if the
			physical link between CE1 and PE1 fails, the physical link between
			CE2 and PE2 will not be affected and will remain up. Unless CE2 is
			notified about the remote failure, it will continue to send traffic
			over the emulated service to CE1. Such traffic will be discarded at
			PE1. Some native services have failure notification so that when the
			services fail, both CEs will be notified. For such native services,
			the corresponding PWE3 service MUST provide a failure notification
			mechanism.
	5.1.4. Collective Status Signaling		Similarly, if a native service has notification mechanism so that
			when a network failure is fixed, all the affected services will
			change status from "Down" to "Up", the corresponding emulated service
			MUST provide a similar mechanism for doing so.
			5.3.2. Misconnection and Payload Mistype
			With PWE3, misconnection and payload mistype can occur. A PWE3
			approach MAY define some mechanism for detecting and handling
			misconnection and payload mistype.
			5.3.3. Packet Loss, Corruption, and Out-of-order Delivery
			A PW can incur packet loss, corruption, and out-of-order delivery.
			This can impact the working condition of an emulated service. Packet
			loss, corruption, and out-of-order delivery can be considered as
			"generalized bit error" of a PW. If a native service has some
			mechanism to deal with bit error, the corresponding PWE3 service
			SHOULD provide a similar mechanism.
			5.3.4. Other Status Notification
			A PWE3 approach MAY provide mechanism for other status notification,
			if any.
			5.3.5. Collective Status Notification
	Status of a group of emulated services may be affected identically by		Status of a group of emulated services may be affected identically by
	a single network incidence. For example, when the physical link		a single network incidence. For example, when the physical link
	between a SE and a PE fails, all the emulated services that go		between a CE and a PE fails, all the emulated services that go
	through that link will fail. It is likely that there exists a group		through that link will fail. It is likely that there exists a group
	of emulated services which all terminate at a remote SE. (There can		of emulated services which all terminate at a remote CE. (There can
	be multiple such SEs). Therefore, it is desirable that a single		be multiple such CEs). Therefore, it is desirable that a single
	signaling message can be used to signal the failure of the whole		notification message be used to notify failure of the whole group of
	group of emulated services. A PWE3 approach MAY provide some		emulated services. A PWE3 approach MAY provide some mechanism for
	mechanism for signaling status changes of a group of emulated		notifying status changes of a group of emulated circuits. One
	circuits. One possible approach is to associate each emulated		possible approach is to associate each emulated service with a group
	service with a group ID when the pseudo-wire for that emulated		ID when the PW for that emulated service is set up. Multiple emulated
	service is set up. Multiple emulated services can then be grouped by		services can then be grouped by associating them with identical group
	associated them with identical group ID. In status signaling, that		ID. In status notification, that group ID can be used to refer all
	group ID can then be used to refer all the emulated services in that		the emulated services in that group.
	group.
	5.2. Clock Recovery		5.4. Clock Recovery
	For some services, the pseudo-wire endpoints need to maintain some		For some services, the PEs need to maintain some kind of timing
	kind of timing relationship (e.g. synchronization). A PWE3 approach		relationship (e.g. synchronization). The corresponding PWE3 services
	for such services MUST provide some mechanism to support that.		MUST provide some mechanism to support that. If time stamps need to
			be carried across the PSN, [RTP] MUST be used.
	6. Management of Emulated Services		6. Management of Emulated Services
	Each PWE3 approach SHOULD provide some mechanisms for network		Each PWE3 approach SHOULD provide some mechanisms for network
	operators to manage the emulated service.		operators to manage the emulated service. These mechanisms can be in
			the forms described below.
	6.1. MIB		6.1. MIBs
	A pseudo-wire MIB (PW-MIB) MAY be provided for managing each emulated		SNMP MIBs [SMIV2] MUST be provided for managing each emulated service
	service. The MIB SHOULD have the following requirements:		as well as pseudo-wire in general. These MIBs SHOULD be created with
			the following requirements.
	- The counters in the MIB SHOULD NOT replicate existing MIB counters.		6.2. General MIB Requirements
	- Each end-service SHOULD appear as an interface in the ifTable.		New MIBs MUST augment or extend where appropriate, existing tables as
			defined in other existing service-specific MIBs for existing services
			such as MPLS or L2TP. For example, the ifTable as defined in the
			Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-
			order packets. A second example is the extension of the MPLS-TE-MIB
			[TEMIB] when emulating circuit services over MPLS. Rather than
			redefining the tunnelTable so that PWES can utilize MPLS tunnels, for
			example, entries in this table MUST instead be extended to add
			additional PWES-specific objects. Doing so facilitates a natural
			extension of those objects defined in the existing MIBs in terms of
			management, as well as leveraging existing agent implementations.
	- The MIB SHOULD describe how the existing counters are used for		Interfaces implementing a PWES MUST appear as an interface in the
	pseudo-wire emulation.		ifTable.
	- The MIB MAY support row creation to create new end-service pairs.		6.3. Configuration and Provisioning
	- The MIB MAY augment existing tables. For example, the ifTable		MIB Tables MUST be designed to facilitate configuration and
	SHOULD be augmented to provide counts of out-of-order packets.		provisioning of the PWES.
	- The MIB SHOULD define meanings for the standard linkUp and linkDown		The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
	traps, as well as any protocol-specific traps that are needed.		PWES connections.
	- The MIB SHOULD be structured in a hierarchical fashion such that		6.4. Performance Monitoring
	generic PW objects and tables are not duplicated for each service.
	6.2. Pseudo-Wire Traceroute		MIBs MUST collect statistics for performance and fault management.
	It can be desirable to know the exact path of a pseudo-wire,		MIBs MUST provide a description of how existing counters are used for
	especially for troubleshooting purpose. A pseudo-wire emulation		PW emulation and SHOULD not replicate existing MIB counters.
	service MAY support pseudo-wire traceroute, even if the pseudo-wire
	used is non-path-oriented.
	7. Scalability		6.5. Fault Management and Notifications
	Scalability requirements for Pseudo-Wire Emulation Edge to Edge are		Notifications SHOULD be defined where appropriate to notify the
	described below.		network operators of any interesting situations, including faults
			detected in the PWES.
	- Pseudo-wire emulation services SHOULD be transparent to other		Objects defined to augment existing protocol-specific notifications
	packet services (e.g. best effort Internet service).		in order to add PWES functionality MUST explain how these
			notifications are to be emitted.
	- Only pseudo-wire endpoints should be aware of existence of pseudo-		6.6. Pseudo-Wire Traceroute
	wires and PWE3 services. Core network devices SHOULD NOT be exposed
	to a large number of pseudo-wires.
	Pseudo-wires can be path-oriented or non-path-oriented. For path-		It can be desirable to know the exact path of a PW, especially for
	oriented pseudo-wires, core network devices must maintain state		troubleshooting purpose. A PW emulation service MUST support PW
	information for them. If a large number of path-oriented pseudo-		traceroute. One tunnel traceroute approach is defined in [BONICA].
	wires are used, core network devices will have to maintain a large
	amount of state information. In order to avoid scalability problem,
	transport tunnels between pseudo-wire endpoints can be introduced.
	Pseudo-wires from the same ingress to the same egress are nested
	inside the transport tunnel that is from that ingress to that
	egress. By creating such a tunnel hierarchy, individual pseudo-
	wires are transparent to the core devices. If a specific PWE3
	approach uses path-oriented pseudo-wires, transport tunnels SHOULD
	be used to improve scalability. However, a transport tunnel is not
	part of any pseudo-wire. Signaling of transport tunnels NEED NOT be
	defined in the PWE3 approach itself. As an example, if LSPs are
	used as pseudo-wires in a PWE3 approach, they can be nested inside
	a tunnel LSP from the pseudo-wire ingress to the pseudo-wire
	egress. The tunnel LSPs can be signaled by any mechanism defined
	in [MPLS].
	- Circuit multiplexing: circuit multiplexing SHOULD be supported.		7. Scalability
	- Collective status signaling: Collective status signaling SHOULD be		Scalability requirements for PWE3 are described below.
	supported.
	8. Other Generic Requirements		- Only PEs should be aware of existence of PWs and PWE3 services.
			Core network devices SHOULD NOT be exposed to a large number of
			PWs.
	Other generic requirements for Pseudo-Wire Emulation Edge to Edge		PWs can be path-oriented or non-path-oriented. For path-oriented
	include:		PWs, core network devices must maintain state information for them.
			If a large number of path-oriented PWs are used, core network
			devices will have to maintain a large amount of state information.
			In order to avoid scalability problem, PSN tunnels between PEs can
			be introduced. PWs from the same ingress to the same egress are
			nested inside the PSN tunnel that is from that ingress to that
			egress. By creating such a tunnel hierarchy, individual PWs are
			transparent to the core devices. If a specific PWE3 approach uses
			path-oriented PWs, PSN tunnels SHOULD be used to improve
			scalability. However, a PSN tunnel is not part of any PW.
			Signaling of PSN tunnels NEED NOT be defined in the PWE3 approach
			itself. As an example, if LSPs are used as PWs in a PWE3 approach,
			they can be nested inside a tunnel LSP from the PW ingress to the
			PW egress. The tunnel LSPs can be signaled by any mechanism
			defined in [MPLS].
	- No New Protocol Operations:		- Circuit multiplexing: circuit multiplexing SHOULD be supported.
	No matter which protocol (e.g. GRE or L2TP or MPLS) is used for		- Collective status notification: collective status notification
	packet transport, PWE3 SHOULD just be an application of that		SHOULD be supported.
	protocol. In other words, no new protocol (GRE or L2TP or MPLS)
	operations SHOULD be introduced. For example, if an MPLS label
	switching operation is performed, a PWE3 approach SHOULD not
	require that the TTL field of the top label remains unchanged.
	(Otherwise, this label switching would be different from a normal
	MPLS label switching and would be considered as a new protocol
	operation). If any new operations are indeed introduced in a PWE3
	approach, they MUST be clearly pointed out.
	- Minimum configuration work at the pseudo-wire endpoints;		8. Other Generic Requirements
	- Easy to maintain and manage.		8.1. RFC 2914 Conformance
			[RFC2914] describes the need for congestion control in the Internet,
			and discusses what constitute correct congestion control. Any PWE3
			approach MUST conform to RFC 2914 and be TCP-friendly in its response
			to congestion. The applicability document of a PWE3 approach MUST
			provide a statement on RFC 2914 conformance.
	9. Non-Requirements		9. Non-Requirements
	Some non-requirements are mentioned in various sections of this		Some non-requirements are mentioned in various sections of this
	document. Those work items are outside scope of the PWE3 WG. The		document. Those work items are outside scope of the PWE3 WG. The
	non-requirements are listed below:		non-requirements are listed below:
	- Selection of a particular type of pseudo-wires;		- Service interworking;
			- Point-to-multipoint or multipoint-to-multipoint PWs;
			- Selection of a particular type of PWs;
	- Striving to make the emulated services perfectly match their native		- Striving to make the emulated services perfectly match their native
	services;		services;
	- Defining mechanisms for signaling the transport tunnels;		- Defining mechanisms for signaling the PSN tunnels;
	- Defining how to perform traffic management on packets that carry		- Defining how to perform traffic management on packets that carry PW
	encapsulated PDUs;		PDUs;
	- Providing security for the encapsulated PDUs;		- Providing security for the PW PDUs;
	- Providing any multicast service that is not native to the emulated		- Providing any multicast service that is not native to the emulated
	medium.		medium.
	To illustrate this point, Ethernet transmission to a multicast		To illustrate this point, Ethernet transmission to a multicast
	IEEE-48 address is considered in scope, while multicast services		IEEE-48 address is considered in scope, while multicast services
	like [MARS] that are implemented on top of the medium are out of		like [MARS] that are implemented on top of the medium are out of
	scope;		scope;
	10. Quality of Service (QoS) Considerations		10. Quality of Service (QoS) Considerations
	In this document, QoS means satisfactory service quality. It should		In this document, QoS means satisfactory service quality. It should
	not be confused with QoS mechanisms such as Weighted Fair Queueing		not be confused with QoS mechanisms such as Weighted Fair Queuing
	(WFQ) or Random Early Detection (RED).		(WFQ) or Random Early Detection (RED).
	QoS is essential for ensuring that the emulated services are similar		QoS is essential for ensuring that the emulated services are similar
	(but not necessarily identical) to their native forms. It is up to		(but not necessarily identical) to their native forms. It is up to
	network operators to decide how to provide QoS - They can choose to		network operators to decide how to provide QoS - They can choose to
	rely on over-provisioning and/or deploy some QoS mechanisms.		rely on over-provisioning and/or deploy some QoS mechanisms.
	In order to take advantage of some QoS mechanisms defined in other		In order to take advantage of QoS mechanisms defined in other working
	working groups, e.g. the traffic management schemes defined in		groups, e.g. the traffic management schemes defined in DiffServ WG,
	DiffServ WG, it is desirable that some mechanisms exists for		it is desirable that some mechanisms exists for differentiating the
	differentiating the packets resulted from PDU encapsulation. These		packets resulted from PDU encapsulation. These mechanisms need not be
	mechanisms need not be defined in the PWE3 approaches themselves. For		defined in the PWE3 approaches themselves. For example, if the
	example, if the resulted packets are MPLS or IP packets, their EXP or		packets are MPLS or IP packets, their EXP or DSCP fields can be used
	DSCP fields can be used for marking and differentiating,		for marking and differentiating. A PWE3 approach MAY provide
	respectively. Every PWE3 approach SHOULD provide guidelines for		guidelines for marking and differentiating, e.g. what fields in the
	marking and differentiating, e.g. what fields in the original L2 or		original L2 or L1 headers should be used for determining the EXP/DSCP
	L1 headers should be used for determining the EXP/DSCP value. But the		value. But the exact procedure of how to perform marking and
	exact procedure on how to perform marking and differentiating, e.g.		differentiating, e.g. specifying the mapping function from Ethernet
	the mapping from Ethernet .1P field to EXP field, is out of scope.		.1P field to EXP field, is out of scope.
	11. Inter-domain Pseudo-Wires		11. Inter-domain Pseudo-Wires
	The PWE3 WG will determine the requirements for having a pseudo-wire		The PWE3 WG will determine the requirements for having a PW pass
	pass across an administrative boundary. An edge could be a native		across an administrative boundary. An edge could be a native hand-
	hand-off or hand-off to a further pseudo-wire. The working group may		off or hand-off to a further PW. The working group may analyze
	analyze requirements for both security and performance for the		requirements for both security and performance for the inter-
	inter-administration technology. This topic is for further study.		administration technology. This topic is for further study.
	12. Security Considerations		12. Security Considerations
	12.1. Security Considerations for the Signaling/Control Channel		12.1. Security Considerations for the Signaling/Control Channel
	If a signaling/control channel is used in a PWE3 approach, some		If a signaling/control channel is used in a PWE3 approach, some
	security mechanism SHOULD be provided to ensure integrity of the		security mechanism MUST be provided to ensure integrity of the
	information transmitted across the signaling/control channel.		information transmitted across the signaling/control channel.
	12.2. Security Considerations for the Encapsulated PDUs		12.2. Security Considerations for the PW PDUs
	Providing security for the encapsulated PDUs is outside scope of the		Providing security for the PW PDUs is outside scope of the PWE3 WG.
	PWE3 WG.
	13. Deployment Considerations		13. Deployment Considerations
	Transition from using separate networks for TDM, ATM, Frame Relay and		Transition from using separate networks for TDM, ATM, Frame Relay and
	IP services to using a single network for multiple services requires		IP services to using a single network for multiple services requires
	careful planning and execution. This is an important topic for		careful planning and execution. This is an important topic for
	further study.		further study.
	14. Acknowledgments		14. Acknowledgments
	Some requirements specified in this document were originally		Some requirements specified in this document were originally
	articulated in a number of documents including [MART1], [MART2],		articulated in a number of documents including [MARTINI1],
	[CES], and [SFBS]. The authors would like to acknowledge authors of		[MARTINI2], [CES], and [SFBS]. The authors would like to acknowledge
	those documents. The authors would also like to acknowledge the input		authors of those documents. The authors would also like to
	and comments from T. So.		acknowledge the input and comments from Eric Rosen, Tricci So and Ron
			Cohen.
	15. References		15. References
			[BONICA] R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements
			for Generic Tunnels", <draft-bonica-tunneltrace-01.txt>,
			work in progress, Feb. 2001.
	[CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over		[CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over
	MPLS (CEM) Encapsulation" <draft-malis-sonet-ces-mpls-		MPLS (CEM) Encapsulation" , work in progress, April 2001.
	04.txt>, work in progress, April 2001.
	[GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic		[GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic
	Routing Encapsulation (GRE)", RFC2784, March 2000.		Routing Encapsulation (GRE)", RFC2784, March 2000.
			[IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB
			using SMIv2", RFC 2233, Nov. 1997.
	[L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G.		[L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G.
	Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC		Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC
	2661, August 1999.		2661, August 1999.
			[LSPPING] P. Pan, N. Sheth, and D. Cooper, "Detecting Data Plane
			Liveliness in RSVP-TE", <draft-pan-lsp-ping-00.txt>, work in
			progress, July 2001.
	[MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based		[MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
	ATM Networks", RFC2022, November 1996		ATM Networks", RFC2022, November 1996
	[MART1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS",		[MARTINI1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS",
	<draft-martini-l2circuit-trans-MPLS-06.txt>, work in		<draft-martini-l2circuit-trans-MPLS-06.txt>, work in
	progress, May 2001.		progress, May 2001.
	[MART2] L. Martini et al, "Encapsulation Methods for Transport of		[MARTINI2] L. Martini et al, "Encapsulation Methods for Transport of
	Layer 2 Frames Over MPLS", <draft-martini-l2circuit-encap-		Layer 2 Frames Over MPLS", <draft-martini-l2circuit-encap-
	MPLS-02.txt>, work in progress, May 2001.		MPLS-02.txt>, work in progress, May 2001.
	[MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol		[MPLS] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC3031, January 2001		Label Switching Architecture", RFC3031, January 2001
			[MPLSINIP] P. Doolan, Y. Katsube, A. Malis, R. Wilder, T. Worster,
			"MPLS Label Stack Encapsulation in IP", <draft-worster-
			mpls-in-ip-04.txt>, work in progress, Feb. 2001.
			[MPLSOAM] N. Harrison, P. Willis, S. Davari, B. Mack-Crane, H. Ohta,
			"OAM Functionality for MPLS Networks", <draft-harrison-
			mpls-oam-00.txt>, work in progress, Feb. 2001.
			[TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic
			Engineering Management Information Base Using SMIv2",
			<draft-ietf-mpls-te-mib-05.txt>, work in progress, November
			2000.
	[PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella,		[PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella,
	"Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)",		"Framework for Pseudo-Wire Emulation Edge-to-Edge (PWE3)",
	<draft-pate-pwe3-framework-00.txt>, work in progress, May		<draft-pate-pwe3-framework-00.txt>, work in progress, May
	2001.		2001.
	[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A		[RFC2914] S.Floyd, "Congestion Control Principles", RFC 2914, Sept.
	Transport Protocol for Real-Time Applications", RFC1889,		2000.
	January 1996.
			[RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
			"RTP: A Transport Protocol for Real-Time Applications",
			RFC1889, January 1996.
	[SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R.		[SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R.
	Hartani, and T. So "Multi-service over MPLS", <draft-		Hartani, and T. So, "Multi-service over MPLS", <draft-
	stdenis-ms-over-mpls-00.txt>, work in progress, Nov. 2000.		stdenis-ms-over-mpls-00.txt>, work in progress, Nov. 2000.
			[SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
			"Structure of Management Information for Version 2 of the
			Simple Network Management Protocol (SNMPv2)", RFC 1902,
			January 1996.
	16. Authors' Addresses		16. Authors' Addresses
	XiPeng Xiao		XiPeng Xiao
	Photuris, Inc.		Photuris, Inc.
	2025 Stierlin Court		2025 Stierlin Court
	Mountain View, CA 94043		Mountain View, CA 94043
	Email: xxiao@photuris.com		Email: xxiao@photuris.com
	Danny McPherson		Danny McPherson
	Amber Networks, Inc.		Amber Networks, Inc.
	skipping to change at page 17, line 4 ¶		skipping to change at page 18, line 11 ¶
	Photuris, Inc.		Photuris, Inc.
	2025 Stierlin Court		2025 Stierlin Court
	Mountain View, CA 94043		Mountain View, CA 94043
	Email: xxiao@photuris.com		Email: xxiao@photuris.com
	Danny McPherson		Danny McPherson
	Amber Networks, Inc.		Amber Networks, Inc.
	48664 Milmont Drive		48664 Milmont Drive
	Fremont, CA 94538		Fremont, CA 94538
	Email: danny@ambernetworks.com		Email: danny@ambernetworks.com
	Prayson Pate		Prayson Pate
	Overture Networks		Overture Networks
	P. O. Box 14864		P. O. Box 14864
	RTP, NC, USA 27709		RTP, NC, USA 27709
	Email: prayson.pate@overturenetworks.com		Email: prayson.pate@overturenetworks.com
	Craig White		Craig White
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	1025 Eldorado Blvd.		1025 Eldorado Blvd.
	Broomfield, CO, 80021		Broomfield, CO, 80021
	e-mail: Craig.White@Level3.com		e-mail: Craig.White@Level3.com
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: kireeti@juniper.net		Email: kireeti@juniper.net
			Vijay Gill
			Metromedia Fiber Network Inc.
			8075 Leesburg Pike, Suite 300
			Vienna, VA 22182
			Email: vgill@mfnx.net
			Thomas D. Nadeau
			Cisco Systems, Inc.
			250 Apollo Drive
			Chelmsford, MA 01824
			Email: tnadeau@cisco.com
	17. Full Copyright Section		17. Full Copyright Section
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
End of changes. 128 change blocks.
	418 lines changed or deleted		506 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/