< draft-martini-l2circuit-trans-mpls-04.txt		draft-martini-l2circuit-trans-mpls-05.txt >
	Network Working Group Luca Martini		Network Working Group Luca Martini
	Internet Draft Nasser El-Aawar		Internet Draft Nasser El-Aawar
	Expiration Date: May 2001 Giles Heron		Expiration Date: August 2001 Giles Heron
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	Daniel Tappan		Daniel Tappan
	Eric C. Rosen		Eric C. Rosen
			Alex Hamilton
			Jayakumar Jayakumar
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Steve Vogelsang		Steve Vogelsang
	John Shirron		John Shirron
			Toby Smith
	Laurel Networks, Inc.		Laurel Networks, Inc.
	Andrew G. Malis		Andrew G. Malis
			Vinai Sirkay
	Vivace Networks, Inc.		Vivace Networks, Inc.
	Dimitri Stratton Vlachos		Dimitri Stratton Vlachos
	Mazu Networks, Inc.		Mazu Networks, Inc.
	November 2000		February 2001
	Transport of Layer 2 Frames Over MPLS		Transport of Layer 2 Frames Over MPLS
	draft-martini-l2circuit-trans-mpls-04.txt		draft-martini-l2circuit-trans-mpls-05.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of 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
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes methods for transporting the Protocol Data		This document describes methods for transporting the Protocol Data
	Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,		Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,
	Ethernet, and providing a SONET circuit emulation service across an		Ethernet, and providing a SONET circuit emulation service across an
	MPLS network.		MPLS network.
	Table of Contents		Table of Contents
	1 Specification of Requirements .......................... 2		1 Specification of Requirements .......................... 2
	2 Introduction ........................................... 2		2 Introduction ........................................... 3
	3 Tunnel Labels and VC Labels ............................ 3		3 Tunnel Labels and VC Labels ............................ 3
	4 Protocol-Specific Issues ............................... 4		4 Protocol-Specific Details .............................. 4
	4.1 Frame Relay ............................................ 4		4.1 Frame Relay ............................................ 5
	4.2 ATM .................................................... 4		4.2 ATM .................................................... 5
	4.2.1 OAM Cell Support ....................................... 4		4.2.1 ATM AAL5 VCC Transport ................................. 5
	4.2.2 ILMI Support ........................................... 5		4.2.2 ATM Transparent Cell Transport ......................... 5
	4.3 HDLC ( Cisco ) ......................................... 5		4.2.3 ATM VCC and VPC Cell Transport ......................... 5
	4.4 PPP .................................................... 5		4.2.4 OAM Cell Support ....................................... 6
	5 LDP .................................................... 6		4.2.5 ILMI Support ........................................... 6
	6 Security Considerations ................................ 9		4.3 Ethernet VLAN .......................................... 7
	7 References ............................................. 9		4.4 Ethernet ............................................... 7
	8 Author Information ..................................... 9		4.5 HDLC ( Cisco ) ......................................... 7
			4.6 PPP .................................................... 7
			4.7 Static MPLS ............................................ 7
			5 LDP .................................................... 8
			5.1 Interface Parameters Field ............................. 9
			6 IANA Considerations .................................... 11
			7 Security Considerations ................................ 11
			8 References ............................................. 11
			9 Author Information ..................................... 12
	1. Specification of Requirements		1. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Introduction		2. Introduction
	In an MPLS network, it is possible to carry the Protocol Data Units		In an MPLS network, it is possible to carry the Protocol Data Units
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 50 ¶
	packet, there must be a label, which becomes visible to R2, that		packet, there must be a label, which becomes visible to R2, that
	tells R2 how to treat the received packet. Call this label the "VC		tells R2 how to treat the received packet. Call this label the "VC
	label".		label".
	So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on		So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on
	its label stack, and then (if R1 is not adjacent to R2) pushes on a		its label stack, and then (if R1 is not adjacent to R2) pushes on a
	tunnel label. The tunnel label gets the MPLS packet from R1 to R2;		tunnel label. The tunnel label gets the MPLS packet from R1 to R2;
	the VC label is not visible until the MPLS packet reaches R2. R2's		the VC label is not visible until the MPLS packet reaches R2. R2's
	disposition of the packet is based on the VC label.		disposition of the packet is based on the VC label.
			Note that the tunnel could be a GRE encapsulated MPLS tunnel between
			R1 and R2. In this case R1 would be adjacent to R2 , and only the VC
			label would be used, and the intervening network need only carry IP
			packets.
	If the payload of the MPLS packet is, for example, an ATM AAL5 PDU,		If the payload of the MPLS packet is, for example, an ATM AAL5 PDU,
	the VC label will generally correspond to a particular ATM VC at R2.		the VC label will generally correspond to a particular ATM VC at R2.
	That is, R2 needs to be able to infer from the VC label the outgoing		That is, R2 needs to be able to infer from the VC label the outgoing
	interface and the VPI/VCI value for the AAL5 PDU. If the payload is a		interface and the VPI/VCI value for the AAL5 PDU. If the payload is a
	Frame Relay PDU, then R2 needs to be able to infer from the VC label		Frame Relay PDU, then R2 needs to be able to infer from the VC label
	the outgoing interface and the DLCI value. If the payload is an		the outgoing interface and the DLCI value. If the payload is an
	ethernet frame, then R2 needs to be able to infer from the VC label		Ethernet frame, then R2 needs to be able to infer from the VC label
	the outgoing interface, and perhaps the VLAN identifier. This process		the outgoing interface, and perhaps the VLAN identifier. This process
	is unidirectional, and will be repeated independently for		is unidirectional, and will be repeated independently for
	bidirectional operation. It is REQUIRED to assign the same VC, and		bidirectional operation. It is REQUIRED to assign the same VC ID for
	Group ID for a given circuit in both directions.		a given circuit in both directions. The transported frame MAY be
			modified when it reaches the egress router. If the header of the
	Note that the VC label must always be at the bottom of the label		transported layer 2 frame is modified, this MUST be done at the
	stack, and the tunnel label, if present, must be immediately above		egress LSR only. Note that the VC label must always be at the bottom
	the VC label. Of course, as the packet is transported across the MPLS		of the label stack, and the tunnel label, if present, must be
	network, additional labels may be pushed on (and then popped off) as		immediately above the VC label. Of course, as the packet is
	needed. Even R1 itself may push on additional labels above the tunnel		transported across the MPLS network, additional labels may be pushed
	label. If R1 and R2 are directly adjacent LSRs, then it may not be		on (and then popped off) as needed. Even R1 itself may push on
	necessary to use a tunnel label at all.		additional labels above the tunnel label. If R1 and R2 are directly
			adjacent LSRs, then it may not be necessary to use a tunnel label at
			all.
	This document does not specify a method for distributing the tunnel		This document does not specify a method for distributing the tunnel
	label or any other labels that may appear above it on the stack. Any		label or any other labels that may appear above the VC label on the
	acceptable method of MPLS label distribution will do.		stack. Any acceptable method of MPLS label distribution will do.
	This document does specify a method for assigning and distributing		This document does specify a method for assigning and distributing
	the VC label. Static label assignment MAY be used, and		the VC label. Static label assignment MAY be used, and
	implementations SHOULD provide support for this. If signaling is		implementations SHOULD provide support for this. If signaling is
	used, the VC label MUST be distributed from R2 to R1 using LDP in the		used, the VC label MUST be distributed from R2 to R1 using LDP in the
	downstream unsolicited mode; this requires that an LDP connection be		downstream unsolicited mode; this requires that an LDP connection be
	created between R1 and R2.		created between R1 and R2. [1]
	Note that this technique allows an unbounded number of layer 2 "VCs"		Note that this technique allows an unbounded number of layer 2 "VCs"
	to be carried together in a single "tunnel". Thus it scales quite		to be carried together in a single "tunnel". Thus it scales quite
	well in the network backbone.		well in the network backbone.
	4. Protocol-Specific Issues		4. Protocol-Specific Details
	4.1. Frame Relay		4.1. Frame Relay
	The MPLS edge LSR MAY provide a Frame Relay LMI to the CE device.		The Frame Relay PDUs are encapsulated according to the procedures
			defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status
	If the MPLS edge LSR detects a service affecting condition as defined		signaling to the Frame Relay network. If the MPLS edge LSR detects a
	in [2] Q.933 Annex A.5 sited in IA FRF1.1, it MUST withdraw the label		service affecting condition as defined in [2] Q.933 Annex A.5 sited
	that corresponds to the frame relay DLCI. The Egress LSR SHOULD		in IA FRF1.1, it MUST withdraw the label that corresponds to the
	generate the corresponding errors and alarms as defined in [2] on the		frame relay DLCI. The Egress LSR SHOULD generate the corresponding
	Frame relay VC.		errors and alarms as defined in [2] on the Frame relay VC.
	4.2. ATM		4.2. ATM
	4.2.1. OAM Cell Support		4.2.1. ATM AAL5 VCC Transport
	OAM cells MAY be transported on the VC LSP. A router that does not		ATM AAL5 CSPS-PDUs are encapsulated according to [7] ATM AAL5 CPCS-
	support transport of ATM cells MUST discard incoming MPLS frames on		PDU mode. At the edge LSRs, R1 and R2, if ATM ILMI signaling is
	an ATM VC LSP that contain a control word with the T bit set. [7] A		supported it SHOULD be connected to VC signaling. This mode allows
	router that supports transport of OAM cells MUST follow the		the transport of ATM AAL5 CSPS-PDUs traveling on a particular ATM PVC
	procedures outlined in [9] section 8 for mode 0 only in addition to		across the mpls network to another ATM PVC.
	the applicable procedures specified in [6].
	A router that does not support transport of OAM cells across an LSP		4.2.2. ATM Transparent Cell Transport
	MAY provide OAM support on ATM PVCs using the following procedures:
	If an F5 end-to-end OAM cell is received from a VC by a LSR with a		This mode is similar to the Ethernet port mode. Every cell that is
	loopback indication value of 1 and the LSR has a label mapping for		received at the ingress ATM port on the ingress LSR, R1, is
	the VC, the LSR MUST decrement the loopback indication value and loop		encapsulated according to [7], ATM cell mode, and sent across the LSP
	back the cell on the VC. Otherwise the loopback cell MUST be		to the egress LSR, R2. This mode allows an ATM port to be connected
	discarded by the LSR.		to only one other ATM port. [7] allows for grouping of multiple cells
			into a single MPLS frame. Grouping of ATM cells is OPTIONAL for
			transmission at the ingress LSR, R1. If the Egress LSR R2 supports
			cell concatenation the ingress LSR, R1, should only concatenate cells
			up to the "Maximum Number of concatenated ATM cells" parameter
			received as part of the FEC element.
	The LSR MAY optionally be configured to periodically generate F5		4.2.3. ATM VCC and VPC Cell Transport
	end-to-end loopback OAM cells on a VC. In this case, the LSR must
	only generate F5 end-to-end loopback cells while a label mapping
	exists for the VC. If the VC label mapping is withdrawn the LSR MUST
	cease generation of F5 end-to-end loopback OAM cells. If the LSR
	fails to receive a response to an F5 end-to-end loopback OAM cell for
	a pre-defined period of time it MUST withdraw the label mapping for
	the VC.
	If an ingress LSR receives an AIS F5 OAM cell, fails to receive a		This mode is similar to the ATM AAL5 VCC transport except that only
	pre-defined number of the End-to-End loop OAM cells, or a physical		cells are transported. Every cell that is received on a pre-defined
			ATM PVC, or ATM PVP, at the ingress ATM port on the ingress LSR, R1,
			is encapsulated according to [7], ATM cell mode, and sent across the
			LSP to the egress LSR R2. Grouping of ATM cells is OPTIONAL for
			transmission at the ingress LSR, R1. If the Egress LSR R2 supports
			cell concatenation the ingress LSR, R1, MUST only concatenate cells
			up to the "Maximum Number of concatenated ATM cells in a frame"
			parameter received as part of the FEC element.
			4.2.4. OAM Cell Support
			OAM cells MAY be transported on the VC LSP. When the LSR is operating
			in AAL5 PDU transport mode if it does not support transport of ATM
			cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP
			that contain a VC label with the T bit set [7]. When operating in
			AAL5 PDU transport mode an LSR that supports transport of OAM cells
			using the T bit defined in [7], or an LSR operating in any of the
			three cell transport modes MUST follow the procedures outlined in [9]
			section 8 for mode 0 only, in addition to the applicable procedures
			specified in [6].
			4.2.4.1. OAM Cell Emulation Mode
			AN LSR that does not support transport of OAM cells across an LSP MAY
			provide OAM support on ATM PVCs using the following procedures:
			If an F5 end-to-end OAM cell is received from a ATM VC by an ingress
			LSR or egress LSR, with a loopback indication value of 1 and the LSR
			has a label mapping for the ATM VC, the LSR MUST decrement the
			loopback indication value and loop back the cell on the ATM VC.
			Otherwise the loopback cell MUST be discarded by the LSR.
			The ingress LSR, R1, may also optionally be configured to
			periodically generate F5 end-to-end loopback OAM cells on a VC. If
			the LSR fails to receive a response to an F5 end-to-end loopback OAM
			cell for a pre-defined period of time it MUST withdraw the label
			mapping for the VC.
			If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive
			a pre-defined number of the End-to-End loop OAM cells, or a physical
	interface goes down, it MUST withdraw the label mappings for all VCs		interface goes down, it MUST withdraw the label mappings for all VCs
	associated with the failure. When a VC label mapping is withdrawn,		associated with the failure. When a VC label mapping is withdrawn,
	the egress LSR SHOULD generate AIS F5 OAM cells on the VC associated		the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC
	with the withdrawn label mapping.		associated with the withdrawn label mapping. In this mode it is very
			useful to apply a unique group ID to each interface. In the case
			where a physical interface goes down, a wild card label withdraw can
			be sent to all LDP neighbors, greatly reducing the signaling response
			time.
	4.2.2. ILMI Support		4.2.5. ILMI Support
	An MPLS edge LSR MAY provide an ATM ILMI to the CE device.		An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If
			an ingress LSR receives an ILMI message indicating that the ATM edge
			switch has deleted a VC, or if the physical interface goes down, it
			MUST withdraw the label mappings for all VCs associated with the
			failure. When a VC label mapping is withdrawn, the egress LSR SHOULD
			notify its client of this failure by deleting the VC using ILMI.
	If an ingress LSR receives an ILMI message indicating that the CE has		4.3. Ethernet VLAN
	deleted a VC, or if the physical interface goes down, it MUST
	withdraw the label mappings for all VCs associated with the failure.
	When a VC label mapping is withdrawn, the egress LSR SHOULD notify
	its client of this failure by deleting the VC using ILMI.
	4.3. HDLC ( Cisco )		The Ethernet frame will be encapsulated according to the procedures
			in [7]. It should be noted that if the VLAN identifier is modified
			by the egress LSR, according to the procedures outlined above, the
			Ethernet spanning tree protocol might fail to work properly.
			4.4. Ethernet
			The Ethernet frame will be encapsulated according to the procedures
			in [7]. If the LSR detects a failure on the Ethernet physical port,
			or the port is administratively disabled, the corresponding VC label
			mapping MAY be withdrawn. If the egress LSR, R2, does not have a VC
			label mapping for the corresponding Ethernet port, the Ethernet port
			physical layer MAY be disabled.
			4.5. HDLC ( Cisco )
	If the MPLS edge LSR detects that the physical link has failed it		If the MPLS edge LSR detects that the physical link has failed it
	MUST withdraw the label that corresponds to the HDLC link. The Egress		MUST withdraw the label that corresponds to the HDLC link. The Egress
	LSR SHOULD notify the CE device of this failure by using a physical		LSR SHOULD notify the CE device of this failure by using a physical
	layer mechanism to take the link out of service.		layer mechanism to take the link out of service.
	4.4. PPP		4.6. PPP
	If the MPLS edge LSR detects that the physical link has failed it		If the MPLS edge LSR detects that the physical link has failed it
	MUST withdraw the label that corresponds to the PPP link. The Egress		MUST withdraw the label that corresponds to the PPP link. The Egress
	LSR SHOULD notify the CE device of this failure by using a physical		LSR SHOULD notify the CE device of this failure by using a physical
	layer mechanism to take the link out of service.		layer mechanism to take the link out of service.
			4.7. Static MPLS
			The MPLS frames encapsulated according to [3] using any layer 2
			technology that is commonly used to transport MPLS can be transported
			across the service provider MPLS network using the methods described
			in this document. The VC label in this case is the statically
			configured label that is accepted at the ingress LSR R1, and
			advertised with an associated VC ID in LDP. The VC ID has to match in
			both directions on a particular VC. At the egress LSR, R2 a common
			MPLS label swap operation will swap the VC label with the label that
			is statically configured for this particular VC. This transport mode
			can be used to offer packet transport using different kinds of layer
			2 access infrastructures.
	5. LDP		5. LDP
	The VC label bindings are distributed using the LDP downstream		The VC label bindings are distributed using the LDP downstream
	unsolicited mode described in [1]. The LSRs will establish an LDP		unsolicited mode described in [1]. The LSRs will establish an LDP
	session using the Extended Discovery mechanism described in [1,		session using the Extended Discovery mechanism described in [1,
	section 2.4-2.5], for this purpose a new type of FEC TLV element is		section 2.4-2.5], for this purpose a new type of FEC element is
	defined. The FEC element type is 128. [note1]		defined. The FEC element type is 128. [note1]
	The Virtual Circuit FEC TLV element, is defined as follows:		The Virtual Circuit FEC element, is defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| VC tlv |C| VC Type | VC ID len |		| VC tlv |C| VC Type |VC info Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group ID |		| Group ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| VC ID |
	| VC ID |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| Interface parameters |
			| " |
			| " |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	- VC Type		- VC Type
	A 15 bit quantity containing a value which represents the type of		A 15 bit quantity containing a value which represents the type of
	VC. Assigned Values are:		VC. Assigned Values are:
	VC Type Description		VC Type Description
	0x0001 Frame Relay DLCI		0x0001 Frame Relay DLCI
	0x0002 ATM VCC transport		0x0002 ATM AAL5 VCC transport
	0x0003 ATM VPC transport		0x0003 ATM transparent cell transport
	0x0004 Ethernet VLAN		0x0004 Ethernet VLAN
	0x0005 Ethernet		0x0005 Ethernet
	0x0006 HDLC ( Cisco )		0x0006 HDLC ( Cisco )
	0x0007 PPP		0x0007 PPP
	0x8008 CEM [8]		0x8008 CEM [8]
			0x0009 ATM VCC cell transport
			0x000A ATM VPC cell transport
			0x000B MPLS
			- Control word bit (C)
			The highest order bit (C) of the Vc type is used to flag the
			presence of a control word ( defined in [7] ) as follows:
	The highest order bit is used to flag the presence of a control word as
	follows:
	bit 15 = 1 control word present on this VC.		bit 15 = 1 control word present on this VC.
	bit 15 = 0 no control word present on this VC.		bit 15 = 0 no control word present on this VC.
	- VC ID length		- VC information length
	Length of the VC ID field in octets. If this value is 0, then it		Length of the VC ID field and the interface parameters field in
	references all VCs using the specified group ID		octets. If this value is 0, then it references all VCs using the
			specified group ID and there is no VC ID present, nor any
			interface parameters.
	- Group ID		- Group ID
	An arbitrary 32 bit value which represents a group of VCs that is		An arbitrary 32 bit value which represents a group of VCs that is
	used to augment the VC space. This value MUST be user		used to augment the VC space. This value MUST be user
	configurable. The group ID is intended to be used as either a		configurable. The group ID is intended to be used as a port
	port index , or a virtual tunnel index. In the latter case a		index, or a virtual tunnel index. To simplify configuration a
	switching function at ingress will map a particular circuit from		particular VC ID at ingress could be part of the virtual tunnel
	a port to a circuit in the virtual tunnel for transport to the		for transport to the egress router. The Group ID is very useful
	egress router.		to send a wild card label withdrawals to remote LSRs upon
			physical port failure.
	- VC ID		- VC ID
	Identifies a particular VC. The interpretation of the identifier		A non zero 32-bit connection ID that together with the VC type,
	depends on the VC type:		identifies a particular VC.
	* Frame Relay
	A 32-bit value representing a 16-bit DLCI value 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | DLCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	* ATM VCC Transport		- Interface parameters
	A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as		This variable length field is used to provide interface specific
	follows:		parameters, such as interface MTU.
	0 1 2 3		5.1. Interface Parameters Field
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| VPI | VCI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	* ATM VPC Transport		This field specifies edge facing interface specific parameters and
			SHOULD be used to validate that the LSRs, and the ingress and egress
			ports at the edges of the circuit have the necessary capabilities to
			interoperate with each other. The field structure is defines as
			follows:
	A 32-bit value containing a 16-bit VPI 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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Parameter ID | Length | Variable Length Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Variable Length Value |
			| " |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The parameter ID is defined as follows:
			Parameter ID Length Description
	0 1 2 3		0x01 4 Interface MTU in octets.
	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		0x02 4 Maximum Number of concatenated ATM cells.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		0x03 up to 82 Optional Interface Description string.
	| VPI | Reserved |		0x04 4 CEM [8] Payload Bytes.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		0x05 4 CEM options.
	* Ethernet VLAN		The Length field is defined as the length of the interface parameter
			including the parameter id and length field itself.
	A 32 bit value representing 16bit vlan identifier as follows:		- Interface MTU
	0 1 2 3		A 2 octet value indicating the MTU in bytes. This is the Maximum
	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		Transmit Unit of the egress packet interface that will be
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		transmitting the decapsulated PDU that is received from the MPLS
	| Reserved | VLAN ID |		network. This parameter is REQUIRED, and SHOULD match in both
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		direction of a specific circuit. The MTU is specified in bytes,
			and if it does not match on a specific circuit, that circuit
			should not be enabled. This parameter is applicable only to VC
			types 1, 2, 4, 5, 6, 7, and 0x0b.
	* Ethernet		- Maximum Number of concatenated ATM cells
	A 32 bit port identifier.		This 2 octet parameter specifies the maximum number of
			concatenated ATM cells that can be processed as a single PDU by
			the egress LSR. This parameter does not need to match in both
			directions of a specific LSR. This parameter is REQUIRED for the
			following VC types: 3, 9, and 0x0a. An LSR transmitting
			concatenated cells on this VC can concatenate a number of cells
			up to the value of this parameter, but MUST NOT exceed it.
	* HDLC ( Cisco )		- Optional Interface Description string
	A 32-bit port identifier		This arbitrary, OPTIONAL, interface description string can be
			used to send an administrative description text string to the
			remote LSR. This parameter is OPTIONAL, and is applicable to all
			VC types. The interface description parameter length is variable,
			and can be up to 80 octets.
	* PPP		- Payload Bytes
	A 32-bit port identifier		A 2 octet value indicating the the number of TDM payload octets
			contained in all packets on the CEM stream, from 48 to 1,023
			octets. All of the packets in a given CEM stream have the same
			number of payload bytes. Note that there is a possibility that
			the packet size may exceed the SPE size in the case of an STS-1
			SPE, which could cause two pointers to be needed in the CEM
			header, since the payload may contain two J1 bytes for
			consecutive SPEs. For this reason, the number of payload bytes
			must be less than or equal to 783 for STS-1 SPEs.
	* CEM[8]		- CEM Options. An optional 16 Bit value of CEM Flags. Bit 0 is
			defined being set to indicate CEM-DBA in operation.
	A 32-bit value used follows:		6. IANA Considerations
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Circuit ID | Payload Bytes |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Circuit ID: An assigned number for the SONET circuit being		As specified in this document, a Virtual Circuit FEC element contains
	transported.		the VC Type field. VC Type value 0 is reserved. VC Type values 1
			through 11 are defined in this document. VC Type values 12 through 63
			are to be assigned by IANA using the "IETF Consensus" policy defined
			in RFC2434. VC Type values 64 through 127 are to be assigned by IANA,
			using the "First Come First Served" policy defined in RFC2434. VC
			Type values 128 through 32767 are vendor-specific, and values in this
			range are not to be assigned by IANA.
	Payload Bytes(N): the number of TDM payload bytes contained		As specified in this document, a Virtual Circuit FEC element contains
	in all packets on the CEM stream, from 48 to 1,023 bytes. All		the Interface Parameters field, which is a list of one or more
	of the packets in a given CEM stream have the same number of		parameters, and each parameter is identified by the Parameter ID
	payload bytes. Note that there is a possibility that the		field. Parameter ID value 0 is reserved. Parameter ID values 1
	packet size may exceed the SPE size in the case of an STS-1		through 5 are defined in this document. Parameter ID values 6
	SPE, which could cause two pointers to be needed in the CEM		through 63 are to be assigned by IANA using the "IETF Consensus"
	header, since the payload may contain two J1 bytes for		policy defined in RFC2434. Parameter ID values 64 through 127 are to
	consecutive SPEs. For this reason, the number of payload		be assigned by IANA, using the "First Come First Served" policy
	bytes must be less than or equal to 783 for STS-1 SPEs. The		defined in RFC2434. Parameter ID values 128 through 255 are vendor-
	reserved fields in the above specifications MUST be set to 0		specific, and values in this range are not to be assigned by IANA.
	in the FEC TLV, and ignored when received.
	6. Security Considerations		7. Security Considerations
	This document does not affect the underlying security issues of MPLS.		This document does not affect the underlying security issues of MPLS.
	7. References		8. References
	[1] "LDP Specification", draft-ietf-mpls-ldp-11.txt ( work in		[1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A.
	progress )		Fredette, B. Thomas. January 2001. RFC3036
	[2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame		[2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame
	Mode Basic call control, ITU Geneva 1995		Mode Basic call control, ITU Geneva 1995
	[3] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-08.txt		[3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G.
	( work in progress )		Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032
	[4] "IEEE 802.3ac-1998" IEEE standard specification.		[4] "IEEE 802.3ac-1998" IEEE standard specification.
	[5] American National Standards Institute, "Synchronous Optical		[5] American National Standards Institute, "Synchronous Optical
	Network Formats," ANSI T1.105-1995.		Network Formats," ANSI T1.105-1995.
	[6] ITU Recommendation G.707, "Network Node Interface For The		[6] ITU Recommendation G.707, "Network Node Interface For The
	Synchronous Digital Hierarchy", 1996.		Synchronous Digital Hierarchy", 1996.
	[7] "Encapsulation Methods for Transport of Layer 2 Frames Over		[7] "Encapsulation Methods for Transport of Layer 2 Frames Over
	MPLS", draft-martini-l2circuit-encap-mpls-00.txt ( Work in progress )		MPLS", draft-martini-l2circuit-encap-mpls-01.txt ( Work in progress )
	[8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM)		[8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM)
	Encapsulation", draft-malis-sonet-ces-mpls-01.txt ( Work in progress		Encapsulation", draft-malis-sonet-ces-mpls-01.txt ( Work in progress
	)		)
	[9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000.		[9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000.
	[note1] FEC element type 128 is pending IANA approval.		[note1] FEC element type 128 is pending IANA approval.
	8. Author Information		9. Author Information
	Luca Martini		Luca Martini
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	1025 Eldorado Blvd.		1025 Eldorado Blvd.
	Broomfield, CO, 80021		Broomfield, CO, 80021
	e-mail: luca@level3.net		e-mail: luca@level3.net
	Nasser El-Aawar		Nasser El-Aawar
	Level 3 Communications, LLC.		Level 3 Communications, LLC.
	1025 Eldorado Blvd.		1025 Eldorado Blvd.
	Broomfield, CO, 80021		Broomfield, CO, 80021
	e-mail: nna@level3.net		e-mail: nna@level3.net
	Giles Heron		Giles Heron
	Level 3 Communications		Level 3 Communications
	66 Prescot Street		66 Prescot Street
	London		London
	skipping to change at page 10, line 23 ¶		skipping to change at page 13, line 4 ¶
	London		London
	E1 8HG		E1 8HG
	United Kingdom		United Kingdom
	e-mail: giles@level3.net		e-mail: giles@level3.net
	Dimitri Stratton Vlachos		Dimitri Stratton Vlachos
	Mazu Networks, Inc.		Mazu Networks, Inc.
	125 Cambridgepark Drive		125 Cambridgepark Drive
	Cambridge, MA 02140		Cambridge, MA 02140
	e-mail: d@mazunetworks.com		e-mail: d@mazunetworks.com
	Dan Tappan		Dan Tappan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	e-mail: tappan@cisco.com		e-mail: tappan@cisco.com
			Jayakumar Jayakumar,
			Cisco Systems Inc.
			225, E.Tasman, MS-SJ3/3,
			San Jose, CA, 95134
			e-mail: jjayakum@cisco.com
			Alex Hamilton,
			Cisco Systems Inc.
			285 W. Tasman, MS-SJCI/3/4,
			San Jose, CA, 95134
			e-mail: tahamilt@cisco.com
	Eric Rosen		Eric Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	e-mail: erosen@cisco.com		e-mail: erosen@cisco.com
	Steve Vogelsang		Steve Vogelsang
	Laurel Networks, Inc.		Laurel Networks, Inc.
	2607 Nicholson Rd.		2607 Nicholson Rd.
	Sewickley, PA 15143		Sewickley, PA 15143
	skipping to change at page 11, line 4 ¶		skipping to change at page 13, line 33 ¶
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	e-mail: erosen@cisco.com		e-mail: erosen@cisco.com
	Steve Vogelsang		Steve Vogelsang
	Laurel Networks, Inc.		Laurel Networks, Inc.
	2607 Nicholson Rd.		2607 Nicholson Rd.
	Sewickley, PA 15143		Sewickley, PA 15143
	e-mail: sjv@laurelnetworks.com		e-mail: sjv@laurelnetworks.com
	John Shirron		John Shirron
	Laurel Networks, Inc.		Laurel Networks, Inc.
	2607 Nicholson Rd.		2607 Nicholson Rd.
	Sewickley, PA 15143		Sewickley, PA 15143
	e-mail: jshirron@laurelnetworks.com		e-mail: jshirron@laurelnetworks.com
	Andrew G. Malis		Andrew G. Malis
	Vivace Networks, Inc.		Vivace Networks, Inc.
	2730 Orchard Parkway		2730 Orchard Parkway
	San Jose, CA 95134		San Jose, CA 95134
	Phone: +1 408 383 7223		Phone: +1 408 383 7223
	Email: Andy.Malis@vivacenetworks.com		Email: Andy.Malis@vivacenetworks.com
			Vinai Sirkay
			Vivace Networks, Inc.
			2730 Orchard Parkway
			San Jose, CA 95134
			e-mail: vinai.sirkay@vivacenetworks.com
End of changes. 73 change blocks.
	165 lines changed or deleted		298 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/