draft-ietf-mpls-generalized-cr-ldp-00.txt		draft-ietf-mpls-generalized-cr-ldp-01.txt
	Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)		Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)
	Internet Draft Ayan Banerjee (Calient Networks)		Internet Draft Ayan Banerjee (Calient Networks)
	Expiration Date: May 2001 Lou Berger (Movaz Networks)		Expiration Date: September 2001 Lou Berger (Movaz Networks)
	Greg Bernstein (Ciena Corporation)		Greg Bernstein (Ciena Corporation)
	John Drake (Calient Networks)		John Drake (Calient Networks)
	Yanhe Fan (Axiowave Networks)		Yanhe Fan (Axiowave Networks)
	Kireeti Kompella (Juniper Networks, Inc.)		Kireeti Kompella (Juniper Networks, Inc.)
	Eric Mannie (GTS)		Eric Mannie (EBONE)
	Jonathan P. Lang (Calient Networks)		Jonathan P. Lang (Calient Networks)
	Bala Rajagopalan (Tellium, Inc.)		Bala Rajagopalan (Tellium, Inc.)
	Yakov Rekhter (Cisco Systems)		Yakov Rekhter (Juniper Networks, Inc.)
	Debanjan Saha (Tellium, Inc.)		Debanjan Saha (Tellium, Inc.)
	Vishal Sharma (Tellabs)		Vishal Sharma (Jasmine Networks)
	George Swallow (Cisco Systems)		George Swallow (Cisco Systems)
	Z. Bo Tang (Tellium, Inc.)		Z. Bo Tang (Tellium, Inc.)
	November 2000		March 2001
	Generalized MPLS Signaling - CR-LDP Extensions		Generalized MPLS Signaling - CR-LDP Extensions
	draft-ietf-mpls-generalized-cr-ldp-00.txt		draft-ietf-mpls-generalized-cr-ldp-01.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. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		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		To view the current status of any Internet-Draft, please check the
	http://www.ietf.org/ietf/1id-abstracts.txt		"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
			Directory, see http://www.ietf.org/shadow.html.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes extensions to CR-LDP signaling required to		This document describes extensions to CR-LDP signaling required to
	support Generalized MPLS. Generalized MPLS extends MPLS to encompass		support Generalized MPLS. Generalized MPLS extends MPLS to encompass
	time-division (e.g. SONET ADMs), wavelength (optical lambdas) and		time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
	spatial switching (e.g. incoming port or fiber to outgoing port or		spatial switching (e.g. incoming port or fiber to outgoing port or
	fiber). This document presents a CR-LDP specific description of the		fiber). This document presents a CR-LDP specific description of the
	extensions. An RSVP-TE specific description can be found in [GMPLS-		extensions. An RSVP-TE specific description can be found in [GMPLS-
	RSVP]. A generic functional description is presented in [GMPLS-SIG].		RSVP]. A generic functional description is presented in [GMPLS-SIG].
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	2.2.1 Procedures ................................................ 6		2.2.1 Procedures ................................................ 6
	2.3 Waveband Switching ........................................ 6		2.3 Waveband Switching ........................................ 6
	2.3.1 Procedures ................................................ 7		2.3.1 Procedures ................................................ 7
	2.4 Suggested Label ........................................... 8		2.4 Suggested Label ........................................... 8
	2.5 Label Set ................................................. 8		2.5 Label Set ................................................. 8
	2.5.1 Procedures ................................................ 8		2.5.1 Procedures ................................................ 8
	3 Bidirectional LSPs ........................................ 9		3 Bidirectional LSPs ........................................ 9
	3.1 Procedures ................................................ 10		3.1 Procedures ................................................ 10
	4 Explicit Label Control .................................... 10		4 Explicit Label Control .................................... 10
	4.1 Procedures ................................................ 11		4.1 Procedures ................................................ 11
	5 Acknowledgments ........................................... 12		5 Protection TLV ............................................ 12
	6 Security Considerations ................................... 12		5.1 Procedures ................................................ 12
	7 References ................................................ 12		6 Acknowledgments ........................................... 12
	8 Authors' Addresses ........................................ 13		7 Security Considerations ................................... 13
			8 References ................................................ 13
			9 Authors' Addresses ........................................ 13
	Changes from previous version:		Changes from previous version:
	o Moved protocol specific details into two documents, one for RSVP-TE		o Revised label request
	and one for CR-LDP.		o Moved protection flags to separate object
	o Clarified Label Set
	o Minor text cleanup		o Minor text cleanup
	1. Introduction		1. Introduction
	Generalized MPLS extends MPLS from supporting packet (PSC) interfaces		Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
	and switching to include support of three new classes of interfaces		and switching to include support of three new classes of interfaces
	and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and		and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
	Fiber-Switch (FSC). A functional description of the extensions to		Fiber-Switch (FSC). A functional description of the extensions to
	MPLS signaling needed to support the new classes of interfaces and		MPLS signaling needed to support the new classes of interfaces and
	switching is provided in [GMPLS-SIG]. This document presents CR-LDP		switching is provided in [GMPLS-SIG]. This document presents CR-LDP
	skipping to change at page 4, line 19		skipping to change at page 4, line 19
	LSRs. A Generalized Label Request TLV is set by the ingress node,		LSRs. A Generalized Label Request TLV is set by the ingress node,
	transparently passed by transit nodes, and used by the egress node.		transparently passed by transit nodes, and used by the egress node.
	The format of a Generalized Label Request is:		The format of a Generalized Label Request is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| 0x0901 | Length |		|U|F| 0x0901 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Enc. Type |Link Prot.Flags| G-PID |		| LSP Enc. Type | Reserved | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	2.1.1. Generalized Label Request with SONET/SDH Label Range		2.1.1. Generalized Label Request with SONET/SDH Label Range
	The format of a Generalized Label Request with SONET/SDH label range		The format of a Generalized Label Request with SONET/SDH label range
	(in CR-LDP) is:		(in CR-LDP) is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| 0x0902 | Length |		|U|F| 0x0902 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Enc. Type |Link Prot.Flags| G-PID |		| LSP Enc. Type | Reserved | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RGT | RT | Reserved | RNC |		| RNC | Signal Type |Rsrved.| RGT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	2.1.2. Procedures		2.1.2. Procedures
	A node processing the REQUEST message containing the Generalized		A node processing a REQUEST message containing a Generalized Label
	Label Request must verify that the requested parameters can be		Request must verify that the requested parameters can be satisfied by
	satisfied by the incoming interface, the node and by the outgoing		the incoming interface, the node and by the outgoing interface. The
	interface. The node may either directly support the LSP or it may		node may either directly support the LSP or it may use a tunnel (FA),
	use a tunnel (FA), i.e., another class of switching. In either case,		i.e., another class of switching. In either case, each parameter
	each parameter must be checked.		must be checked.
	Note that local node policy dictates when tunnels may be used and		Note that local node policy dictates when tunnels may be used and
	when they may be created. Local policy may allow for tunnels to be		when they may be created. Local policy may allow for tunnels to be
	dynamically established or may be solely administratively controlled.		dynamically established or may be solely administratively controlled.
	For more information on tunnels and processing of ER hops when using		For more information on tunnels and processing of ER hops when using
	tunnels see [MPLS-HIERARCHY].		tunnels see [MPLS-HIERARCHY].
	Transit and egress nodes MUST verify that the node itself and, where		Transit and egress nodes MUST verify that the node itself and, where
	appropriate, that the outgoing interface or tunnel can support the		appropriate, that the outgoing interface or tunnel can support the
	requested LSP Encoding Type. If encoding cannot be supported, the		requested LSP Encoding Type. If encoding cannot be supported, the
	node MUST generate a NOTIFICATION message, with a "Routing		node MUST generate a NOTIFICATION message, with a "Routing
	problem/Unsupported Encoding" indication.		problem/Unsupported Encoding" indication.
	Transit nodes MUST verify that the outgoing interface or tunnel can
	support the requested Link Protection Flags. If it cannot, the node
	MUST generate a NOTIFICATION message, with a "Routing
	problem/Unsupported Link Protection" indication.
	The G-PID parameter is normally only examined at the egress. If the		The G-PID parameter is normally only examined at the egress. If the
	indicated G-PID cannot be supported then the egress MUST generate a		indicated G-PID cannot be supported then the egress MUST generate a
	NOTIFICATION message, with a "Routing problem/Unsupported GPID"		NOTIFICATION message, with a "Routing problem/Unsupported GPID"
	indication. In the case of PSC and when penultimate hop popping		indication. In the case of PSC and when penultimate hop popping
	(PHP) is requested, the penultimate hop also examines the (stored) G-		(PHP) is requested, the penultimate hop also examines the (stored) G-
	PID during the processing of the MAPPING message. In this case if		PID during the processing of the MAPPING message. In this case if
	the G-PID is not supported, then the penultimate hop MUST generate a		the G-PID is not supported, then the penultimate hop MUST generate a
	NOTIFICATION message with a "Routing problem/Unacceptable label		NOTIFICATION message with a "Routing problem/Unacceptable label
	value" indication.		value" indication.
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	|0|0| 0x901 | Length |		|0|0| 0x901 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L|U| Reserved | Label |		|L|U| Reserved | Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label (continued) |		| Label (continued) |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of L, U and Label parameters.		See [GMPLS-SIG] for a description of L, U and Label parameters.
	Length
	Specifies the length of the value field in bytes.
	4.1. Procedures		4.1. Procedures
	The Label ER-Hop follows a ER-Hop containing the IP address, or the		The Label ER-Hop follows a ER-Hop containing the IP address, or the
	interface identifier [MPLS-UNNUM], associated with the link on which		interface identifier [MPLS-UNNUM], associated with the link on which
	it is to be used. The preceding ER-Hop must be strict. Up to two		it is to be used. The preceding ER-Hop must be strict. Up to two
	label ER-Hops may be present, one for the downstream label and one		label ER-Hops may be present, one for the downstream label and one
	for the upstream label. The following SHOULD result in "Bad		for the upstream label. The following SHOULD result in "Bad
	EXPLICIT_ROUTE" errors:		EXPLICIT_ROUTE" errors:
	- If the first label ER-Hop is not preceded by a ER-Hop		- If the first label ER-Hop is not preceded by a ER-Hop
	containing an IP address, or a interface identifier		containing an IP address, or a interface identifier
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	Note an implication of the above procedures is that the label ER-Hop		Note an implication of the above procedures is that the label ER-Hop
	should never be the first ER-Hop in a newly received message. If the		should never be the first ER-Hop in a newly received message. If the
	label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD		label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD
	be treated as a "Bad strict node" error.		be treated as a "Bad strict node" error.
	Procedures by which an LSR at the head-end of an LSP obtains the		Procedures by which an LSR at the head-end of an LSP obtains the
	information needed to construct the Label ER-Hop are outside the		information needed to construct the Label ER-Hop are outside the
	scope of this document.		scope of this document.
	5. Acknowledgments		5. Protection TLV
			The use of the Protection Object is optional. The object is included
			to indicate specific protection attributes of an LSP.
			The format of Protection Flags Object is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|U|F| TBA | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|S| Reserved | Link Flags|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			See [GMPLS-SIG] for a description of parameters.
			5.1. Procedures
			Transit nodes processing a REQUEST message containing a Protection
			Object MUST verify that the requested protection can be satisfied by
			the outgoing interface or tunnel (FA). If it cannot, the node MUST
			generate a NOTIFICATION message, with a "Routing problem/Unsupported
			Link Protection" indication.
			6. Acknowledgments
	This draft is the work of numerous authors and consists of a		This draft is the work of numerous authors and consists of a
	composition of a number of previous drafts in this area. A list of		composition of a number of previous drafts in this area. A list of
	the drafts from which material and ideas were incorporated follows:		the drafts from which material and ideas were incorporated follows:
	draft-saha-rsvp-optical-signaling-00.txt		draft-saha-rsvp-optical-signaling-00.txt
	draft-lang-mpls-rsvp-oxc-00.txt		draft-lang-mpls-rsvp-oxc-00.txt
	draft-kompella-mpls-optical-00.txt		draft-kompella-mpls-optical-00.txt
	draft-fan-mpls-lambda-signaling-00.txt		draft-fan-mpls-lambda-signaling-00.txt
	Valuable comments and input were received from a number of people,		Valuable comments and input were received from a number of people,
	notably Adrian Farrel.		notably Adrian Farrel.
	6. Security Considerations		7. Security Considerations
	This draft introduce no new security considerations to [CR-LDP].		This draft introduce no new security considerations to [CR-LDP].
	7. References		8. References
	[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",		[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
	draft-ietf-mpls-cr-ldp-04.txt, July, 2000.		draft-ietf-mpls-cr-ldp-04.txt, July, 2000.
	[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with		[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
	MPLS TE", Internet Draft,		MPLS TE", Internet Draft,
	draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000.		draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000.
	[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -		[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
	RSVP-TE Extensions", Internet Draft,		RSVP-TE Extensions", Internet Draft,
	draft-ietf-mpls-generalized-rsvp-te-00.txt,		draft-ietf-mpls-generalized-rsvp-te-01.txt,
	November 2000.		February 2001.
	[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -		[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
	Signaling Functional Description", Internet Draft,		Signaling Functional Description", Internet Draft,
	draft-ietf-mpls-generalized-signaling-01.txt,		draft-ietf-mpls-generalized-signaling-02.txt,
	November 2000.		February 2001.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119.		Requirement Levels," RFC 2119.
	[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki,		[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki,
	"Improving Topology Data Base Accuracy With LSP Feedback		"Improving Topology Data Base Accuracy With LSP Feedback
	via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt.		via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt.
	8. Authors' Addresses		9. Authors' Addresses
	Peter Ashwood-Smith		Peter Ashwood-Smith
	Nortel Networks Corp.		Nortel Networks Corp.
	P.O. Box 3511 Station C,		P.O. Box 3511 Station C,
	Ottawa, ON K1Y 4H7		Ottawa, ON K1Y 4H7
	Canada		Canada
	Phone: +1 613 763 4534		Phone: +1 613 763 4534
	Email: petera@nortelnetworks.com		Email: petera@nortelnetworks.com
	Ayan Banerjee		Ayan Banerjee
	skipping to change at page 13, line 21		skipping to change at page 14, line 4
	Canada		Canada
	Phone: +1 613 763 4534		Phone: +1 613 763 4534
	Email: petera@nortelnetworks.com		Email: petera@nortelnetworks.com
	Ayan Banerjee		Ayan Banerjee
	Calient Networks		Calient Networks
	5853 Rue Ferrari		5853 Rue Ferrari
	San Jose, CA 95138		San Jose, CA 95138
	Phone: +1 408 972-3645		Phone: +1 408 972-3645
	Email: abanerjee@calient.net		Email: abanerjee@calient.net
	Lou Berger		Lou Berger
	Movaz Networks		Movaz Networks, Inc.
	Phone: +1 301 468 9228		7926 Jones Branch Drive
			Suite 615
			McLean VA, 22102
			Phone: +1 703 847-1801
	Email: lberger@movaz.com		Email: lberger@movaz.com
	Greg Bernstein		Greg Bernstein
	Ciena Corporation		Ciena Corporation
	10480 Ridgeview Court		10480 Ridgeview Court
	Cupertino, CA 94014		Cupertino, CA 94014
	Phone: +1 408 366 4713		Phone: +1 408 366 4713
	Email: greg@ciena.com		Email: greg@ciena.com
	John Drake		John Drake
	skipping to change at page 14, line 15		skipping to change at page 15, line 4
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: kireeti@juniper.net		Email: kireeti@juniper.net
	Jonathan P. Lang		Jonathan P. Lang
	Calient Networks		Calient Networks
	25 Castilian		25 Castilian
	Goleta, CA 93117		Goleta, CA 93117
	Email: jplang@calient.net		Email: jplang@calient.net
	Eric Mannie		Eric Mannie
	GTS		EBONE
	Terhulpsesteenweg 6A		Terhulpsesteenweg 6A
	1560 Hoeilaart - Belgium		1560 Hoeilaart - Belgium
	Phone: +32 2 658 56 52		Phone: +32 2 658 56 52
	Mobile: +32 496 58 56 52		Mobile: +32 496 58 56 52
	Fax: +32 2 658 51 18		Fax: +32 2 658 51 18
	Email: eric.mannie@gts.com		Email: eric.mannie@ebone.com
	Bala Rajagopalan		Bala Rajagopalan
	Tellium, Inc.		Tellium, Inc.
	2 Crescent Place		2 Crescent Place
	P.O. Box 901		P.O. Box 901
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4237		Phone: +1 732 923 4237
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: braja@tellium.com		Email: braja@tellium.com
	Yakov Rekhter		Yakov Rekhter
	cisco Systems		Juniper Networks, Inc.
	Email: yakov@cisco.com		Email: yakov@juniper.net
	Debanjan Saha		Debanjan Saha
	Tellium Optical Systems		Tellium Optical Systems
	2 Crescent Place		2 Crescent Place
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4264		Phone: +1 732 923 4264
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: dsaha@tellium.com		Email: dsaha@tellium.com
	Vishal Sharma		Vishal Sharma
	Tellabs Research Center		Jasmine Networks, Inc.
	One Kendall Square		3061 Zanker Road, Suite B
	Bldg. 100, Ste. 121		San Jose, CA 95134
	Cambridge, MA 02139-1562		Phone: +1 408 895 5030
	Phone: +1 617 577 8760		Fax: +1 408 895 5050
	Email: Vishal.Sharma@tellabs.com		Email: vsharma@jasminenetworks.com
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA 01824		Chelmsford, MA 01824
	Voice: +1 978 244 8143		Voice: +1 978 244 8143
	Email: swallow@cisco.com		Email: swallow@cisco.com
	Z. Bo Tang		Z. Bo Tang
	Tellium, Inc.		Tellium, Inc.
	2 Crescent Place		2 Crescent Place
	P.O. Box 901		P.O. Box 901
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4231		Phone: +1 732 923 4231
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: btang@tellium.com		Email: btang@tellium.com
			Generated on: Fri Mar 2 14:09:47 EST 2001
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/