< draft-ietf-pwe3-arch-02.txt		draft-ietf-pwe3-arch-03.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-02.txt>		Document: <draft-ietf-pwe3-arch-03.txt>
	Expires: August 2003 Prayson Pate		Expires: December 2003 Prayson Pate
	Overture Networks, Inc.		Overture Networks, Inc.
	Editors		Editors
	February 2003		June 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 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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
	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
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
			Table of Contents
	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....................................... 11		3.2 Domain of PWE3....................................... 11
	3.3 Payload Types........................................ 11		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 Reference.		4.5 Pre-processing Extension to Protocol Stack 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.............. 31		6. PW Demultiplexer Layer and PSN Requirements.............. 32
	6.1 Multiplexing......................................... 31		6.1 Multiplexing......................................... 32
	6.2 Fragmentation........................................ 31		6.2 Fragmentation........................................ 32
	6.3 Length and Delivery.................................. 31		6.3 Length and Delivery.................................. 32
	6.4 PW-PDU Validation.................................... 31		6.4 PW-PDU Validation.................................... 33
	6.5 Congestion Considerations............................ 32		6.5 Congestion Considerations............................ 33
	7. Control Plane............................................ 33		7. Control Plane............................................ 34
	7.1 Set-up or Teardown of Pseudo-Wires................... 33		7.1 Set-up or Teardown of Pseudo-Wires................... 34
	7.2 Status Monitoring.................................... 33		7.2 Status Monitoring.................................... 34
	7.3 Notification of Pseudo-wire Status Changes........... 34		7.3 Notification of Pseudo-wire Status Changes........... 35
	7.4 Keep-alive........................................... 35		7.4 Keep-alive........................................... 36
	7.5 Handling Control Messages of the Native Services..... 35		7.5 Handling Control Messages of the Native Services..... 36
	8. Management and Monitoring................................. 36		8. Management and Monitoring................................. 37
	8.1 Status and Statistics................................ 36		8.1 Status and Statistics................................ 37
	8.2 PW SNMP MIB Architecture............................. 36		8.2 PW SNMP MIB Architecture............................. 37
	8.3 Connection Verification and Traceroute................ 40		8.3 Connection Verification and Traceroute................ 41
	9. IANA considerations...................................... 40		9. IANA considerations...................................... 41
	10. Security Considerations................................. 40		10. Security Considerations................................. 41
	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.
	skipping to change at page 28, line 13 ¶		skipping to change at page 28, line 13 ¶
	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 |
	+---------------------+ +-------------------------+		+---------------------+ +-------------------------+
	| Data-link |------------->| 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
	skipping to change at page 29, line 13 ¶		skipping to change at page 29, line 13 ¶
	protocol architecture of this section.		protocol architecture of this section.
	5.4.2. PWE3 over an MPLS PSN		5.4.2. PWE3 over an MPLS PSN
	The MPLS ethos places importance on wire efficiency. By using a		The MPLS ethos places importance on wire efficiency. By using a
	control word, some components of the PWE3 protocol layers can be		control word, some components of the PWE3 protocol layers can be
	compressed to increase this efficiency.		compressed to increase this efficiency.
	+---------------------+		+---------------------+
	| Payload |		| Payload |
	/=====================\		/=====================\ +--------------------------------+
	H Payload Convergence H-----+		H Payload Convergence H--+------>| Flags, Frag, Len, Seq #, etc |
	H---------------------H |		H---------------------H | +--------------------------------+
	H Timing H------------------------+		H Timing H--------->| RTP |
	H---------------------H | |		H---------------------H | +--------------------------------+
	H Sequencing H-----| |		H Sequencing H--+ | MPLS Payload Type Ident |
	\=====================/ | |		\=====================/ | +--------------------------------+
	| PW Demultiplexer |---+ | v		| PW Demultiplexer |--------->| PW Label |
	+---------------------+ | | +--------------------------------+		+---------------------+ | +--------------------------------+
	| PSN Convergence |-----| . .		| PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap|
	+---------------------+ | | . RTP .		+---------------------+ | +--------------------------------+
	| PSN |-+ | | | |		| PSN |-----+
	+---------------------+ | | | +--------------------------------+		+---------------------+
	| Data-link | | | +->| Flags, Frag, Len, Seq #, etc |		| Data-link |
	+---------------------+ | | +--------------------------------+		+---------------------+
	| Physical | | +--->| PW Label |		| Physical |
	+---------------------+ | +--------------------------------+		+---------------------+
	+----->| 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
	format. The flags in the control word provide the necessary payload		format. The flags in the control word provide the necessary payload
	convergence. A sequence field provides support for both in-order		convergence. A sequence field provides support for both in-order
	payload delivery and (supported by a fragmentation control method) a		payload delivery and (supported by a fragmentation control method) a
	PSN fragmentation service within the PSN Convergence Layer. Ethernet		PSN fragmentation service within the PSN Convergence Layer. Ethernet
	pads all frames to a minimum size of 64 bytes. The MPLS header does		pads all frames to a minimum size of 64 bytes. The MPLS header does
	not include a length indicator. Therefore to allow PWE3 to be carried		not include a length indicator. Therefore to allow PWE3 to be carried
	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. Where the design of
	where appropriate, timing is provided by RTP [RFC1889].		the control word would alias an IP packet, an MPLS Payload Type
			Identifier should be interposed between the PW label and the control
			word (see 5.4.4). As with an IP PSN, 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		5.4.3. PW over MPLS Generic Control Word
	The PW set-up protocol determines whether a particular PW uses a		To allow accurate packet inspection in an MPLS PSN, and/or to operate
	control word. When a control word is used, it MUST have the		correctly over MPLS PSNs that have deployed equal-cost multiple-path
	following form:		load-balancing (ECMP), a PW packet MUST NOT alias an IP packet. IP
			packets are carried in MPLS label stacks without any protocol
			identifier. Historic values of the IP version number [RFC791]
			[RFC1881] are therefore used to distinguish between IP and non-IP
			MPLS payloads.
			To disambiguate the PW from an IP flow the PW SHOULD employ either
			the generic PW control word shown in Figure 12, or an MPLS payload
			type identifier. Note that an MPLS payload with bits 0..3 = 4 is an
			IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PID | Flags |FRG| Length | Sequence Number |		|0 0 0 0| Specified by PW Encapsulation |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12 - MPLS Generic Control Word		Figure 12: Generic PW Control Word
	The meaning of the fields of the MPLS Generic Control Word (Figure		The PW set-up protocol determines whether a PW uses a control word.
	12) is as follows:		When a control word is used, it SHOULD have the following preferred
			form:
	PID (bits 0 to 3):		0 1 2 3
	In an environment in which all PWs use the control word,		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
	the payload type of an MPLS packet can be determined by		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	inspecting the first four bits of the longword, which		|0 0 0 0| Flags |FRG| Length | Sequence Number |
	follows the bottom of the label stack. A value of 0		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	indicates "pseudowire", 4 indicates IPv4, 6 indicates IPv6.
			Figure 13: MPLS Preferred Control Word
			The meaning of the fields of the MPLS Preferred Control Word (Figure
			13) is as follows:
	Flags (bits 4 to 7):		Flags (bits 4 to 7):
	These bits are available for per payload signaling. Their		These bits are available for per payload signaling. Their
	definition is encapsulation specific.		definition is encapsulation specific.
	FRG (bits 8 and 9):		FRG (bits 8 and 9):
	These bits are used when fragmenting a PW payload. Their use
	is defined in [FRAG].		These bits are used when fragmenting a PW payload. Their use
			is defined in [FRAG]. When the PW is of a type that will
			never need payload fragmentation, these bits may be used as
			general purpose flags.
	Length (bits 10 to 15):		Length (bits 10 to 15):
	The length field is used to determine the size of a PW		The length field is used to determine the size of a PW
	payload that might have been padded to the minimum Ethernet		payload that might have been padded to the minimum Ethernet
	MAC frame size during its transit across the PSN. If the		MAC frame size during its transit across the PSN. If the
	MPLS payload (defined as the CW + the PW payload + any		MPLS payload (defined as the CW + the PW payload + any
	additional PW headers is less than 46 bytes, the length MUST		additional PW headers is less than 46 bytes, the length MUST
	be set to the length of the MPLS payload. If the MPLS		be set to the length of the MPLS payload. If the MPLS
	payload is between 46 bytes and 63 bytes the implementation		payload is between 46 bytes and 63 bytes the implementation
	MAY either set to the length to the length of the MPLS		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, 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.		payload is greater than 63 bytes the length MUST be set to 0.
	Sequence number (Bit 16 to 31):		Sequence number (Bit 16 to 31):
	If the sequence number is not used, it is set to zero by		If the sequence number is not used, it is set to zero by
	the sender and ignored by the receiver. Otherwise it		the sender and ignored by the receiver. Otherwise it
	specifies the sequence number of a packet. A circular list		specifies the sequence number of a packet. A circular list
	of sequence numbers is used. A sequence number takes a value		of sequence numbers is used. A sequence number takes a value
	from 1 to 65535 (2**16-1).		from 1 to 65535 (2**16-1). If the payload is an OAM packet
			the sequence number MAY be used to mark the position in the
			sequence, in which case it has the same value as the last
			data PDU sent. The use of the sequence number is optional
			for OAM payloads.
			5.4.4. MPLS Payload Identifier
			If technical considerations result in a PW control word that may
			alias an IP packet, the control word SHOULD be preceeded by an MPLS
			payload type identifier.
			The MPLS payload type is defined as follows:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|0 0 0 1| reserved | PPP DLL Protocol Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| As defined by PPP DLL protocol definition |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 14: MPLS Payload Type Identifier
			PPP DLL Protocol Number [16:31]:
			These numbers are assigned by IANA.
	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
	skipping to change at page 31, line 33 ¶		skipping to change at page 32, line 28 ¶
	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 identifier.		have a single multiplexing identifier.
			When a MPLS label is used as a PW Demultiplexer setting of the TTL
			value [RFC3032] in the PW label is application specific, however in a
			strict point to point application the TTL SHOULD be set to 2.
	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. See Section 5.3 for a full		is large enough to transport the PW PDUs. See Section 5.3 for a full
	discussion of the PW fragmentation issues.		discussion of the PW fragmentation issues.
	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.
	skipping to change at page 32, line 41 ¶		skipping to change at page 33, line 45 ¶
	trigger the necessary reduction in offered load, and no additional		trigger the necessary reduction in offered load, and no additional
	congestion avoidance action is necessary.		congestion avoidance action is necessary.
	If the PW is operating over a PSN that provides enhanced delivery,		If the PW is operating over a PSN that provides enhanced delivery,
	the PEs SHOULD monitor packet loss to ensure that the service that		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		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 assume that the PSN is providing a best-effort service, and
	SHOULD use the best-effort service congestion avoidance measures		SHOULD use the best-effort service congestion avoidance measures
	described below.		described below.
	If best-effort service is being used and the trafic is not known to		If best-effort service is being used and the traffic is not known to
	be TCP friendly, the PEs SHOULD monitor packet loss to ensure that		be TCP friendly, the PEs SHOULD monitor packet loss to ensure that
	the packet loss rate is within acceptable parameters. Packet loss is		the packet loss rate is within acceptable parameters. Packet loss is
	considered acceptable if a TCP flow across the same network path and		considered acceptable if a TCP flow across the same network path and
	experiencing the same network conditions would achieve an average		experiencing the same network conditions would achieve an average
	throughput, measured on a reasonable timescale, that is not less than		throughput, measured on a reasonable timescale, that is not less than
	the PW flow is achieving. This condition can be satisfied by		the PW flow is achieving. This condition can be satisfied by
	implementing a rate-limiting measure in the NSP, or by shutting down		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		one or more PWs. The choice of which approach to use depends upon
	the type of traffic being carried. Where congestion is avoided by		the type of traffic being carried. Where congestion is avoided by
	shutting down a PW, a suitable mechanism MUST be provided to prevent		shutting down a PW, a suitable mechanism MUST be provided to prevent
	skipping to change at page 36, line 47 ¶		skipping to change at page 37, line 47 ¶
	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 13.		Figure 15.
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	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 37, line 30 ¶		skipping to change at page 38, 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 13: Relationship of SNMP MIBs		Figure 15: Relationship of SNMP MIBs
	Figure 14 shows an example for a SONET PW carried over MPLS.		Figure 16 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 38, line 27 ¶		skipping to change at page 39, 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 14: Service-specific Example for MIBs		Figure 16: 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
	skipping to change at page 40, line 28 ¶		skipping to change at page 41, line 28 ¶
	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
	The control word PID bits need to be assigned by IANA.		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 integrity, confidentiality
	native data units. The use of PWE3 can therefore expose a particular		or delivery of the native data units. The use of PWE3 can therefore
	environment to additional security threats. Assumptions that might be		expose a particular environment to additional security threats.
	appropriate when all communicating systems are interconnected via a		Assumptions that might be appropriate when all communicating systems
	point to point or circuit-switched network may no longer hold when		are interconnected via a point to point or circuit-switched network
	they are interconnected using an emulated wire carried over some		may no longer hold when they are interconnected using an emulated
	types of PSN. It is outside the scope of this specification, to		wire carried over some types of PSN. It is outside the scope of this
	fully analyze and review the risks of PWE3, particularly as these		specification, to fully analyze and review the risks of PWE3,
	risks will depend on the PSN. An example should make the concern		particularly as these risks will depend on the PSN. An example should
	clear. A number of IETF standards employ relatively weak security		make the concern clear. A number of IETF standards employ relatively
	mechanisms when communicating nodes are expected to be connected to		weak security mechanisms when communicating nodes are expected to be
	the same local area network. The Virtual Router Redundancy Protocol		connected to the same local area network. The Virtual Router
	[RFC2338] is one instance. The relatively weak security mechanisms		Redundancy Protocol [RFC2338] is one instance. The relatively weak
	represent a greater vulnerability in an emulated Ethernet connected		security mechanisms represent a greater vulnerability in an emulated
	via a PW.		Ethernet connected via a PW.
	Exploitation of vulnerabilities from within the PSN may be directed		Exploitation of vulnerabilities from within the PSN may be directed
	to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel		to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel
	services are disrupted. Controlling PSN access to the PW Tunnel		services are disrupted. Controlling PSN access to the PW Tunnel
	end-point is one way to protect against this. By restricting PW		end-point is one way to protect against this. By restricting PW
	Tunnel end-point access to legitimate remote PE sources of traffic,		Tunnel end-point access to legitimate remote PE sources of traffic,
	the PE may reject traffic that would interfere with the PW		the PE may reject traffic that would interfere with the PW
	Demultiplexing and PSN tunnel services.		Demultiplexing and PSN tunnel services.
	Protection mechanisms MUST also address the spoofing of tunneled PW		Protection mechanisms MUST also address the spoofing of tunneled PW
	data. The validation of traffic addressed to the PW Demultiplexer		data. The validation of traffic addressed to the PW Demultiplexer
	end-point is paramount in ensuring integrity of PW encapsulation.		end-point is paramount in ensuring integrity of PW encapsulation.
	Security protocols such as IPSec [RFC2401] MAY be used by the PW		Security protocols such as IPSec [RFC2401] MAY be used by the PW
	Demultiplexer Layer in order to maintain the integrity of the PW by		Demultiplexer Layer in order to maintain the integrity of the PW by
	authenticating data between the PW Demultiplexer End-points. IPSec		authenticating data between the PW Demultiplexer End-points.
	MAY provide authentication, integrity, non-repudiation, and
			IPSec MAY provide authentication, integrity, non-repudiation, and
	confidentiality of data transferred between two PEs. It cannot		confidentiality of data transferred between two PEs. It cannot
	provide the equivalent 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
	and advice on bit-stream over PW services. Thomas K. Johnson for his		and advice on bit-stream over PW services. Thomas K. Johnson for his
	work on the background and motivation for PWs.		work on the background and motivation for PWs.
	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, Danny McPherson, Eric Rosen, John
	Wainner and David Zelig for their comments and contributions.		Rutemiller, Scott 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/>
	[DVB] 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		[FRAG] Malis and Townsley, "PWE3 Fragmentation and
	Reassembly", <draft-ietf-pwe3-fragmentation-00.txt>,		Reassembly", <draft-ietf-pwe3-fragmentation-00.txt>,
	work in progress, October 2002.		work in progress, October 2002.
	[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J.,		[LDPMIB] 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-09.txt>, work in progress,		<draft-ietf-mpls-ldp-mib-09.txt>, work in progress,
	October 2002.		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-09.txt>, work in progress,		<draft-ietf-mpls-lsr-mib-09.txt>, work in progress,
	October 2002.		October 2002.
	skipping to change at page 42, line 40 ¶		skipping to change at page 43, line 44 ¶
	[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-01.txt>, work in		SMIv2", <draft-ietf-pwe3-cep-mib-01.txt>, work in
	progress, October 2002.		progress, October 2002.
			[RFC791] RFC-791: DARPA Internet Program, Protocol Specification,
			ISI, September 1981.
	[RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering.		[RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering.
			[RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6),
			S. Deering, et al, December 1995
	[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.
	skipping to change at page 43, line 39 ¶		skipping to change at page 44, line 49 ¶
	[RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE.		[RFC2890] RFC-2890: Key and Sequence Number Extensions to GRE.
	G. Dommety.		G. Dommety.
	[RFC3022] RFC-3022: Traditional IP Network Address Translator		[RFC3022] RFC-3022: Traditional IP Network Address Translator
	(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.
			[RFC3032] RFC3032: MPLS Label Stack Encoding, 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-09.txt>, work in progress,		<draft-ietf-mpls-te-mib-09.txt>, work in progress,
	November 2002.		November 2002.
	[TFRC] M. Handley et al, "TCP Friendly Rate Control (TFRC):		[TFRC] M. Handley et al, "TCP Friendly Rate Control (TFRC):
	Protocol Specification" <draft-ietf-tsvwg-tfrc-05.txt>,		Protocol Specification" <draft-ietf-tsvwg-tfrc-05.txt>,
	skipping to change at page 44, line 22 ¶		skipping to change at page 45, line 35 ¶
	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.
	Airport Boulevard		507 Airport Boulevard
	Morrisville, NC, USA 27560 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
End of changes. 38 change blocks.
	97 lines changed or deleted		156 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/