< draft-ietf-pwe3-arch-01.txt		draft-ietf-pwe3-arch-02.txt >
	Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant		Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	Document: <draft-ietf-pwe3-arch-01.txt>		Document: <draft-ietf-pwe3-arch-02.txt>
	Expires: May 2003 Prayson Pate		Expires: August 2003 Prayson Pate
	Overture Networks, Inc.		Overture Networks, Inc.
	Editors		Editors
	November 2002		February 2003
	PWE3 Architecture		PWE3 Architecture
	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 RFC2026.		all provisions of section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 The list of		http://www.ietf.org/ietf/1id-abstracts.txt The list of
	Internet-Draft Shadow Directories can be accessed at		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 an architecture for Pseudo Wire Emulation		This document describes an architecture for Pseudo Wire Emulation
	Edge-to-Edge (PWE3). It discusses the emulation of services (such as		Edge-to-Edge (PWE3). It discusses the emulation of services (such as
	Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched		Frame Relay, ATM, Ethernet, TDM and SONET/SDH) over packet switched
	networks (PSNs) using IP or MPLS. It presents the architectural		networks (PSNs) using IP or MPLS. It presents the architectural
	framework for pseudo wires (PWs), defines terminology, specifies the		framework for pseudo wires (PWs), defines terminology, specifies the
	various protocol elements and their functions.		various protocol elements and their functions.
	Co-Authors		Co-Authors
	The following are co-authors of this document:		The following are co-authors of this document:
	Thomas K. Johnson Litchfield Communications		Thomas K. Johnson Litchfield Communications
	Kireeti Kompella Juniper Networks, Inc.		Kireeti Kompella Juniper Networks, Inc.
	Andrew G. Malis Vivace Networks		Andrew G. Malis Vivace Networks
	Danny McPherson TCB		Danny McPherson TCB
	Thomas D. Nadeau Cisco Systems		Thomas D. Nadeau Cisco Systems
	Tricci So Caspian Networks		Tricci So Caspian Networks
	W. Mark Townsley Cisco Systems		W. Mark Townsley Cisco Systems
	Craig White Level 3 Communications, LLC.		Craig White Level 3 Communications, LLC.
	Lloyd Wood Cisco Systems		Lloyd Wood Cisco Systems
	XiPeng Xiao Redback Networks		XiPeng Xiao Redback Networks
	Table of Contents		Conventions used in this document
	Status of this Memo.......................................... 1		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	1. Introduction............................................. 5		1. Introduction............................................. 5
	1.1 Pseudo Wire Definition............................... 5		1.1 Pseudo Wire Definition............................... 5
	1.2 PW Service Functionality............................. 6		1.2 PW Service Functionality............................. 6
	1.3 Non-Goals of this document........................... 6		1.3 Non-Goals of this document........................... 6
	1.4 Terminology.......................................... 6		1.4 Terminology.......................................... 6
	2. PWE3 Applicability....................................... 9		2. PWE3 Applicability....................................... 9
	3. Protocol Layering Model.................................. 9		3. Protocol Layering Model.................................. 9
	3.1 Protocol Layers...................................... 9		3.1 Protocol Layers...................................... 9
	3.2 Domain of PWE3....................................... 10		3.2 Domain of PWE3....................................... 11
	3.3 Payload Types........................................ 10		3.3 Payload Types........................................ 11
	4. Architecture of Pseudo-wires............................. 14		4. Architecture of Pseudo-wires............................. 14
	4.1 Network Reference Model.............................. 14		4.1 Network Reference Model.............................. 14
	4.2 PWE3 Pre-processing.................................. 15		4.2 PWE3 Pre-processing.................................. 15
	4.3 Maintenance Reference Model.......................... 19		4.3 Maintenance Reference Model.......................... 19
	4.4 Protocol Stack Reference Model....................... 19		4.4 Protocol Stack Reference Model....................... 19
	4.5 Pre-processing Extension to Protocol Stack...........		4.5 Pre-processing Extension to Protocol Stack Reference.
	Reference Model...................................... 20		Model................................................ 20
	5. PW Encapsulation......................................... 21		5. PW Encapsulation......................................... 21
	5.1 Payload Convergence Layer............................ 22		5.1 Payload Convergence Layer............................ 22
	5.2 Payload-independent PW Encapsulation Layers.......... 24		5.2 Payload-independent PW Encapsulation Layers.......... 24
	5.3 Fragmentation........................................ 27		5.3 Fragmentation........................................ 27
	5.4 Instantiation of the Protocol Layers................. 27		5.4 Instantiation of the Protocol Layers................. 27
	6. PW Demultiplexer Layer and PSN Requirements.............. 30		6. PW Demultiplexer Layer and PSN Requirements.............. 31
	6.1 Multiplexing......................................... 30		6.1 Multiplexing......................................... 31
	6.2 Fragmentation........................................ 30		6.2 Fragmentation........................................ 31
	6.3 Length and Delivery.................................. 30		6.3 Length and Delivery.................................. 31
	6.4 PW-PDU Validation.................................... 31		6.4 PW-PDU Validation.................................... 31
	6.5 Congestion Considerations............................ 31		6.5 Congestion Considerations............................ 32
	7. Control Plane............................................ 31		7. Control Plane............................................ 33
	7.1 Set-up or Teardown of Pseudo-Wires................... 31		7.1 Set-up or Teardown of Pseudo-Wires................... 33
	7.2 Status Monitoring.................................... 32		7.2 Status Monitoring.................................... 33
	7.3 Notification of Pseudo-wire Status Changes........... 32		7.3 Notification of Pseudo-wire Status Changes........... 34
	7.4 Keep-alive........................................... 34		7.4 Keep-alive........................................... 35
	7.5 Handling Control Messages of the Native Services..... 34		7.5 Handling Control Messages of the Native Services..... 35
	8. Management and Monitoring................................. 34		8. Management and Monitoring................................. 36
	8.1 Statistics........................................... 34		8.1 Status and Statistics................................ 36
	8.2 PW SNMP MIB Architecture............................. 35		8.2 PW SNMP MIB Architecture............................. 36
	8.3 Connection Verification and Traceroute................ 38		8.3 Connection Verification and Traceroute................ 40
	9. IANA considerations...................................... 38		9. IANA considerations...................................... 40
	10. Security Considerations................................. 38		10. Security Considerations................................. 40
	10.1 PW Tunnel End-Point and PW Demultiplexer Security... 38
	10.2 Validation of PW Encapsulation...................... 39
	1. Introduction		1. Introduction
	This document describes an architecture for Pseudo Wire Emulation		This document describes an architecture for Pseudo Wire Emulation
	Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation		Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation
	of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH)		of services (such as Frame Relay, ATM, Ethernet, TDM and SONET/SDH)
	over packet switched networks (PSNs) using IP or MPLS. It presents		over packet switched networks (PSNs) using IP or MPLS. It presents
	the architectural framework for pseudo wires (PWs), defines		the architectural framework for pseudo wires (PWs), defines
	terminology, specifies the various protocol elements and their		terminology, specifies the various protocol elements and their
	functions.		functions.
	1.1 Pseudo Wire Definition		1.1 Pseudo Wire Definition
	PWE3 is a mechanism that emulates the essential attributes of a		PWE3 is a mechanism that emulates the essential attributes of a
	service (such as a T1 leased line or Frame Relay) over a PSN. PWE3 is		service (such as a T1 leased line or Frame Relay) over a PSN. PWE3 is
	intended to provide only the minimum necessary functionality to		intended to provide only the minimum necessary functionality to
	emulate the wire with the required degree of faithfulness for the		emulate the wire with the required degree of faithfulness for the
	given service definition. Any required switching functionality is the		given service definition. Any required switching functionality is the
	responsibility of a forwarder function (FWRD). Any translation or		responsibility of a forwarder function (FWRD). Any translation or
	other operation needing knowledge of the payload semantics is carried		other operation needing knowledge of the payload semantics is carried
	out by native service processing (NSP) elements. The functional		out by native service processing (NSP) elements. The functional
	definition of any FWRD or NSP elements is outside the scope of PWE3.		definition of any FWRD or NSP elements is outside the scope of PWE3.
	The required functions of PWs include encapsulating service-specific		The required functions of PWs include encapsulating service-specific
	bit-streams, cells or PDUs arriving at an ingress port, and carrying		bit-streams, cells or PDUs arriving at an ingress port, and carrying
	them across a path or tunnel. In some cases it is necessary to		them across a IP path or MPLS tunnel. In some cases it is necessary
	perform other operation such as managing their timing and order, to		to perform other operation such as managing their timing and order,
	emulate the behavior and characteristics of the service to the		to emulate the behavior and characteristics of the service to the
	required degree of faithfulness.		required degree of faithfulness.
	From the perspective of a Customer Edge Equipment (CE), the PW is		From the perspective of a Customer Edge Equipment (CE), the PW is
	characterised as an unshared link or circuit of the chosen service.		characterised as an unshared link or circuit of the chosen service.
	In some cases, there may be deficiencies in the PW emulation that		In some cases, there may be deficiencies in the PW emulation that
	impact the traffic carried over a PW, and hence limit the		impact the traffic carried over a PW, and hence limit the
	applicability of this technology. These limitations must be fully		applicability of this technology. These limitations must be fully
	described in the appropriate service-specific documentation. It is		described in the appropriate service-specific documentation.
	possible that these limitations may lead to the definition of more
	than one PW emulation method, each providing a different degree of		For each service type, there will be one default mode of operation
	faithfulness.		that all PEs offering that service type MUST support. However,
			OPTIONAL modes MAY be defined to improve the faithfulness of the
			emulated service, if it can be clearly demonstrated that the
			additional complexity associated with the OPTIONAL mode is offset by
			the value it offers to PW users.
	1.2 PW Service Functionality		1.2 PW Service Functionality
	PWs provide the following functions in order to emulate the behavior		PWs provide the following functions in order to emulate the behavior
	and characteristics of the native service.		and characteristics of the native service.
	o Encapsulation of service-specific PDUs or circuit data arriving		o Encapsulation of service-specific PDUs or circuit data arriving
	at the ingress port (logical or physical).		at the PE-bound port (logical or physical).
	o Carriage of the encapsulated data across a PSN tunnel.		o Carriage of the encapsulated data across a PSN tunnel.
	o Establishment of the PW including the exchange and/or		o Establishment of the PW including the exchange and/or
	distribution of the PW identifiers used by the PSN		distribution of the PW identifiers used by the PSN
	tunnel endpoints.		tunnel endpoints.
	o Managing the signaling, timing, order or other aspects of the		o Managing the signaling, timing, order or other aspects of the
	service at the boundaries of the PW.		service at the boundaries of the PW.
	o Service-specific status and alarm management.		o Service-specific status and alarm management.
	1.3 Non-Goals of this document		1.3 Non-Goals of this document
	The following are non-goals for this document:		The following are non-goals for this document:
	o The on-the-wire specification of services encapsulation.		o The on-the-wire specification of PW encapsulations.
	o The detailed definition of the protocols involved in PW		o The detailed definition of the protocols involved in PW
	setup and maintenance.		set-up and maintenance.
	The following are outside the scope of PWE3:		The following are outside the scope of PWE3:
	o Any multicast service not native to the emulated medium.		o Any multicast service not native to the emulated medium.
	Thus, Ethernet transmission to a "multicast" IEEE-48 address		Thus, Ethernet transmission to a "multicast" IEEE-48 address
	is in scope, while multicast services like MARS [RFC2022] that		is in scope, while multicast services like MARS [RFC2022] that
	are implemented on top of the medium are out of scope.		are implemented on top of the medium are out of scope.
	o Methods to signal or control the underlying PSN.		o Methods to signal or control the underlying PSN.
	1.4 Terminology		1.4 Terminology
	Editor's note: Although it was decided at IETF-54 that the PWE3
	common terminology should be published in a separate document, there
	is case for it remaining in the architecture document. If the PWE3-WG
	confirms the desire to have a separate document, we will remove this
	section in the next revision.
	This document uses the following definitions of terms. These terms		This document uses the following definitions of terms. These terms
	are illustrated in context in Figure 2.		are illustrated in context in Figure 2.
	Attachment Circuit The circuit or virtual circuit attaching		Attachment Circuit The circuit or virtual circuit attaching
	(AC) a CE to a PE.		(AC) a CE to a PE.
	Applicability Each PW service will have an Applicability
	Statement (AS) Statement (AS) that describes the applicability
	of PWs for that service.
	CE-bound The traffic direction where PW-PDUs are		CE-bound The traffic direction where PW-PDUs are
	received on a PW via the PSN, processed		received on a PW via the PSN, processed
	and then sent to the destination CE.		and then sent to the destination CE.
	CE Signaling Messages sent and received by the CEs		CE Signaling Messages sent and received by the CEs
	control plane. It may be desirable or		control plane. It may be desirable or
	even necessary for the PE to participate		even necessary for the PE to participate
	in or monitor this signaling in order		in or monitor this signaling in order
	to effectively emulate the service.		to effectively emulate the service.
			Control Word (CW) A four octet header used in some encapsulations
			to carry per packet information when the PSN
			is MPLS.
	Customer Edge (CE) A device where one end of a service		Customer Edge (CE) A device where one end of a service
	originates and/or terminates. The CE is not		originates and/or terminates. The CE is not
	aware that it is using an emulated service		aware that it is using an emulated service
	rather than a native service.		rather than a native service.
	Forwarder (FWRD) A PE subsystem that selects the PW to use to		Forwarder (FWRD) A PE subsystem that selects the PW to use to
	transmit a payload received on an AC.		transmit a payload received on an AC.
	Fragmentation The action of dividing a single PDU into		Fragmentation The action of dividing a single PDU into
	multiple PDUs before transmission with the		multiple PDUs before transmission with the
	intent of the original PDU being reassembled		intent of the original PDU being reassembled
	elsewhere in the network. Fragmentation may be		elsewhere in the network. Fragmentation MAY be
	performed in order to allow sending of packets		performed in order to allow sending of packets
	of a larger size than the network MTU which		of a larger size than the network MTU which
	they will traverse.		they will traverse.
	Maximum transmission The packet size (excluding data link header)		Maximum transmission The packet size (excluding data link header)
	unit (MTU) that an interface can transmit without		unit (MTU) that an interface can transmit without
	needing to fragment.		needing to fragment.
	Native Service Processing of the data received by the PE		Native Service Processing of the data received by the PE
	Processing (NSP) from the CE before presentation to the PW		Processing (NSP) from the CE before presentation to the PW
	for transmission across the core.		for transmission across the core, or
			processing of the data received from a PW
			by a PE before it is output on the AC.
			NSP functionality is defined by standards
			bodies other than the IETF, such as ITU-T,
			ANSI, ATMF, etc.)
	Packet Switched Within the context of PWE3, this is a		Packet Switched Within the context of PWE3, this is a
	Network (PSN) network using IP or MPLS as the mechanism		Network (PSN) network using IP or MPLS as the mechanism
	for packet forwarding.		for packet forwarding.
	Protocol Data The unit of data output to, or received		Protocol Data The unit of data output to, or received
	Unit (PDU) from, the network by a protocol layer.		Unit (PDU) from, the network by a protocol layer.
	Provider Edge (PE) A device that provides PWE3 to a CE.		Provider Edge (PE) A device that provides PWE3 to a CE.
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 33 ¶
	PSN Tunnel A tunnel across a PSN inside which one or		PSN Tunnel A tunnel across a PSN inside which one or
	more PWs can be carried.		more PWs can be carried.
	PSN Tunnel Used to set up, maintain and tear down the		PSN Tunnel Used to set up, maintain and tear down the
	Signaling underlying PSN tunnel.		Signaling underlying PSN tunnel.
	PW Demultiplexer Data-plane method of identifying a PW		PW Demultiplexer Data-plane method of identifying a PW
	terminating at a PE.		terminating at a PE.
	Time Domain Synchronous bit-streams at rates defined by		Time Domain Time Division Multiplexing. Frequently used
	Multiplexing (TDM) G.702.		Multiplexing (TDM) to refer to the synchronous bit-streams at
			rates defined by G.702.
	Tunnel A method of transparently carrying information		Tunnel A method of transparently carrying information
	over a network.		over a network.
	2. PWE3 Applicability		2. PWE3 Applicability
	The PSN carrying a PW will subject payload packets to delay, jitter,		The PSN carrying a PW will subject payload packets to loss, delay,
	network transients and re-ordering. The applicability of PWE3 to a		delay variation, and re-ordering. During a network transient there
	particular service depends on the sensitivity of that service to		may be a sustained period of impaired service. The applicability of
	these effects, and the ability of the adaptation layer to mask them.		PWE3 to a particular service depends on the sensitivity of that
	Some services, such as IP over FR over PWE3, may prove quite		service (or the CE implementation) to these effects, and the ability
	resilient to IP and MPLS PSN characteristics. Other services, such as		of the adaptation layer to mask them. Some services, such as IP over
	the interconnection of PBX systems via PWE3, will require more		FR over PWE3, may prove quite resilient to IP and MPLS PSN
	careful consideration of the PSN and adaptation layer		characteristics. Other services, such as the interconnection of PBX
	characteristics. In some instances, traffic engineering of the		systems via PWE3, will require more careful consideration of the PSN
	underlying PSN will be required, and in some cases the constraints		and adaptation layer characteristics. In some instances, traffic
	may be such that it is not possible to provide the required service		engineering of the underlying PSN will be required, and in some
	guarantees.		cases, the constraints may be such that it is not possible to provide
			the required service guarantees.
	3. Protocol Layering Model		3. Protocol Layering Model
	The PWE3 protocol-layering model is intended to minimise the		The PWE3 protocol-layering model is intended to minimise the
	differences between PWs operating over different PSN types. The		differences between PWs operating over different PSN types. The
	design of the protocol-layering model has the goals of making each PW		design of the protocol-layering model has the goals of making each PW
	definition independent of the underlying PSN, and maximizing the		definition independent of the underlying PSN, and maximizing the
	reuse of IETF protocol definitions and their implementations.		reuse of IETF protocol definitions and their implementations.
	3.1 Protocol Layers		3.1 Protocol Layers
	The logical protocol-layering model required to support a PW is shown		The logical protocol-layering model required to support a PW is shown
	in Figure 1.		in Figure 1.
	+---------------------------+		+---------------------------+
	| Payload |		| Payload |
	+---------------------------+		+---------------------------+
	| Encapsulation | <==== May be empty		| Encapsulation | <==== MAY be null
	+---------------------------+		+---------------------------+
	| PW Demultiplexer |		| PW Demultiplexer |
	+---------------------------+		+---------------------------+
	| PSN Convergence | <==== May be empty		| PSN Convergence | <==== MAY be null
	+---------------------------+		+---------------------------+
	| PSN |		| PSN |
	+---------------------------+		+---------------------------+
	| MAC/Data-link |		| Data-link |
	+---------------------------+		+---------------------------+
	| Physical |		| Physical |
	+---------------------------+		+---------------------------+
	Figure 1: Logical Protocol Layering Model		Figure 1: Logical Protocol Layering Model
	The payload is transported over the Encapsulation Layer. The		The payload is transported over the Encapsulation Layer. The
	Encapsulation Layer carries any information, not already present		Encapsulation Layer carries any information, not already present
	within the payload itself, that is needed by the PW CE-bound PE		within the payload itself, that is needed by the PW CE-bound PE
	interface to send the payload to the CE via the physical interface.		interface to send the payload to the CE via the physical interface.
	If no information is needed beyond that in the payload itself, this		If no information is needed beyond that in the payload itself, this
	layer is empty.		layer is empty.
	This layer also provides support for real-time processing, and		This layer also provides support for real-time processing, and
	sequencing, if needed.		sequencing, if needed.
	The PW Demultiplexer Layer provides the ability to deliver multiple		The PW Demultiplexer Layer provides the ability to deliver multiple
	PWs over a single PSN tunnel. The PW demultiplexer value used to		PWs over a single PSN tunnel. The PW demultiplexer value used to
	identify the PW in the data-plane may be unique per PE, but this is		identify the PW in the data-plane may be unique per PE, but this is
	not a PWE3 requirement. It must, however, be unique per tunnel		not a PWE3 requirement. It MUST, however, be unique per tunnel
	endpoint. If it is necessary to identify a particular tunnel, then		endpoint. If it is necessary to identify a particular tunnel, then
	that is the responsibility of the PSN layer.		that is the responsibility of the PSN layer.
	The PSN Convergence Layer provides the enhancements needed to make		The PSN Convergence Layer provides the enhancements needed to make
	the PSN conform to the assumed PSN service requirement. This layer		the PSN conform to the assumed PSN service requirement. This layer
	therefore provides a consistent interface to the PW, making the PW		therefore provides a consistent interface to the PW, making the PW
	independent of the PSN type. If the PSN already meets the service		independent of the PSN type. If the PSN already meets the service
	requirements, this layer is empty.		requirements, this layer is empty.
	The PSN header, MAC/Data-link and Physical Layer definitions are		The PSN header, MAC/Data-link and Physical Layer definitions are
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 27 ¶
	o Packet		o Packet
	o Cell		o Cell
	o Bit-stream		o Bit-stream
	o Structured bit-stream		o Structured bit-stream
	Within these generic types there are specific service types. For		Within these generic types there are specific service types. For
	example:		example:
	Generic Payload Type PW Service		Generic Payload Type PW Service
	-------------------- ----------		-------------------- ----------
	Packet Ethernet (all types), HDLC,		Packet Ethernet (all types), HDLC framing,
	frame-relay, ATM AAL5 PDU.		frame-relay, ATM AAL5 PDU.
	Cell ATM.		Cell ATM.
	Bit-stream SONET, TDM (e.g. DS1, DS3, E1).		Bit-stream Unstructured E1, T1, E3, T3.
	Structured bit-stream SONET, TDM.		Structured bit-stream SONET/SDH (e.g. SPE, VT, NxDS0).
	3.3.1. Packet Payload		3.3.1. Packet Payload
	A packet payload is a variable-size data unit presented to the PE on		A packet payload is a variable-size data unit presented to the PE on
	the AC. A packet payload may be large compared to the PSN MTU. The		the AC. A packet payload may be large compared to the PSN MTU. The
	delineation of the packet boundaries is encapsulation-specific. HDLC		delineation of the packet boundaries is encapsulation-specific. HDLC
	or Ethernet PDUs can be considered as examples of packet payloads.		or Ethernet PDUs can be considered as examples of packet payloads.
	Typically a packet will be stripped of transmission overhead such as		Typically a packet will be stripped of transmission overhead such as
	HDLC flags and stuffing bits before transmission over the PW.		HDLC flags and stuffing bits before transmission over the PW.
	A packet payload would normally be relayed across the PW as a single		A packet payload would normally be relayed across the PW as a single
	unit. However, there will be cases where the combined size of the		unit. However, there will be cases where the combined size of the
	packet payload and its associated PWE3 and PSN headers exceeds the		packet payload and its associated PWE3 and PSN headers exceeds the
	PSN path MTU. In these cases, some fragmentation methodology needs		PSN path MTU. In these cases, some fragmentation methodology needs
	to be applied. This may, for example, be the case when a user is		to be applied. This may, for example, be the case when a user is
	providing the service and attaching to the service provider via an		providing the service and attaching to the service provider via
	Ethernet, or where nested pseudo-wires are involved. Fragmentation is		Ethernet, or where nested pseudo-wires are involved. Fragmentation is
	discussed in more detail in Section 5.3		discussed in more detail in Section 5.3
	A packet payload may need sequencing and real-time support.		A packet payload may need sequencing and real-time support.
	In some situations, the packet payload may be selected from the		In some situations, the packet payload MAY be selected from the
	packets presented on the emulated wire on the basis of some sub-		packets presented on the emulated wire on the basis of some sub-
	multiplexing technique. For example, one or more frame-relay PDUs		multiplexing technique. For example, one or more frame-relay PDUs
	may be selected for transport over a particular pseudo-wire based on		may be selected for transport over a particular pseudo-wire based on
	the frame-relay Data-Link Connection Identifier (DLCI), or, in the		the frame-relay Data-Link Connection Identifier (DLCI), or, in the
	case of Ethernet payloads, on the basis of the VLAN identifier. This		case of Ethernet payloads, using a suitable MAC bridge filter. This
	is an FWRD function, and this selection would therefore be made		is an FWRD function, and this selection would therefore be made
	before the packet was presented to the PW Encapsulation Layer.		before the packet was presented to the PW Encapsulation Layer.
	3.3.2. Cell Payload		3.3.2. Cell Payload
	A cell payload is created by capturing, transporting and replaying		A cell payload is created by capturing, transporting and replaying
	groups of bits presented on the wire in a fixed-size format. The		groups of octets presented on the wire in a fixed-size format. The
	delineation of the group of bits that comprise the cell is specific		delineation of the group of bits that comprise the cell is specific
	to the encapsulation type. Two common examples of cell payloads are		to the encapsulation type. Two common examples of cell payloads are
	ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream		ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream
	packets [ETSI].		packets [DVB].
	To reduce per-PSN packet overhead, multiple cells may be concatenated		To reduce per-PSN packet overhead, multiple cells MAY be concatenated
	into a single payload. The Encapsulation Layer may consider the		into a single payload. The Encapsulation Layer MAY consider the
	payload complete on the expiry of a timer, after a fixed number of		payload complete on the expiry of a timer, after a fixed number of
	cells have been received or when a significant cell (e.g. an ATM OAM		cells have been received or when a significant cell (e.g. an ATM OAM
	cell) has been received. The benefit of concatenating multiple PDUs		cell) has been received. The benefit of concatenating multiple PDUs
	should be weighed against the resulting increase in jitter and the		should be weighed against a possible increase in packet delay
	larger penalty incurred by packet loss. In some cases, it may be		variation and the larger penalty incurred by packet loss. In some
	appropriate for the Encapsulation Layer to perform a silence		cases, it may be appropriate for the Encapsulation Layer to perform
	suppression or a similar compression.		some type of compression, such as silence suppression or voice
			compression.
	The generic cell payload service will normally need sequence number		The generic cell payload service will normally need sequence number
	support, and may also need real-time support. The generic cell		support, and may also need real-time support. The generic cell
	payload service would not normally require fragmentation.		payload service would not normally require fragmentation.
	The Encapsulation Layer may apply some form of compression to some of		The Encapsulation Layer MAY apply some form of compression to some of
	these sub-types (e.g. idle cells may be suppressed).		these sub-types (e.g. idle cells MAY be suppressed).
	In some instances, the cells to be incorporated in the payload may be		In some instances, the cells to be incorporated in the payload MAY be
	selected by filtering them from the stream of cells presented on the		selected by filtering them from the stream of cells presented on the
	wire. For example, an ATM PWE3 service may select cells based on		wire. For example, an ATM PWE3 service may select cells based on
	their VCI or VPI fields. This is an FWRD function, and the selection		their VCI or VPI fields. This is an FWRD function, and the selection
	would therefore be made before the packet was presented to the PW		would therefore be made before the packet was presented to the PW
	Encapsulation Layer.		Encapsulation Layer.
	3.3.3. Bit-stream		3.3.3. Bit-stream
	A bit-stream payload is created by capturing, transporting and		A bit-stream payload is created by capturing, transporting and
	replaying the bit pattern on the emulated wire, without taking		replaying the bit pattern on the emulated wire, without taking
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 29 ¶
	3.3.4. Structured bit-stream		3.3.4. Structured bit-stream
	A structured bit-stream payload is created by using some knowledge of		A structured bit-stream payload is created by using some knowledge of
	the underlying structure of the bit-stream to capture, transport and		the underlying structure of the bit-stream to capture, transport and
	replay the bit pattern on the emulated wire.		replay the bit pattern on the emulated wire.
	Two important points distinguish structured and unstructured bit-		Two important points distinguish structured and unstructured bit-
	streams:		streams:
	o Some part of the original bit-stream are stripped in		o Some parts of the original bit-stream MAY be stripped in the
	the PSN-bound direction by NSP block. For example,		PSN-bound direction by NSP block. For example, in Structured
	in Structured SONET the section and line overhead (and,		SONET the section and line overhead (and, possibly more) may
	possibly, more) may be stripped.		be stripped. A framer is required to enable such stripping.
			It is also required for frame/payload alignment for
			fractional T1/E1 applications.
	o The PW must preserve the structure across the PSN so that		o The PW MUST preserve the structure across the PSN so that
	the CE-bound NSP block can insert it correctly into the		the CE-bound NSP block can insert it correctly into the
	reconstructed unstructured bit-stream.		reconstructed unstructured bit-stream. The stripped
			information (such as SONET pointer justifications) may
			appear in the encapsulation layer to facilitate this
			reconstitution.
	The Encapsulation Layer may also perform silence/idle suppression or		As an option, the Encapsulation Layer MAY also perform silence/idle
	similar compression on a structured bit-stream.		suppression or similar compression on a structured bit-stream.
	Structured bit-streams are distinguished from cells in that the		Structured bit-streams are distinguished from cells in that the
	structures may be too long to be carried in a single packet. Note		structures may be too long to be carried in a single packet. Note
	that "short" structures are indistinguishable from cells and may		that "short" structures are indistinguishable from cells and may
	benefit from the use of those PWE3 methods.		benefit from the use of methods described in section 3.3.2.
	This service will require sequencing and real-time support.		This service REQUIRES sequencing and real-time support.
	3.3.5. Principle of Minimum Intervention		3.3.5. Principle of Minimum Intervention
	To minimise the scope of information, and to improve the efficiency		To minimise the scope of information, and to improve the efficiency
	of data flow through the Encapsulation Layer, the payload should be		of data flow through the Encapsulation Layer, the payload SHOULD be
	transported as received with as few modifications as possible		transported as received with as few modifications as possible
	[RFC1958].		[RFC1958].
	This minimum intervention approach decouples payload development from		This minimum intervention approach decouples payload development from
	PW development and requires fewer translations at the NSP in a system		PW development and requires fewer translations at the NSP in a system
	with similar CE interfaces at each end. It also prevents unwanted		with similar CE interfaces at each end. It also prevents unwanted
	side-effects due to subtle mis-representation of the payload in the		side-effects due to subtle misrepresentation of the payload in the
	intermediate format.		intermediate format.
	An intervention approach can be more wire-efficient in some cases and		An approach which does intervene can be more wire-efficient in some
	may result in fewer translations at the NSP where the CE interfaces		cases and may result in fewer translations at the NSP where the CE
	are of different types. Any intermediate format effectively becomes a		interfaces are of different types. Any intermediate format
	new framing type, requiring documentation and assured		effectively becomes a new framing type, requiring documentation and
	interoperability. This increases the amount of work for handling the		assured interoperability. This increases the amount of work for
	protocol the intermediate format carries, and is undesirable.		handling the protocol the intermediate format carries, and is
			undesirable.
	4. Architecture of Pseudo-wires		4. Architecture of Pseudo-wires
	This section describes the PWE3 architectural model.		This section describes the PWE3 architectural model.
	4.1 Network Reference Model		4.1 Network Reference Model
	Figure 2 illustrates the network reference model for point-to-point		Figure 2 illustrates the network reference model for point-to-point
	PWs.		PWs.
	skipping to change at page 14, line 42 ¶		skipping to change at page 15, line 33 ¶
	| |		| |
	native service native service		native service native service
	Figure 2: PWE3 Network Reference Model		Figure 2: PWE3 Network Reference Model
	The two PEs (PE1 and PE2) need to provide one or more PWs on behalf		The two PEs (PE1 and PE2) need to provide one or more PWs on behalf
	of their client CEs (CE1 and CE2) to enable the client CEs to		of their client CEs (CE1 and CE2) to enable the client CEs to
	communicate over the PSN. A PSN tunnel is established to provide a		communicate over the PSN. A PSN tunnel is established to provide a
	data path for the PW. The PW traffic is invisible to the core		data path for the PW. The PW traffic is invisible to the core
	network, and the core network is transparent to the CEs. Native data		network, and the core network is transparent to the CEs. Native data
	units (bits, cells or packets) presented at the PW End Service (PWES)		units (bits, cells or packets) presented to the PW End Service (PWES)
	are encapsulated in a PW-PDU and carried across the underlying		are encapsulated in a PW-PDU and carried across the underlying
	network via the PSN tunnel. The PEs perform the necessary		network via the PSN tunnel. The PEs perform the necessary
	encapsulation and decapsulation of PW-PDUs, as well as handling any		encapsulation and decapsulation of PW-PDUs, as well as handling any
	other functions required by the PW service, such as sequencing or		other functions required by the PW service, such as sequencing or
	timing.		timing. A PE MAY provide multiple PWESs.
	There are situations in which a particular packet payload needs to be
	multicast so that it is received by a number of CEs. This is useful
	when using PWs as part of a "virtual LAN" service (see, e.g.,
	[VPLS]). This can be achieved by replicating the payload and
	transmitting the replicas on PWs, but it may also be useful to have a
	type of PW that is inherently point-to-multipoint. In that case, the
	PW would need to be carried through a point-to-multipoint PSN tunnel,
	employing a multicast mechanism provided by the PSN.
	4.2 PWE3 Pre-processing		4.2 PWE3 Pre-processing
	In some applications, there is a need to perform operations on the		In some applications, there is a need to perform operations on the
	native data units received from the CE (including both payload and		native data units received from the CE (including both payload and
	signaling traffic) before they are transmitted across the PW by the		signaling traffic) before they are transmitted across the PW by the
	PE. Examples include Ethernet bridging, SONET cross-connect,		PE. Examples include Ethernet bridging, SONET cross-connect,
	translation of locally-significant identifiers such as VCI/VPI, or		translation of locally-significant identifiers such as VCI/VPI, or
	translation to another service type. These operations could be		translation to another service type. These operations could be
	carried out in external equipment, and the processed data sent to the		carried out in external equipment, and the processed data sent to the
	skipping to change at page 17, line 8 ¶		skipping to change at page 17, line 13 ¶
	o Native Service Processing (NSP)		o Native Service Processing (NSP)
	4.2.1. Forwarders		4.2.1. Forwarders
	In some applications there is the need to selectively forward payload		In some applications there is the need to selectively forward payload
	elements from one of more ACs to one or more PWs. In such cases there		elements from one of more ACs to one or more PWs. In such cases there
	will also be the need to perform the inverse function on PWE3-PDUs		will also be the need to perform the inverse function on PWE3-PDUs
	received by a PE from the PSN. This is the function of the FWRD.		received by a PE from the PSN. This is the function of the FWRD.
	The FWRD selects the PW based on, for example: the incoming AC, the		The FWRD selects the PW based on, for example: the incoming AC, the
	contents of the payload, or some statically- or dynamically-		contents of the payload, or some statically and/or dynamically
	configured forwarding information.		configured forwarding information.
	+----------------------------------------+		+----------------------------------------+
	| PE Device |		| PE Device |
	+----------------------------------------+		+----------------------------------------+
	Single | | |		Single | | |
	PWES | | Single | PW Instance		PWES | | Single | PW Instance
	<------>o Forwarder + PW Instance X<===========>		<------>o Forwarder + PW Instance X<===========>
	| | |		| | |
	+----------------------------------------+		+----------------------------------------+
	skipping to change at page 17, line 30 ¶		skipping to change at page 17, line 35 ¶
	Figure 4a: Simple point-to-point service		Figure 4a: Simple point-to-point service
	+----------------------------------------+		+----------------------------------------+
	| PE Device |		| PE Device |
	+----------------------------------------+		+----------------------------------------+
	Multiple| | Single | PW Instance		Multiple| | Single | PW Instance
	PWES | + PW Instance X<===========>		PWES | + PW Instance X<===========>
	<------>o | |		<------>o | |
	| |----------------------|		| |----------------------|
	<------>o | Single | PW Instance		<------>o | Single | PW Instance
	| + PW Instance X<===========>		| Forwarder + PW Instance X<===========>
	<------>o | |		<------>o | |
	| Forwarder |----------------------|		| |----------------------|
	<------>o | Single | PW Instance		<------>o | Single | PW Instance
	| + PW Instance X<===========>		| + PW Instance X<===========>
	<------>o | |		<------>o | |
	| |----------------------| Multipoint
	| | Multipoint | PW Instance
	| + PW Instance X<===========>
	| | |
	+----------------------------------------+		+----------------------------------------+
	Figure 4b: Multiple PWEs to Multiple PW Forwarding		Figure 4b: Multiple PWES to Multiple PW Forwarding
	Figure 4a shows a simple FWRD that performs some type of filtering		Figure 4a shows a simple FWRD that performs some type of filtering
	operation. Because the FWRD has a single input and a single output		operation. Because the FWRD has a single input and a single output
	interface, filtering is the only type of forwarding operation that		interface, filtering is the only type of forwarding operation that
	applies. Figure 4b shows a more general forwarding situation where		applies. Figure 4b shows a more general forwarding situation where
	payloads are extracted from one or more PWESs and directed to one or		payloads are extracted from one or more PWESs and directed to one or
	more PWs, including, in this instance, a multipoint PW. In this case		more PWs, including, in this instance, a multipoint PW. In this case
	both filtering and direction operations may be performed on the		both filtering and direction operations MAY be performed on the
	payloads.		payloads.
	4.2.2. Native Service Processing		4.2.2. Native Service Processing
	In some applications some form of data or address translation, or		In some applications some form of data or address translation, or
	other operation requiring knowledge of the semantics of the payload,		other operation requiring knowledge of the semantics of the payload,
	will be required. This is the function of the Native Service		will be required. This is the function of the Native Service
	Processor (NSP).		Processor (NSP).
	The use of the NSP approach simplifies the design of the PW by		The use of the NSP approach simplifies the design of the PW by
	skipping to change at page 18, line 28 ¶		skipping to change at page 18, line 28 ¶
	PWE3.		PWE3.
	+----------------------------------------+		+----------------------------------------+
	| PE Device |		| PE Device |
	Multiple+----------------------------------------+		Multiple+----------------------------------------+
	PWES | | | Single | PW Instance		PWES | | | Single | PW Instance
	<------>o NSP # + PW Instance X<===========>		<------>o NSP # + PW Instance X<===========>
	| | | |		| | | |
	|------| |----------------------|		|------| |----------------------|
	| | | Single | PW Instance		| | | Single | PW Instance
	<------>o NSP # + PW Instance X<===========>		<------>o NSP #Forwarder + PW Instance X<===========>
	| | | |		| | | |
	|------|Forwarder |----------------------|		|------| |----------------------|
	| | | Single | PW Instance		| | | Single | PW Instance
	<------>o NSP # + PW Instance X<===========>		<------>o NSP # + PW Instance X<===========>
	| | | |		| | | |
	|------| |----------------------| Multipoint
	| | | Multipoint | PW Instance
	<------>o NSP # + PW Instance X<===========>
	| | | |
	+----------------------------------------+		+----------------------------------------+
	Figure 5: NSP in a Multiple PWEs to Multiple		Figure 5: NSP in a Multiple PWEs to Multiple
	PW Forwarding PE		PW Forwarding PE
	Figure 5 illustrates the relationship between NSP, FWRD and PWs in a		Figure 5 illustrates the relationship between NSP, FWRD and PWs in a
	PE. The NSP function may apply any transformation operation		PE. The NSP function MAY apply any transformation operation
	(modification, injection, etc.) on the payloads as they pass between		(modification, injection, etc.) on the payloads as they pass between
	the physical interface to the CE and the virtual interface to the		the physical interface to the CE and the virtual interface to the
	FWRD. A PE device may contain more than one FWRD.		FWRD. A PE device MAY contain more than one FWRD.
	This model also supports the operation of a system in which the NSP		This model also supports the operation of a system in which the NSP
	functionality includes terminating the data-link and applying Network		functionality includes terminating the data-link, and applying
	Layer processing to the payload is also supported.		Network Layer processing to the payload is also supported.
	4.3 Maintenance Reference Model		4.3 Maintenance Reference Model
	Figure 6 illustrates the maintenance reference model for PWs.		Figure 6 illustrates the maintenance reference model for PWs.
	|<------- CE (end-to-end) Signaling ------>|		|<------- CE (end-to-end) Signaling ------>|
	| |<---- PW/PE Maintenance ----->| |		| |<---- PW/PE Maintenance ----->| |
	| | |<-- PSN Tunnel -->| | |		| | |<-- PSN Tunnel -->| | |
	| | | Signaling | | |		| | | Signaling | | |
	| V V (out of scope) V V |		| V V (out of scope) V V |
	skipping to change at page 19, line 30 ¶		skipping to change at page 19, line 26 ¶
	| |-----|.............PW1..............|-----| |		| |-----|.............PW1..............|-----| |
	| CE1 | | | | | | CE2 |		| CE1 | | | | | | CE2 |
	| |-----|.............PW2..............|-----| |		| |-----|.............PW2..............|-----| |
	+-----+ | |==================| | +-----+		+-----+ | |==================| | +-----+
	+-----+ +-----+		+-----+ +-----+
	Customer Provider Provider Customer		Customer Provider Provider Customer
	Edge 1 Edge 1 Edge 2 Edge 2		Edge 1 Edge 1 Edge 2 Edge 2
	Figure 6: PWE3 Maintenance Reference Model		Figure 6: PWE3 Maintenance Reference Model
	The following signaling mechanisms are required:		The following signaling mechanisms are REQUIRED:
	o The CE (end-to-end) signaling is between the CEs. This		o The CE (end-to-end) signaling is between the CEs. This
	signaling could be frame relay PVC status signaling, ATM SVC		signaling could be frame relay PVC status signaling, ATM SVC
	signaling, etc.		signaling, TDM CAS signaling, etc.
	o The PW/PE Maintenance is used between the PEs (or NSPs) to set		o The PW/PE Maintenance is used between the PEs (or NSPs) to set
	up, maintain and tear down PWs, including any required		up, maintain and tear down PWs, including any required
	coordination of parameters.		coordination of parameters.
	o The PSN Tunnel signaling controls the PW multiplexing and some		o The PSN Tunnel signaling controls the PW multiplexing and some
	elements of the underlying PSN. Examples are L2TP control		elements of the underlying PSN. Examples are L2TP control
	protocol, MPLS LDP and RSVP-TE. The definition of the		protocol, MPLS LDP and RSVP-TE. The definition of the
	information that PWE3 needs to be signaled is within the scope		information that PWE3 needs to be signaled is within the scope
	of PWE3, but the signaling protocol itself is not.		of PWE3, but the signaling protocol itself is not.
	skipping to change at page 20, line 35 ¶		skipping to change at page 20, line 35 ¶
	connection to its peer at the far end. Native service PDUs from the		connection to its peer at the far end. Native service PDUs from the
	CE are passed through an Encapsulation Layer at the sending PE, and		CE are passed through an Encapsulation Layer at the sending PE, and
	then sent over the PSN. The receiving PE removes the encapsulation		then sent over the PSN. The receiving PE removes the encapsulation
	and restores the payload to its native format for transmission to the		and restores the payload to its native format for transmission to the
	destination CE.		destination CE.
	4.5 Pre-processing Extension to Protocol Stack Reference Model		4.5 Pre-processing Extension to Protocol Stack Reference Model
	Figure 8 illustrates how the protocol stack reference model is		Figure 8 illustrates how the protocol stack reference model is
	extended to include the provision of pre-processing (Forwarding and		extended to include the provision of pre-processing (Forwarding and
	NSP). This shows the ideal placement of the physical interface		NSP). This shows the placement of the physical interface relative to
	relative to the CE.		the CE.
	/======================================\		/======================================\
	H Forwarder H<----Pre-processing		H Forwarder H<----Pre-processing
	H----------------======================/		H----------------======================/
	H Native Service H | |		H Native Service H | |
	H Processing H | |		H Processing H | |
	\================/ | |		\================/ | |
	| | | Emulated |		| | | Emulated |
	| Service | | Service |		| Service | | Service |
	| Interface | | (TDM, ATM, |		| Interface | | (TDM, ATM, |
	skipping to change at page 22, line 23 ¶		skipping to change at page 22, line 23 ¶
	H Timing H		H Timing H
	H---------------------------H		H---------------------------H
	H Sequencing H		H Sequencing H
	\===========================/		\===========================/
	| PW Demultiplexer |		| PW Demultiplexer |
	+---------------------------+		+---------------------------+
	| PSN Convergence |		| PSN Convergence |
	+---------------------------+		+---------------------------+
	| PSN |		| PSN |
	+---------------------------+		+---------------------------+
	| MAC/Data-link |		| Data-link |
	+---------------------------+		+---------------------------+
	| Physical |		| Physical |
	+---------------------------+		+---------------------------+
	Figure 9: PWE3 Encapsulation Layer in Context		Figure 9: PWE3 Encapsulation Layer in Context
	The Payload Convergence Sub-layer is highly tailored to the specific		The Payload Convergence Sub-layer is highly tailored to the specific
	payload type, but, by grouping a number of target payload types into		payload type, but, by grouping a number of target payload types into
	a generic class, and then providing a single convergence sub-layer		a generic class, and then providing a single convergence sub-layer
	type common to the group, we achieve a reduction in the number of		type common to the group, we achieve a reduction in the number of
	payload convergence sub-layer types. This decreases implementation		payload convergence sub-layer types. This decreases implementation
	complexity. The provision of per-packet signaling and other out-of-		complexity. The provision of per-packet signaling and other out-of-
	band information (other than sequencing or timing) is undertaken by		band information (other than sequencing or timing) is undertaken by
	this layer.		this layer.
	The Timing Layer and the Sequencing Layer provide generic services to		The Timing Layer and the Sequencing Layer provide generic services to
	the Payload Convergence Layer for all payload types, when required.		the Payload Convergence Layer for all payload types that require
			them.
	5.1 Payload Convergence Layer		5.1 Payload Convergence Layer
	5.1.1. Encapsulation		5.1.1. Encapsulation
	The primary task of the Payload Convergence Layer is the		The primary task of the Payload Convergence Layer is the
	encapsulation of the payload in PW-PDUs. The native data units to be		encapsulation of the payload in PW-PDUs. The native data units to be
	encapsulated may or may not contain a L2 header or L1 overhead. This		encapsulated MAY contain a L2 header or L1 overhead. This is service
	is service specific. The Payload Convergence header carries the		specific. The Payload Convergence header carries the additional
	additional information needed to replay the native data units at the		information needed to replay the native data units at the CE-bound
	CE-bound physical interface. The PW Demultiplexer header is not		physical interface. The PW Demultiplexer header is not considered as
	considered as part of the PW header.		part of the PW header.
	Not all the additional information needed to replay the native data		Not all the additional information needed to replay the native data
	units need to be carried in the PW header of the PW PDUs. Some		units need to be carried in the PW header of the PW PDUs. Some
	information (e.g. service type of a PW) may be stored as state		information (e.g. service type of a PW) MAY be stored as state
	information at the destination PE during PW set-up.		information at the destination PE during PW set-up.
	5.1.2. PWE3 Channel Types		5.1.2. PWE3 Channel Types
	The PW Encapsulation Layer and its associated signaling require one		The PW Encapsulation Layer and its associated signaling require one
	or more of the following types of channels from its underlying PW		or more of the following types of channels from its underlying PW
	Demultiplexer and PSN Layers:		Demultiplexer and PSN Layers:
	1. A reliable control channel for signaling line events, status		1. A reliable control channel for signaling line events, status
	indications, and, in some exceptional cases, CE-CE events		indications, and, in some exceptional cases, CE-CE events
	skipping to change at page 23, line 29 ¶		skipping to change at page 23, line 30 ¶
	For example, this capability is needed in [PPPoL2TP]		For example, this capability is needed in [PPPoL2TP]
	(PPP negotiation has to be split between the two ends of the		(PPP negotiation has to be split between the two ends of the
	tunnel). PWE3 may also need this type of control channel to		tunnel). PWE3 may also need this type of control channel to
	provide faithful emulation of complex data-link protocols.		provide faithful emulation of complex data-link protocols.
	plus one or more data channels with the following characteristics:		plus one or more data channels with the following characteristics:
	2. A high-priority, unreliable, sequenced channel. A typical use		2. A high-priority, unreliable, sequenced channel. A typical use
	is for CE-to-CE signaling. "High priority" may simply be		is for CE-to-CE signaling. "High priority" may simply be
	indicated via DSCP/EXP bits for priority during transit.		indicated via the DSCP bits for IP or the EXP bits for MPLS,
	This channel type could also use a bit in the tunnel header		giving the packet priority during transit. This channel type
	itself to indicate that packets received at the PE should be		could also use a bit in the tunnel header itself to indicate
	processed with higher priority [RFC2474].		that packets received at the PE SHOULD be processed with higher
			priority [RFC2474].
	3. A sequenced channel for data traffic that is sensitive to		3. A sequenced channel for data traffic that is sensitive to
	packet reordering (one classification for use could be for		packet reordering (one classification for use could be for
	any non-IP traffic).		any non-IP traffic).
	4. An un-sequenced channel for data traffic insensitive to packet		4. An un-sequenced channel for data traffic insensitive to packet
	order.		order.
	The data channels (2, 3 and 4 above) should be carried "in band" with		The data channels (2, 3 and 4 above) SHOULD be carried "in band" with
	one another to as much of a degree as is reasonably possible on a		one another to as much of a degree as is reasonably possible on a
	PSN.		PSN.
	Where end-to-end connectivity may be disrupted by address translation		Where end-to-end connectivity may be disrupted by address translation
	[RFC3022], access-control lists, firewalls etc., there exists the		[RFC3022], access-control lists, firewalls etc., there exists the
	possibility that the control channel may be able to pass traffic and		possibility that the control channel may be able to pass traffic and
	set up the PW, but the PW data traffic is blocked by one or more of		set-up the PW, but the PW data traffic is blocked by one or more of
	these mechanisms. In these cases unless the control channel is also		these mechanisms. In these cases unless the control channel is also
	carried "in band" the signaling to set-up the PW will not confirm		carried "in band" the signaling to set-up the PW will not confirm the
	the existence of an end-to-end data path.		existence of an end-to-end data path.
	In some cases there is a need to synchronize CE events with the data		In some cases there is a need to synchronize CE events with the data
	carried over a PW. This is especially the case with TDM circuits		carried over a PW. This is especially the case with TDM circuits
	(e.g., the on-hook/off-hook events in PSTN switches might be carried		(e.g., the on-hook/off-hook events in PSTN switches might be carried
	over a reliable control channel, whilst the associated bit-stream is		over a reliable control channel, whilst the associated bit-stream is
	carried over a sequenced data channel).		carried over a sequenced data channel).
	PWE3 channel types that are not needed by the supported PWs need not		PWE3 channel types that are not needed by the supported PWs need not
	be included in such an implementation.		be included in such an implementation.
	5.1.3. Quality of Service Considerations		5.1.3. Quality of Service Considerations
	Where possible, it is desirable to employ mechanisms to provide PW		Where possible, it is desirable to employ mechanisms to provide PW
	Quality of Service (QoS) support over PSNs.		Quality of Service (QoS) support over PSNs.
	5.2 Payload-independent PW Encapsulation Layers		5.2 Payload-independent PW Encapsulation Layers
	Two PWE3 Encapsulation Sub-layers provide common services to all		Two PWE3 Encapsulation Sub-layers provide common services to all
	payload types: Sequencing and Timing. These services are optional		payload types: Sequencing and Timing. These services are optional
	and are only used if needed by a particular PW instance. If the		and are only used if needed by a particular PW instance. If the
	service is not needed, the associated header may be omitted in order		service is not needed, the associated header MAY be omitted in order
	to conserve processing and network resources.		to conserve processing and network resources.
	There will be instances where a specific payload type will be		There will be instances where a specific payload type will be
	required to be transported with or without sequence and/or real-time		required to be transported with or without sequence and/or real-time
	support. For example, an invariant of frame relay transport is the		support. For example, an invariant of frame relay transport is the
	preservation of packet order. Some frame-relay applications expect		preservation of packet order. Some frame-relay applications expect
	in-order delivery, and may not cope with reordering of the frames.		in-order delivery, and may not cope with reordering of the frames.
	However, where the frame relay service is itself only being used to		However, where the frame relay service is itself only being used to
	carry IP, it may be desirable to relax that constraint in return for		carry IP, it may be desirable to relax that constraint in return for
	reduced per-packet processing cost.		reduced per-packet processing cost.
	The guiding principle is that, where possible, an existing IETF		The guiding principle is that, where possible, an existing IETF
	protocol should be used to provide these services. Where a suitable		protocol SHOULD be used to provide these services. Where a suitable
	protocol is not available, the existing protocol should be extended		protocol is not available, the existing protocol should be extended
	or modified to meet the PWE3 requirements, thereby making that		or modified to meet the PWE3 requirements, thereby making that
	protocol available for other IETF uses. In the particular case of		protocol available for other IETF uses. In the particular case of
	timing, more than one general method may be necessary to provide for		timing, more than one general method may be necessary to provide for
	the full scope of payload timing requirements.		the full scope of payload timing requirements.
	5.2.1. Sequencing		5.2.1. Sequencing
	The sequencing function provides three services: frame ordering,		The sequencing function provides three services: frame ordering,
	frame duplication detection and frame loss detection. These services		frame duplication detection and frame loss detection. These services
	allow the emulation of the invariant properties of a physical wire.		allow the emulation of the invariant properties of a physical wire.
	Support for sequencing depends on the payload type, and may be		Support for sequencing depends on the payload type, and MAY be
	omitted if not needed.		omitted if not needed.
	The size of the sequence-number space depends on the speed of the		The size of the sequence-number space depends on the speed of the
	emulated service, and the maximum time of the transient conditions in		emulated service, and the maximum time of the transient conditions in
	the PSN. A sequence number space greater than approximately 2^16 may		the PSN. A sequence number space greater than 2^16 may therefore be
	therefore be needed to prevent the sequence number space wrapping		needed to prevent the sequence number space wrapping during the
	during the transient.		transient.
	5.2.1.1 Frame Ordering		5.2.1.1 Frame Ordering
	When packets carrying the PW-PDUs traverse a PSN, they may arrive out		When packets carrying the PW-PDUs traverse a PSN, they may arrive out
	of order at the destination PE. For some services, the frames		of order at the destination PE. For some services, the frames
	(control frames, data frames, or both control and data frames) must		(control frames, data frames, or both control and data frames) MUST
	be delivered in order. For such services, some mechanism must be		be delivered in order. For such services, some mechanism MUST be
	provided for ensuring in-order delivery. Providing a sequence number		provided for ensuring in-order delivery. Providing a sequence number
	in the sequence sub-layer header for each packet is one possible		in the sequence sub-layer header for each packet is one possible
	approach to out-of-sequence detection. Alternatively it can be noted		approach to out-of-sequence detection. Alternatively it can be noted
	that sequencing is a subset of the problem of delivering timed		that sequencing is a subset of the problem of delivering timed
	packets, and that a single combined mechanism such as [RFC1889] may		packets, and that a single combined mechanism such as [RFC1889] MAY
	be employed.		be employed.
	There are two possible misordering strategies:		There are two possible misordering strategies:
	o Drop misordered PW PDUs.		o Drop misordered PW PDUs.
	o Try to sort PW PDUs into the correct order.		o Try to sort PW PDUs into the correct order.
	The choice of strategy will depend on:		The choice of strategy will depend on:
	skipping to change at page 25, line 43 ¶		skipping to change at page 25, line 46 ¶
	o The speeds of the PW and PSN.		o The speeds of the PW and PSN.
	o The acceptable delay (since delay must be introduced to		o The acceptable delay (since delay must be introduced to
	reorder)		reorder)
	o The incidence of expected misordering.		o The incidence of expected misordering.
	5.2.1.2 Frame Duplication Detection		5.2.1.2 Frame Duplication Detection
	In rare cases, packets traversing a PW may be duplicated by the		In rare cases, packets traversing a PW may be duplicated by the
	underlying PSN. For some services, frame duplication is not		underlying PSN. For some services frame duplication is not
	acceptable. For such services, some mechanism must be provided to		acceptable. For such services, some mechanism MUST be provided to
	ensure that duplicated frames will not be delivered to the		ensure that duplicated frames will not be delivered to the
	destination CE. The mechanism may or may not be the same as the		destination CE. The mechanism MAY be the same as the mechanism used
	mechanism used to ensure in-order frame delivery.		to ensure in-order frame delivery.
	5.2.1.3 Frame Loss Detection		5.2.1.3 Frame Loss Detection
	A destination PE can determine whether a frame has been lost by		A destination PE can determine whether a frame has been lost by
	tracking the sequence numbers of the received PW PDUs.		tracking the sequence numbers of the received PW PDUs.
	In some instances, a destination PE will have to presume that a PW		In some instances, a destination PE will have to presume that a PW
	PDU is lost if it fails to arrive within a certain time. If a PW-PDU		PDU is lost if it fails to arrive within a certain time. If a PW-PDU
	that has been processed as lost subsequently arrives, the destination		that has been processed as lost subsequently arrives, the destination
	PE must discard it.		PE MUST discard it.
	5.2.2. Timing		5.2.2. Timing
	A number of native services have timing expectations based on the		A number of native services have timing expectations based on the
	characteristics of the networks that they were designed to travel		characteristics of the networks that they were designed to travel
	over, and it can be necessary for the emulated service to duplicate		over, and it can be necessary for the emulated service to duplicate
	these network characteristics as closely as possible, e.g. in		these network characteristics as closely as possible, e.g. in
	delivering native traffic with the same jitter, bit-rate and timing		delivering native traffic with bit-rate, jitter, wander and delay
	characteristics as it was sent.		characteristics similar to those received at the sending PE.
	In such cases, it is necessary for the receiving PE to play out the		In such cases, it is necessary for the receiving PE to play out the
	native traffic as it was received at the sending PE. This relies on		native traffic as it was received at the sending PE. This relies on
	either timing information sent between the two PEs, or in some case		either timing information sent between the two PEs, or in some case
	timing information received from an external reference.		timing information received from an external reference.
	The Timing Sub-layer must therefore support two timing functions:		The Timing Sub-layer must therefore support two timing functions:
	clock recovery and timed payload delivery. A particular payload type		clock recovery and timed payload delivery. A particular payload type
	may require either or both of these services.		may require either or both of these services.
	5.2.2.1 Clock Recovery		5.2.2.1 Clock Recovery
	Clock recovery is the extraction of output transmission bit timing		Clock recovery is the extraction of output transmission bit timing
	information from the delivered packet stream, and requires a suitable		information from the delivered packet stream, and requires a suitable
	mechanism. A physical wire provides this naturally, but it is a		mechanism. A physical wire carries the timing information natively,
	relatively complex task to extract this from a highly jittered source		but it is a relatively complex task to extract timing from a highly
	such as packet stream. It is therefore desirable that an existing		jittered source such as packet stream. It is therefore desirable
	real-time protocol such as [RFC1889] be used for this purpose, unless		that an existing real-time protocol such as [RFC1889] be used for
	it can be shown that this is unsuitable or unnecessary for a		this purpose, unless it can be shown that this is unsuitable or
	particular payload type.		unnecessary for a particular payload type.
	5.2.2.2 Timed delivery		5.2.2.2 Timed delivery
	Timed delivery is the delivery of non-contiguous PW PDUs to the PW		Timed delivery is the delivery of non-contiguous PW PDUs to the PW
	output interface with a constant phase relative to the input		output interface with a constant phase relative to the input
	interface. The timing of the delivery may be relative to a clock		interface. The timing of the delivery may be relative to a clock
	derived from the packet stream received over the PSN clock recovery,		derived from the packet stream received over the PSN clock recovery,
	or with reference to an external clock.		or with reference to an external clock.
	5.3 Fragmentation		5.3 Fragmentation
	A payload would normally be relayed across the PW as a single unit.		A payload would ideally be relayed across the PW as a single unit.
	However, there will be cases where the combined size of the payload		However, there will be cases where the combined size of the payload
	and its associated PWE3 and PSN headers exceeds the PSN path MTU.		and its associated PWE3 and PSN headers exceeds the PSN path MTU.
	When a packet exceeds the MTU of a given network, fragmentation and		When a packet size exceeds the MTU of a given network, fragmentation
	reassembly may have to be performed in order for the packet to be		and reassembly have to be performed in order for the packet to be
	delivered. Since fragmentation and reassembly generally consume a		delivered. Since fragmentation and reassembly generally consume a
	large amount of network resource as compared to simply switching a		considerable network resources as compared to simply switching a
	packet in its entirety, efforts should be made to reduce or eliminate		packet in its entirety, efforts SHOULD be made to reduce or eliminate
	the need for fragmentation and reassembly as much as possible		the need for fragmentation and reassembly throughout a network to the
	throughout a network. Of particular concern for fragmentation and		extent possible. Of particular concern for fragmentation and
	reassembly are aggregation points where large numbers of pseudowires		reassembly are aggregation points where large numbers of PWs are
	are processed (e.g. at the PE).		processed (e.g. at the PE).
	Ideally, the equipment originating the traffic being sent over the PW		Ideally, the equipment originating the traffic being sent over the PW
	will be configured to have adaptive measures (e.g. [RFC1191],		will be configured to have adaptive measures (e.g. [RFC1191],
	[RFC1981]) in place such that it never sends a packet that must be		[RFC1981]) in place that ensure that packets that need to be
	fragmented. When this fails, the point closest to the sending host		fragmented are not sent. When this fails, the point closest to the
	with fragmentation and reassembly capabilities should attempt to		sending host with fragmentation and reassembly capabilities SHOULD
	reduce the size of packets further into the network. Thus, in the		attempt to reduce the size of packets to satisfy the PSN MTU. Thus,
	reference model for PWE3 [Figure 3] fragmentation should first be		in the reference model for PWE3 [Figure 3] fragmentation SHOULD first
	performed at the CE if at all possible. If and only if the CE cannot		be performed at the CE if at all possible. If and only if the CE
	adhere to an acceptable MTU size for the PW should the PE attempt its		cannot adhere to an acceptable MTU size for the PW should the PE
	own fragmentation method.		attempt its own fragmentation method.
	In cases where MTU management fails to limit the payload to a size		In cases where MTU management fails to limit the payload to a size
	suitable for transmission of the PW, the PE may fall back to either a		suitable for transmission of the PW, the PE MAY fall back to either a
	generic PW fragmentation method, or, if available the fragmentation		generic PW fragmentation method, or, if available the fragmentation
	service of the underlying PSN.		service of the underlying PSN.
	It is acceptable for a PE implementation to not support		It is acceptable for a PE implementation not to support
	fragmentation. A PE that does not support fragmentation will drop		fragmentation. A PE that does not support fragmentation will drop
	packets that exceed the PSN MTU, and the management plane of the		packets that exceed the PSN MTU, and the management plane of the
	encapsulating PE may be notified.		encapsulating PE MAY be notified.
	If the length of a L2/L1 frame, restored from a PW PDU, exceeds the		If the length of a L2/L1 frame, restored from a PW PDU, exceeds the
	MTU of the destination PWES, it must be dropped. In this case, the		MTU of the destination PWES, it MUST be dropped. In this case, the
	management plane of the destination PE may be notified.		management plane of the destination PE MAY be notified.
	5.4 Instantiation of the Protocol Layers		5.4 Instantiation of the Protocol Layers
	This document does not address the detailed mapping of the Protocol		This document does not address the detailed mapping of the Protocol
	Layering model to existing or future IETF standards. The		Layering model to existing or future IETF standards. The
	instantiation of the logical Protocol Layering model is shown in		instantiation of the logical Protocol Layering model is shown in
	Figure 9.		Figure 9.
	5.4.1. PWE3 over an IP PSN		5.4.1. PWE3 over an IP PSN
	The protocol definition of PWE3 over an IP PSN should employ existing		The protocol definition of PWE3 over an IP PSN SHOULD employ existing
	IETF protocols where possible.		IETF protocols where possible.
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| Payload |------------->| Raw payload if possible |		| Payload |------------->| Raw payload if possible |
	/=====================\ +-------------------------+		/=====================\ +-------------------------+
	H Payload Convergence H------------->| As Needed |		H Payload Convergence H------------->| As Needed |
	H---------------------H +-------------------------+		H---------------------H +-------------------------+
	H Timing H----------+-->| RTP |		H Timing H----------+-->| RTP |
	H---------------------H / +-------------+ |		H---------------------H / +-------------+ |
	H Sequencing H----one of | |		H Sequencing H----one of | |
	\=====================/ \ | +-----------+		\=====================/ \ | +-----------+
	| PW Demultiplexer |----------+-->| L2TP, MPLS etc. |		| PW Demultiplexer |----------+-->| L2TP, MPLS etc. |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| PSN Convergence |------------->| Not needed |		| PSN Convergence |------------->| Not needed |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| PSN |------------->| IP |		| PSN |------------->| IP |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| MAC/Data-link |------------->| MAC/Data-link |		| Data-link |------------->| Data-link |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| Physical |------------->| Physical |		| Physical |------------->| Physical |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	Figure 10: PWE3 over an IP PSN		Figure 10: PWE3 over an IP PSN
	Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a		Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a
	rule, the payload should be carried as received from the NSP, with		rule, the payload SHOULD be carried as received from the NSP, with
	the Payload Convergence Layer provided when needed. (It is accepted		the Payload Convergence Layer provided when needed. (It is accepted
	that there may sometimes be good reason not to follow this rule, but		that there MAY sometimes be good reason not to follow this rule, but
	the exceptional circumstances need to be documented in the		the exceptional circumstances need to be documented in the
	Encapsulation Layer definition for that payload type).		Encapsulation Layer definition for that payload type).
	Where appropriate, timing is provided by RTP [RFC1889], which when		Where appropriate, timing is provided by RTP [RFC1889], which when
	used also provides a sequencing service. PW Demultiplexing may be		used also provides a sequencing service. PW Demultiplexing may be
	provided by a number of existing IETF tunnel protocols. Some of		provided by a number of existing IETF tunnel protocols. Some of
	these tunnel protocols provide an optional sequencing service.		these tunnel protocols provide an optional sequencing service.
	(Sequencing is provided either by RTP, or by the PW Demultiplexer		(Sequencing is provided either by RTP, or by the PW Demultiplexer
	Layer, but not both). A PSN Convergence Layer is not needed, because		Layer, but not both). A PSN Convergence Layer is not needed, because
	all the tunnel protocols shown above are designed to operate directly		all the tunnel protocols shown above are designed to operate directly
	skipping to change at page 29, line 26 ¶		skipping to change at page 29, line 26 ¶
	H Timing H------------------------+		H Timing H------------------------+
	H---------------------H | |		H---------------------H | |
	H Sequencing H-----| |		H Sequencing H-----| |
	\=====================/ | |		\=====================/ | |
	| PW Demultiplexer |---+ | v		| PW Demultiplexer |---+ | v
	+---------------------+ | | +--------------------------------+		+---------------------+ | | +--------------------------------+
	| PSN Convergence |-----| . .		| PSN Convergence |-----| . .
	+---------------------+ | | . RTP .		+---------------------+ | | . RTP .
	| PSN |-+ | | | |		| PSN |-+ | | | |
	+---------------------+ | | | +--------------------------------+		+---------------------+ | | | +--------------------------------+
	| MAC/Data-link | | | +->| Flags, Frag, Len, Seq #, etc |		| Data-link | | | +->| Flags, Frag, Len, Seq #, etc |
	+---------------------+ | | +--------------------------------+		+---------------------+ | | +--------------------------------+
	| Physical | | +--->| Inner Label |		| Physical | | +--->| PW Label |
	+---------------------+ | +--------------------------------+		+---------------------+ | +--------------------------------+
	+----->| Outer Label or MPLS-in-IP encap|		+----->| Outer Label or MPLS-in-IP encap|
	+--------------------------------+		+--------------------------------+
	Figure 11: PWE3 over an MPLS PSN using a control word		Figure 11: PWE3 over an MPLS PSN using a control word
	Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An		Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An
	inner MPLS label is used to provide the PW demultiplexing function.		inner MPLS label is used to provide the PW demultiplexing function.
	A control word is used to carry most of the information needed by the		A control word is used to carry most of the information needed by the
	PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact		PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
	skipping to change at page 30, line 7 ¶		skipping to change at page 30, line 7 ¶
	in MPLS to correctly pass over an Ethernet data-link, a length		in MPLS to correctly pass over an Ethernet data-link, a length
	correction field is needed in the control word. As with an IP PSN,		correction field is needed in the control word. As with an IP PSN,
	where appropriate, timing is provided by RTP [RFC1889].		where appropriate, timing is provided by RTP [RFC1889].
	In some networks it may be necessary to carry PWE3 over MPLS over IP.		In some networks it may be necessary to carry PWE3 over MPLS over IP.
	In these circumstances, the PW is encapsulated for carriage over MPLS		In these circumstances, the PW is encapsulated for carriage over MPLS
	as described in this section, and then a method of carrying MPLS over		as described in this section, and then a method of carrying MPLS over
	an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the		an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the
	resultant PW-PDU.		resultant PW-PDU.
			5.4.3. PW over MPLS Generic Control Word
			The PW set-up protocol determines whether a particular PW uses a
			control word. When a control word is used, it MUST have the
			following form:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PID | Flags |FRG| Length | Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 12 - MPLS Generic Control Word
			The meaning of the fields of the MPLS Generic Control Word (Figure
			12) is as follows:
			PID (bits 0 to 3):
			In an environment in which all PWs use the control word,
			the payload type of an MPLS packet can be determined by
			inspecting the first four bits of the longword, which
			follows the bottom of the label stack. A value of 0
			indicates "pseudowire", 4 indicates IPv4, 6 indicates IPv6.
			Flags (bits 4 to 7):
			These bits are available for per payload signaling. Their
			definition is encapsulation specific.
			FRG (bits 8 and 9):
			These bits are used when fragmenting a PW payload. Their use
			is defined in [FRAG].
			Length (bits 10 to 15):
			The length field is used to determine the size of a PW
			payload that might have been padded to the minimum Ethernet
			MAC frame size during its transit across the PSN. If the
			MPLS payload (defined as the CW + the PW payload + any
			additional PW headers is less than 46 bytes, the length MUST
			be set to the length of the MPLS payload. If the MPLS
			payload is between 46 bytes and 63 bytes the implementation
			MAY either set to the length to the length of the MPLS
			payload, or it MAY set it to 0. If the length of the MPLS
			payload is greater than 63 bytes the length MUST be set to 0.
			Sequence number (Bit 16 to 31):
			If the sequence number is not used, it is set to zero by
			the sender and ignored by the receiver. Otherwise it
			specifies the sequence number of a packet. A circular list
			of sequence numbers is used. A sequence number takes a value
			from 1 to 65535 (2**16-1).
	6. PW Demultiplexer Layer and PSN Requirements		6. PW Demultiplexer Layer and PSN Requirements
	PWE3 places three service requirements on the protocol layers used to		PWE3 places three service requirements on the protocol layers used to
	carry it across the PSN:		carry it across the PSN:
	o Multiplexing		o Multiplexing
	o Fragmentation		o Fragmentation
	o Length and Delivery		o Length and Delivery
	6.1 Multiplexing		6.1 Multiplexing
	The purpose of the PW Demultiplexer Layer is to allow multiple PWs to		The purpose of the PW Demultiplexer Layer is to allow multiple PWs to
	be carried in a single tunnel. This minimizes complexity and		be carried in a single tunnel. This minimizes complexity and
	conserves resources.		conserves resources.
	Some types of native service are capable of grouping multiple		Some types of native service are capable of grouping multiple
	circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple		circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple
	Ethernet VLANs on a physical media, or multiple DS0 services within a		Ethernet VLANs on a physical media, or multiple DS0 services within a
	T1 or E1. A PW may interconnect two end-trunks. That trunk would		T1 or E1. A PW MAY interconnect two end-trunks. That trunk would
	have a single multiplexing value.		have a single multiplexing identifier.
	6.2 Fragmentation		6.2 Fragmentation
	If the PSN provides a fragmentation and reassembly service of		If the PSN provides a fragmentation and reassembly service of
	adequate performance, it MAY be used to obtain an effective MTU that		adequate performance, it MAY be used to obtain an effective MTU that
	is large enough to transport the PW PDUs. However, if the PSN does		is large enough to transport the PW PDUs. See Section 5.3 for a full
	not offer an adequate service, and fragmentation at the PE cannot be		discussion of the PW fragmentation issues.
	avoided by any other means, then a PW-specific fragmentation method
	may be utilized here. See Section 5.3 for more details.
	6.3 Length and Delivery		6.3 Length and Delivery
	PDU delivery to the egress PE is the function of the PSN Layer.		PDU delivery to the egress PE is the function of the PSN Layer.
	If the underlying PSN does not provide all the information necessary		If the underlying PSN does not provide all the information necessary
	to determine the length of a PW-PDU, the Encapsulation Layer will		to determine the length of a PW-PDU, the Encapsulation Layer MUST
	provide it.		provide it.
	6.4 PW-PDU Validation		6.4 PW-PDU Validation
	It is a common practice to use a CRC or similar mechanism to assure		It is a common practice to use an error detection mechanism such as a
	end-to-end integrity of frames. The PW service-specific mechanisms		CRC or similar mechanism to assure end-to-end integrity of frames.
	MUST define whether the packet's checksum shall be preserved across
	the PW or be removed from PE bound PDUs and then be re-calculated for		The PW service-specific mechanisms MUST define whether the packet's
	insertion in CE bound data.		checksum shall be preserved across the PW, or be removed from PE-
			bound PDUs and then be re-calculated for insertion in CE-bound data.
	The former approach saves work, while the latter saves bandwidth. For		The former approach saves work, while the latter saves bandwidth. For
	a given implementation the choice may be dictated by hardware		a given implementation the choice may be dictated by hardware
	restrictions.		restrictions, which may not allow the preservation of the checksum.
	For protocols such as ATM and FR, the scope of the checksum is		For protocols such as ATM and FR, the scope of the checksum is
	restricted to a single link. This is because the circuit identifiers		restricted to a single link. This is because the circuit identifiers
	(e.g. FR DLCI or ATM VPI/VCI) have only local significance and are		(e.g. FR DLCI or ATM VPI/VCI) have only local significance and are
	changed on each hop or span. If the circuit identifier (and thus		changed on each hop or span. If the circuit identifier (and thus
	checksum) were going to change as a part of the PW emulation, it		checksum) were going to change as a part of the PW emulation, it
	would be more efficient to strip and re-calculate the checksum.		would be more efficient to strip and re-calculate the checksum.
	The service specific document for each protocol must describe the		The service specific document for each protocol MUST describe the
	validation scheme to be used.		validation scheme to be used.
	6.5 Congestion Considerations		6.5 Congestion Considerations
	The PSN carrying the PW may be subject to congestion. The congestion		The PSN carrying the PW may be subject to congestion. The congestion
	characteristics will vary with the PSN type, the network architecture		characteristics will vary with the PSN type, the network architecture
	and configuration, and the loading of the PSN.		and configuration, and the loading of the PSN.
	Each service specific document will have to specify whether it needs		Where the traffic carried over the PW is known to be TCP friendly
	an appropriate mechanism for operating in the presence of this		(by, for example, packet inspection), packet discard in the PSN will
	congestion, including methods of mapping between its native		trigger the necessary reduction in offered load, and no additional
	congestion reporting and avoidance mechanisms, and those provided by		congestion avoidance action is necessary.
	the PW.
			If the PW is operating over a PSN that provides enhanced delivery,
			the PEs SHOULD monitor packet loss to ensure that the service that
			was requested is actually being delivered. If it is not, then the PE
			SHOULD assume that the PSN is providing a best-effort service, and
			SHOULD use the best-effort service congestion avoidance measures
			described below.
			If best-effort service is being used and the trafic is not known to
			be TCP friendly, the PEs SHOULD monitor packet loss to ensure that
			the packet loss rate is within acceptable parameters. Packet loss is
			considered acceptable if a TCP flow across the same network path and
			experiencing the same network conditions would achieve an average
			throughput, measured on a reasonable timescale, that is not less than
			the PW flow is achieving. This condition can be satisfied by
			implementing a rate-limiting measure in the NSP, or by shutting down
			one or more PWs. The choice of which approach to use depends upon
			the type of traffic being carried. Where congestion is avoided by
			shutting down a PW, a suitable mechanism MUST be provided to prevent
			it immediately returning to service, causing a series of congestion
			pulses.
			The comparison to TCP cannot be specified exactly, but is intended as
			an "order-of-magnitude" comparison in timescale and throughput. The
			timescale on which TCP throughput is measured is the round-trip time
			of the connection. In essence, this requirement states that it is not
			acceptable to deploy an application (using PWE3 or any other
			transport protocol) on the best-effort Internet which consumes
			bandwidth arbitrarily and does not compete fairly with TCP within an
			order of magnitude. One method of determining an acceptable PW
			bandwidth is described in [TFRC].
	7. Control Plane		7. Control Plane
	This section describes PWE3 control plane services.		This section describes PWE3 control plane services.
	7.1 Set-up or Teardown of Pseudo-Wires		7.1 Set-up or Teardown of Pseudo-Wires
	A PW must be set up before an emulated service can be established,		A PW MUST be set up before an emulated service can be established,
	and must be torn down when an emulated service is no longer needed.		and MUST be torn down when an emulated service is no longer needed.
	Set up or teardown of a PW can be triggered by a CLI command, from		Set up or teardown of a PW can be triggered by an operator command,
	the management plane of a PE, by signaling (i.e., set-up or teardown)		from the management plane of a PE, by signaling (i.e., set-up or
	of a PWES, e.g., an ATM SVC, or by an auto-discovery mechanism.		teardown) of a PWES, e.g., an ATM SVC, or by an auto-discovery
			mechanism.
	During the set-up process, the PEs need to exchange some information		During the set-up process, the PEs need to exchange some information
	(e.g. learn each others' capabilities). The tunnel signalling		(e.g. learn each other's capabilities). The tunnel signaling
	protocol may be extended to provide mechanisms to enable the PEs to		protocol MAY be extended to provide mechanisms to enable the PEs to
	exchange all necessary information on behalf of the PW.		exchange all necessary information on behalf of the PW.
	Manual configuration of PWs can be considered a special kind of		Manual configuration of PWs can be considered a special kind of
	signaling, and is allowed.		signaling, and is allowed.
	7.2 Status Monitoring		7.2 Status Monitoring
	Some native services have mechanisms for status monitoring. For		Some native services have mechanisms for status monitoring. For
	example, ATM supports OAM for this purpose. For such services, the		example, ATM supports OAM for this purpose. For such services, the
	corresponding emulated services must specify how to perform status		corresponding emulated services MUST specify how to perform status
	monitoring.		monitoring.
	7.3 Notification of Pseudo-wire Status Changes		7.3 Notification of Pseudo-wire Status Changes
	7.3.1. Pseudo-wire Up/Down Notification		7.3.1. Pseudo-wire Up/Down Notification
	If a native service requires bi-directional connectivity, the		If a native service REQUIRES bi-directional connectivity, the
	corresponding emulated service can only be signaled up when the		corresponding emulated service can only be signaled as being up when
	associated PWs, and PSN tunnels if any, are functional in both		the associated PWs, and PSN tunnels if any, are functional in both
	directions.		directions.
	Because the two CEs of an emulated service are not adjacent, a		Because the two CEs of an emulated service are not adjacent, a
	failure may occur at a place such that one or both physical links		failure may occur at a place such that one or both physical links
	between the CEs and PEs remain up. For example, in Figure 2, if the		between the CEs and PEs remain up. For example, in Figure 2, if the
	physical link between CE1 and PE1 fails, the physical link between		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		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		notified about the remote failure, it will continue to send traffic
	over the emulated service to CE1. Such traffic will be discarded at		over the emulated service to CE1. Such traffic will be discarded at
	PE1. Some native services have failure notification so that when the		PE1. Some native services have failure notification so that when the
	services fail, both CEs will be notified. For such native services,		services fail, both CEs will be notified. For such native services,
	the corresponding PWE3 service must provide a failure notification		the corresponding PWE3 service MUST provide a failure notification
	mechanism.		mechanism.
	Similarly, if a native service has notification mechanisms so that		Similarly, if a native service has notification mechanisms so that
	when a network failure is fixed, all the affected services will		when a network failure is fixed, all the affected services will
	change status from "Down" to "Up", the corresponding emulated service		change status from "Down" to "Up", the corresponding emulated service
	must provide a similar mechanism for doing so.		MUST provide a similar mechanism for doing so.
	These mechanisms may already be built into the tunneling protocol.		These mechanisms may already be built into the tunneling protocol.
	For example, the L2TP control protocol [RFC2661] [L2TPv3] has this		For example, the L2TP control protocol [RFC2661] [L2TPv3] has this
	capability and LDP has the ability to withdraw the corresponding MPLS		capability and LDP has the ability to withdraw the corresponding MPLS
	label.		label.
	7.3.2. Misconnection and Payload Type Mismatch		7.3.2. Misconnection and Payload Type Mismatch
	With PWE3, misconnection and payload type mismatch can occur. If a		With PWE3, misconnection and payload type mismatch can occur. If a
	misconnection occurs it can breach the integrity of the system. If a		misconnection occurs it can breach the integrity of the system. If a
	skipping to change at page 33, line 30 ¶		skipping to change at page 35, line 11 ¶
	A PW can incur packet loss, corruption, and out-of-order delivery on		A PW can incur packet loss, corruption, and out-of-order delivery on
	the PSN path between the PEs. This can impact the working condition		the PSN path between the PEs. This can impact the working condition
	of an emulated service. For some payload types, packet loss,		of an emulated service. For some payload types, packet loss,
	corruption, and out-of-order delivery can be mapped to either a bit		corruption, and out-of-order delivery can be mapped to either a bit
	error burst, or loss of carrier on the PW. If a native service has		error burst, or loss of carrier on the PW. If a native service has
	some mechanism to deal with bit error, the corresponding PWE3 service		some mechanism to deal with bit error, the corresponding PWE3 service
	should provide a similar mechanism.		should provide a similar mechanism.
	7.3.4. Other Status Notification		7.3.4. Other Status Notification
	A PWE3 approach may provide a mechanism for other status		A PWE3 approach MAY provide a mechanism for other status
	notification, if any.		notification, if any are needed.
	7.3.5. Collective Status Notification		7.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 incident. For example, when the physical link (or		a single network incident. For example, when the physical link (or
	sub-network) between a CE and a PE fails, all the emulated services		sub-network) between a CE and a PE fails, all the emulated services
	that go through that link (or sub-network) will fail. It is likely		that go through that link (or sub-network) will fail. It is likely
	that there exists a group of emulated services that all terminate at		that there exists a group of emulated services that all terminate at
	a remote CE. There may also be multiple such CEs affected by the		a remote CE. There may also be multiple such CEs affected by the
	failure. Therefore, it is desirable that a single notification		failure. Therefore, it is desirable that a single notification
	message be used to notify failure of the whole group of emulated		message be used to notify failure of the whole group of emulated
	services.		services.
	A PWE3 approach may provide some mechanism for notifying status		A PWE3 approach MAY provide some mechanism for notifying status
	changes of a group of emulated circuits. One possible method is to		changes of a group of emulated circuits. One possible method is to
	associate each emulated service with a group ID when the PW for that		associate each emulated service with a group ID when the PW for that
	emulated service is set up. Multiple emulated services can then be		emulated service is set up. Multiple emulated services can then be
	grouped by associating them with the same group ID. In status		grouped by associating them with the same group ID. In status
	notification, that group ID can be used to refer all the emulated		notification, that group ID can be used to refer all the emulated
	services in that group. The group ID mechanism should be a mechanism		services in that group. The group ID mechanism should be a mechanism
	provided by the underlying tunnel signaling protocol.		provided by the underlying tunnel signaling protocol.
	7.4 Keep-alive		7.4 Keep-alive
	If a native service has a keep-alive mechanism, the corresponding		If a native service has a keep-alive mechanism, the corresponding
	emulated service needs to use a mechanism to propagate this across		emulated service MUST provide a mechanism to propagate this across
	the PW. An approach following the principle of minimum intervention		the PW. An approach following the principle of minimum intervention
	would be to transparently transport keep-alive messages over the PW.		would be to transparently transport keep-alive messages over the PW.
	However, to accurately reproduce the semantics of the native		However, to accurately reproduce the semantics of the native
	mechanism, some PWs may require an alternative approach, such as		mechanism, some PWs MAY REQUIRE an alternative approach, such as
	piggy-backing on the PW signaling mechanism.		piggy-backing on the PW signaling mechanism.
	7.5 Handling Control Messages of the Native Services		7.5 Handling Control Messages of the Native Services
	Some native services use control messages for maintaining the		Some native services use control messages for circuit maintenance.
	circuits. These control messages may be in-band, e.g. Ethernet flow		These control messages MAY be in-band, e.g. Ethernet flow control,
	control or ATM performance management, or out-of-band, e.g. the		ATM performance management, or TDM tone signaling, or they MAY be
	signaling VC of an ATM VP.		out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS
			signaling.
	From the principle of minimum intervention, it is desirable that the		From the principle of minimum intervention, it is desirable that the
	PEs participate as little as possible in the signaling and		PEs participate as little as possible in the signaling and
	maintenance of the native services. This principle should not,		maintenance of the native services. This principle SHOULD NOT,
	however, override the need to satisfactorily emulate the native		however, override the need to satisfactorily emulate the native
	service.		service.
	If control messages are passed through, it may be desirable to send		If control messages are passed through, it may be desirable to send
	them using either a higher priority or a reliable channel provided by		them using either a higher priority or a reliable channel provided by
	the PW Demultiplexer layer. See PWE3 Channel Types.		the PW Demultiplexer layer. See PWE3 Channel Types.
	8. Management and Monitoring		8. Management and Monitoring
	This section describes the management and monitoring architecture for		This section describes the management and monitoring architecture for
	PWE3.		PWE3.
	8.1 Statistics		8.1 Status and Statistics
	The PE can tabulate statistics that help monitor the state of the		The PE should report the status of the interface and tabulate
	network, and to help with measurement of service level agreements		statistics that help monitor the state of the network, and to help
	(SLAs). Typical counters include:		with measurement of service level agreements (SLAs). Typical counters
			include:
	o Counts of PW-PDUs sent and received, with and without errors.		o Counts of PW-PDUs sent and received, with and without errors.
	o Counts of sequenced PW-PDUs lost.		o Counts of sequenced PW-PDUs lost.
	o Counts of service PDUs sent and received over the PSN, with		o Counts of service PDUs sent and received over the PSN, with
	and without errors (non-TDM).		and without errors (non-TDM).
	o Service-specific interface counts.		o Service-specific interface counts.
			o One way delay and delay variation.
	These counters would be contained in a PW-specific MIB, and they		These counters would be contained in a PW-specific MIB, and they
	should not replicate existing MIB counters.		should not replicate existing MIB counters.
	8.2 PW SNMP MIB Architecture		8.2 PW SNMP MIB Architecture
	This section describes the general architecture for SNMP MIBs used to		This section describes the general architecture for SNMP MIBs used to
	manage PW services and the underlying PSN. The intent here is to		manage PW services and the underlying PSN. The intent here is to
	provide a clear picture of how all of the pertinent MIBs fit together		provide a clear picture of how all of the pertinent MIBs fit together
	to form a cohesive management framework for deploying PWE3 services.		to form a cohesive management framework for deploying PWE3 services.
	8.2.1. MIB Layering		8.2.1. MIB Layering
	The SNMP MIBs created for PWE3 should fit the architecture shown in		The SNMP MIBs created for PWE3 should fit the architecture shown in
	Figure 12.		Figure 13.
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	Service | CEM | | Ethernet | | ATM |		Service | CEM | | Ethernet | | ATM |
	Layer |Service MIB| |Service MIB| ... |Service MIB|		Layer |Service MIB| |Service MIB| ... |Service MIB|
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	\ | /		\ | /
	\ | /		\ | /
	- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -		- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
	\ | /		\ | /
	+-------------------------------------------+		+-------------------------------------------+
	skipping to change at page 35, line 45 ¶		skipping to change at page 37, line 30 ¶
	+-----------+ +-----------+		+-----------+ +-----------+
	PSN VC |L2TP VC MIB| |MPLS VC MIB|		PSN VC |L2TP VC MIB| |MPLS VC MIB|
	Layer +-----------+ +-----------+		Layer +-----------+ +-----------+
	| |		| |
	- - - - - - - - - | - - - - - - - - - - - - - - - | - - -		- - - - - - - - - | - - - - - - - - - - - - - - - | - - -
	| |		| |
	+-----------+ +-----------+		+-----------+ +-----------+
	PSN |L2TP MIB(s)| |MPLS MIB(s)|		PSN |L2TP MIB(s)| |MPLS MIB(s)|
	Layer +-----------+ +-----------+		Layer +-----------+ +-----------+
	Figure 12: Relationship of SNMP MIBs		Figure 13: Relationship of SNMP MIBs
	Figure 13 shows an example for a TDM PW carried over MPLS.		Figure 14 shows an example for a SONET PW carried over MPLS.
	+-----------------+		+-----------------+
	| SONET MIB | RFC2558		| SONET MIB | RFC2558
	+-----------------+		+-----------------+
	|		|
	+-----------------+		+-----------------+
	Service |SONET Service MIB| pw-cem-mib		Service |SONET Service MIB| pw-cem-mib
	Layer +-----------------+		Layer +-----------------+
	- - - - - - - - - - | - - - - - - - - - - - - - - -		- - - - - - - - - - | - - - - - - - - - - - - - - -
	+-----------------+		+-----------------+
	skipping to change at page 36, line 27 ¶		skipping to change at page 38, line 27 ¶
	Layer +-----------------+ pw-mib		Layer +-----------------+ pw-mib
	- - - - - - - - - - | - - - - - - - - - - - - - - -		- - - - - - - - - - | - - - - - - - - - - - - - - -
	+-----------------+		+-----------------+
	PSN VC | MPLS VC MIBS | pw-mpls-mib		PSN VC | MPLS VC MIBS | pw-mpls-mib
	Layer +-----------------+		Layer +-----------------+
	- - - - - - - - - - | - - - - - - - - - - - - - - -		- - - - - - - - - - | - - - - - - - - - - - - - - -
	+-----------------+		+-----------------+
	PSN | MPLS MIBs | mpls-te-mib		PSN | MPLS MIBs | mpls-te-mib
	Layer +-----------------+ mpls-lsr-mib		Layer +-----------------+ mpls-lsr-mib
	Figure 13: Service-specific Example for MIBs		Figure 14: Service-specific Example for MIBs
	Note that there is a separate MIB for each emulated service as well		Note that there is a separate MIB for each emulated service as well
	as one for each underlying PSN. These MIBs may be used in various		as one for each underlying PSN. These MIBs MAY be used in various
	combinations as needed.		combinations as needed.
	8.2.2. Service Layer MIBs		8.2.2. Service Layer MIBs
	The first layer is referred to as the Service Layer. It contains		The first layer is referred to as the Service Layer. It contains
	MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame		MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame
	Relay. This layer contains those corresponding MIBs used to mate or		Relay. This layer contains those corresponding MIBs used to mate or
	adapt those emulated services to the underlying services. This		adapt those emulated services to the underlying services. This
	working group should not produce any MIBs for managing the general		working group should not produce any MIBs for managing the general
	service; rather, it should produce just those MIBs that are used to		service; rather, it should produce just those MIBs that are used to
	skipping to change at page 37, line 16 ¶		skipping to change at page 39, line 16 ¶
	The second layer is referred to as the Generic PW Layer. This layer		The second layer is referred to as the Generic PW Layer. This layer
	is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB		is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB
	[PWMIB]. These MIBs are responsible for providing general PWE3		[PWMIB]. These MIBs are responsible for providing general PWE3
	counters and service models used for monitoring and configuration of		counters and service models used for monitoring and configuration of
	PWE3 services over any supported PSN service. That is, this MIB		PWE3 services over any supported PSN service. That is, this MIB
	provides a general model of PWE3 abstraction for management purposes.		provides a general model of PWE3 abstraction for management purposes.
	This MIB is used to interconnect the Service Layer MIBs to the PSN VC		This MIB is used to interconnect the Service Layer MIBs to the PSN VC
	Layer MIBs. The latter will be described in the next section. This		Layer MIBs. The latter will be described in the next section. This
	layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains		layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains
	common SMI textual conventions [RFC1902] that may be used by any PW		common SMI textual conventions [RFC1902] that MAY be used by any PW
	MIB.		MIB.
	8.2.4. PSN VC Layer MIBs		8.2.4. PSN VC Layer MIBs
	The third layer in the PWE3 management architecture is referred to as		The third layer in the PWE3 management architecture is referred to as
	the PSN VC layer. This layer is comprised of MIBs that are		the PSN VC layer. This layer is comprised of MIBs that are
	specifically designed to interface general PWE3 services (VCs) onto		specifically designed to interface general PWE3 services (VCs) onto
	those underlying PSN services. In general this means that the MIB		those underlying PSN services. In general this means that the MIB
	provides a means with which an operator can map the PW service onto		provides a means with which an operator can map the PW service onto
	the native PSN service. For example, in the case of MPLS, it is		the native PSN service. For example, in the case of MPLS, it is
	skipping to change at page 37, line 41 ¶		skipping to change at page 39, line 41 ¶
	working group should produce these MIBs.		working group should produce these MIBs.
	8.2.5. PSN Layer MIBs		8.2.5. PSN Layer MIBs
	The fourth and final layer in the PWE3 management architecture is		The fourth and final layer in the PWE3 management architecture is
	referred to as the PSN layer. This layer is comprised of those MIBs		referred to as the PSN layer. This layer is comprised of those MIBs
	that control the PSN service-specific services. For example, in the		that control the PSN service-specific services. For example, in the
	case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and		case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and
	the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC		the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC
	services onto native MPLS LSPs and/or TE tunnels to carry the		services onto native MPLS LSPs and/or TE tunnels to carry the
	emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] may be		emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] MAY be
	used to reveal the MPLS labels that are distributed over the MPLS PSN		used to reveal the MPLS labels that are distributed over the MPLS PSN
	in order to maintain the PW service. The MIBs in this layer are		in order to maintain the PW service. The MIBs in this layer are
	produced by other working groups that design and specify the native		produced by other working groups that design and specify the native
	PSN services. These MIBs should contain the appropriate mechanisms		PSN services. These MIBs should contain the appropriate mechanisms
	for monitoring and configuring the PSN service such that the emulated		for monitoring and configuring the PSN service such that the emulated
	PWE3 service will function correctly.		PWE3 service will function correctly.
	8.3 Connection Verification and Traceroute		8.3 Connection Verification and Traceroute
	A connection verification mechanism should be supported by PWs.		A connection verification mechanism should be supported by PWs.
	Connection verification as well as other alarming mechanisms can		Connection verification as well as other alarm mechanisms can alert
	alert the operator that a PW has lost its remote connection. The		the operator that a PW has lost its remote connection. The opaque
	opaque nature of a PW means that it is not possible to specify a		nature of a PW means that it is not possible to specify a generic
	generic connection verification or traceroute mechanism that passes		connection verification or traceroute mechanism that passes this
	this status to the CEs over the PW. If connection verification		status to the CEs over the PW. If connection verification status of
	status of the PW is needed by the CE, it must be mapped to the native		the PW is needed by the CE, it MUST be mapped to the native
	connection status method.		connection status method.
	For troubleshooting purposes, it is sometimes desirable to know the		For troubleshooting purposes, it is sometimes desirable to know the
	exact functional path of a PW between PEs. This is provided by the		exact functional path of a PW between PEs. This is provided by the
	traceroute service of the underlying PSN. The opaque nature of the		traceroute service of the underlying PSN. The opaque nature of the
	PW means that this traceroute information is only available within		PW means that this traceroute information is only available within
	the provider network e.g. at the PEs.		the provider network, e.g., at the PEs.
	9. IANA considerations		9. IANA considerations
	There are no IANA considerations for this document.		The control word PID bits need to be assigned by IANA.
	10. Security Considerations		10. Security Considerations
	PWE3 provides no means of protecting the contents or delivery of the		PWE3 provides no means of protecting the contents or delivery of the
	native data units. PWE3 may, however, leverage security mechanisms		native data units. The use of PWE3 can therefore expose a particular
	provided by the PW Demultiplexer or PSN Layers, such as IPSec		environment to additional security threats. Assumptions that might be
	[RFC2401]. This section addresses the PWE3 vulnerabilities, and the		appropriate when all communicating systems are interconnected via a
	mechanisms available to protect the emulated native services.		point to point or circuit-switched network may no longer hold when
			they are interconnected using an emulated wire carried over some
	The PW Tunnel End-Point, PW Demultiplexing mechanism, and the		types of PSN. It is outside the scope of this specification, to
	payloads of the native service are all vulnerable to attack.		fully analyze and review the risks of PWE3, particularly as these
			risks will depend on the PSN. An example should make the concern
	10.1 PW Tunnel End-Point and PW Demultiplexer Security		clear. A number of IETF standards employ relatively weak security
			mechanisms when communicating nodes are expected to be connected to
	Protection mechanisms must be considered for the PW Tunnel end-point		the same local area network. The Virtual Router Redundancy Protocol
	and PW Demultiplexer mechanism in order to avoid denial-of-service		[RFC2338] is one instance. The relatively weak security mechanisms
	attacks upon the native service, and to prevent spoofing of the		represent a greater vulnerability in an emulated Ethernet connected
	native data units. Exploitation of vulnerabilities from within the		via a PW.
	PSN may be directed to the PW Tunnel end-point so that PW
	Demultiplexer and PSN tunnel services are disrupted. Controlling PSN
	access to the PW Tunnel end-point may protect against this.
	By restricting PW Tunnel end-point access to legitimate remote PE
	sources of traffic, the PE may reject traffic that would interfere
	with the PW Demultiplexing and PSN tunnel services.
	10.2 Validation of PW Encapsulation		Exploitation of vulnerabilities from within the PSN may be directed
			to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel
			services are disrupted. Controlling PSN access to the PW Tunnel
			end-point is one way to protect against this. By restricting PW
			Tunnel end-point access to legitimate remote PE sources of traffic,
			the PE may reject traffic that would interfere with the PW
			Demultiplexing and PSN tunnel services.
	Protection mechanisms must address the spoofing of tunneled PW data.		Protection mechanisms MUST also address the spoofing of tunneled PW
	The validation of traffic addressed to the PW Demultiplexer end-point		data. The validation of traffic addressed to the PW Demultiplexer
	is paramount in ensuring integrity of PW encapsulation. Security		end-point is paramount in ensuring integrity of PW encapsulation.
	protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer		Security protocols such as IPSec [RFC2401] MAY be used by the PW
	Layer in order to maintain the integrity of the PW by authenticating		Demultiplexer Layer in order to maintain the integrity of the PW by
	data between the PW Demultiplexer End-points. IPSec may provide		authenticating data between the PW Demultiplexer End-points. IPSec
	authentication, integrity, non-repudiation, and confidentiality of		MAY provide authentication, integrity, non-repudiation, and
	data transferred between two PEs. It cannot provide the equivalent		confidentiality of data transferred between two PEs. It cannot
	services to the native service.		provide the equivalent services to the native service.
	Based on the type of data being transferred, the PW may indicate to		Based on the type of data being transferred, the PW MAY indicate to
	the PW Demultiplexer Layer that enhanced security services are		the PW Demultiplexer Layer that enhanced security services are
	required. The PW Demultiplexer Layer may define multiple protection		required. The PW Demultiplexer Layer MAY define multiple protection
	profiles based on the requirements of the PW emulated service. CE-		profiles based on the requirements of the PW emulated service. CE-
	to-CE signaling and control events emulated by the PW and some data		to-CE signaling and control events emulated by the PW and some data
	types may require additional protection mechanisms. Alternatively,		types may require additional protection mechanisms. Alternatively,
	the PW Demultiplexer Layer may use peer authentication for every PSN		the PW Demultiplexer Layer may use peer authentication for every PSN
	packet to prevent spoofed native data units from being sent to the		packet to prevent spoofed native data units from being sent to the
	destination CE.		destination CE.
	Acknowledgments		Acknowledgments
	We thank: Sasha Vainshtein for his work on Native Service Processing		We thank: Sasha Vainshtein for his work on Native Service Processing
	skipping to change at page 39, line 46 ¶		skipping to change at page 41, line 44 ¶
	We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar		We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar
	Jayakumar, Ghassem Koleyni, Eric Rosen, John Rutemiller, Scott		Jayakumar, Ghassem Koleyni, Eric Rosen, John Rutemiller, Scott
	Wainner and David Zelig for their comments and contributions.		Wainner and David Zelig for their comments and contributions.
	References		References
	Internet-drafts are works in progress available from		Internet-drafts are works in progress available from
	<http://www.ietf.org/internet-drafts/>		<http://www.ietf.org/internet-drafts/>
	[ETSI] EN 300 744 Digital Video Broadcasting (DVB); Framing		[DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing
	structure, channel coding and modulation for digital		structure, channel coding and modulation for digital
	terrestrial television (DVB-T), European		terrestrial television (DVB-T), European
	Telecommunications Standards Institute (ETSI)		Telecommunications Standards Institute (ETSI)
			[FRAG] Malis and Townsley, "PWE3 Fragmentation and
			Reassembly", <draft-ietf-pwe3-fragmentation-00.txt>,
			work in progress, October 2002.
	[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J.,		[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J.,
	"Definitions of Managed Objects for the Multiprotocol		"Definitions of Managed Objects for the Multiprotocol
	Label Switching, Label Distribution Protocol (LDP)",		Label Switching, Label Distribution Protocol (LDP)",
	<draft-ietf-mpls-ldp-mib-08.txt>, work in progress,		<draft-ietf-mpls-ldp-mib-09.txt>, work in progress,
	August 2001.		October 2002.
	[LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management		[LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management
	Information Base Using SMIv2",		Information Base Using SMIv2",
	(draft-ietf-mpls-lsr-mib-08.txt, work in progress,		<draft-ietf-mpls-lsr-mib-09.txt>, work in progress,
	January 2002.		October 2002.
	[L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau,		[L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau,
	et. al. (work in progress).		et. al. <draft-ietf-l2tpext-l2tp-base-05.txt>, work
			in progress, January 2003.
	[PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol,		[PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol,
	J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-01.txt>,		J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-02.txt>,
	work in progress.		work in progress, June 2002.
	[PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information		[PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information
	Base Using SMIv2", (draft-ietf-pwe3-pw-mib-00.txt),		Base Using SMIv2", <draft-ietf-pwe3-pw-mib-00.txt>,
	work in progress, June 2002.		work in progress, June 2002.
	[PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and		[PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and
	OBJECT-IDENTITIES for Pseudo-Wires Management"		OBJECT-IDENTITIES for Pseudo-Wires Management"
	(draft-ietf-pwe3-pw-tc-mib-00.txt), work in progress,		<draft-ietf-pwe3-pw-tc-mib-00.txt>, work in progress,
	June 2002.		June 2002.
	[PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service		[PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service
	Over MPLS (CEM) Management Information Base Using		Over MPLS (CEM) Management Information Base Using
	SMIv2", (draft-ietf-pwe3-cep-mib-00.txt), work in		SMIv2", <draft-ietf-pwe3-cep-mib-01.txt>, work in
	progress, August 2001.		progress, October 2002.
	[RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering.		[RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering.
	[RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time		[RFC1889] RFC-1889: RTP: A Transport Protocol for Real-Time
	Applications. H. Schulzrinne et. al.		Applications. H. Schulzrinne et. al.
	[RFC1902] RFC-1902: Structure of Management Information for		[RFC1902] RFC-1902: Structure of Management Information for
	Version 2 of the Simple Network Management Protocol		Version 2 of the Simple Network Management Protocol
	(SNMPv2), Case et al, January 1996.		(SNMPv2), Case et al, January 1996.
	[RFC1958] RFC-1958: Architectural Principles of the Internet,		[RFC1958] RFC-1958: Architectural Principles of the Internet,
	B. Carpenter et al.		B. Carpenter et al.
	[RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann,		[RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann,
	S. Deering, J.Mogul.		S. Deering, J. Mogul.
	[RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based		[RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based
	ATM Networks, G. Armitage.		ATM Networks, G. Armitage.
			[RFC2119] RFC-2119, BCP-14: Key words for use in RFCs to Indicate
			Requirement Levels, S. Bradner.
			[RFC2338] RFC-2338: Virtual Router Redundancy Protocol,
			S. Knight, M. Shand et. al.
	[RFC2401] RFC-2401: Security Architecture for the Internet		[RFC2401] RFC-2401: Security Architecture for the Internet
	Protocol. S. Kent, R. Atkinson.		Protocol. S. Kent, R. Atkinson.
	[RFC2474] RFC-2474: Definition of the Differentiated Services		[RFC2474] RFC-2474: Definition of the Differentiated Services
	Field (DS Field) in the IPv4 and IPv6 Headers,		Field (DS Field) in the IPv4 and IPv6 Headers,
	K. Nichols, et. al.		K. Nichols, et. al.
	[RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP".		[RFC2661] RFC-2661: Layer Two Tunneling Protocol "L2TP".
	W. Townsley, et. al.		W. Townsley, et. al.
	skipping to change at page 41, line 32 ¶		skipping to change at page 43, line 44 ¶
	(Traditional NAT). P Srisuresh et al.		(Traditional NAT). P Srisuresh et al.
	[RFC3031] RFC3031: Multiprotocol Label Switching Architecture,		[RFC3031] RFC3031: Multiprotocol Label Switching Architecture,
	E. Rosen, January 2001.		E. Rosen, January 2001.
	[SONETMIB] K. Tesink, "Definitions of Managed Objects for the		[SONETMIB] K. Tesink, "Definitions of Managed Objects for the
	SONET/SDH Interface Type", RFC2558, March 1999.		SONET/SDH Interface Type", RFC2558, March 1999.
	[TEMIB] Srinivasan et al, "Traffic Engineering Management		[TEMIB] Srinivasan et al, "Traffic Engineering Management
	Information Base Using SMIv2",		Information Base Using SMIv2",
	(draft-ietf-mpls-te-mib-08.txt), work in progress,		<draft-ietf-mpls-te-mib-09.txt>, work in progress,
	January 2002.		November 2002.
			[TFRC] M. Handley et al, "TCP Friendly Rate Control (TFRC):
			Protocol Specification" <draft-ietf-tsvwg-tfrc-05.txt>,
			work in progress, October 2002.
	[VPLS] M. Lasserre, "Virtual Private LAN Services over MPLS",		[VPLS] M. Lasserre, "Virtual Private LAN Services over MPLS",
	draft-lasserre-vkompella-ppvpn-vpls-02.txt, work in		<draft-lasserre-vkompella-ppvpn-vpls-03.txt>, work in
	progress, June 2002.		progress, January 2003.
	[XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation		[XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation
	Edge-to-Edge (PWE3)",		Edge-to-Edge (PWE3)",
	(draft-ietf-pwe3-requirements-03.txt), X Xiao et al.		(draft-ietf-pwe3-requirements-04.txt), X Xiao et al.
	work in progress, December 2002.		work in progress, December 2002.
	Editors' Addresses		Editors' Addresses
	Stewart Bryant		Stewart Bryant
	Cisco Systems,		Cisco Systems,
	4, The Square,		4, The Square,
	Stockley Park,		Stockley Park,
	Uxbridge UB11 1BL,		Uxbridge UB11 1BL,
	United Kingdom. Email: stbryant@cisco.com		United Kingdom. Email: stbryant@cisco.com
	Prayson Pate		Prayson Pate
	Overture Networks, Inc.		Overture Networks, Inc.
	P. O. Box 14864		Airport Boulevard
	RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com		Morrisville, NC, USA 27560 Email: prayson.pate@overturenetworks.com
	Full copyright statement		Full copyright statement
	Copyright (C) The Internet Society (2002).		Copyright (C) The Internet Society (2002).
	All Rights Reserved.		All Rights Reserved.
	This document and translations of it may be copied and		This document and translations of it may be copied and
	furnished to others, and derivative works that comment		furnished to others, and derivative works that comment
	on or otherwise explain it or assist in its implementation		on or otherwise explain it or assist in its implementation
	may be prepared, copied, published and distributed, in		may be prepared, copied, published and distributed, in
End of changes. 155 change blocks.
	320 lines changed or deleted		414 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/