< draft-shen-ip-te-rsp-02.txt		draft-shen-ip-te-rsp-03.txt >
	skipping to change at page 1, line 17 ¶		skipping to change at page 1, line 17 ¶
	Redback Networks		Redback Networks
	D. Papadimitriou		D. Papadimitriou
	Alcatel		Alcatel
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	October 2004		October 2004
	IP Traffic Engineering With Route Switched Paths (RSPs)		IP Traffic Engineering With Route Switched Paths (RSPs)
	draft-shen-ip-te-rsp-02.txt
	1. Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as ``work in progress.''
	The list of current Internet-Drafts can be accessed at
	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.
	2. Abstract
	This document describes a mechanism to establish traffic
	engineering IP tunnels. RSVP is used as a signaling protocol
	described in GMPLS RSVP Traffic Engineering technology, but no
	MPLS forwarding capability is assumed on the switched path. IP
	routing is used to switch IP traffic trunks. A simple GMPLS RSVP
	Traffic Engineering extension is needed to setup the IP Route
	Switched Paths (RSPs).
	3. Introduction
	MPLS TE [1, 2] and GMPLS[7, 8] LSPs have been developed and
	deployed to automatically route IP traffic away from network
	failures, congestion and bottlenecks. Commonly MPLS must be enabled
	on the routers through which the LSPs traverse. But some providers
	do not enable MPLS as one of the forwarding capabilities in their
	networks, thus they can not take the advantage offered by MPLS TE
	technologies. Thus by proposing a de-coupling between the TE
	control portion from the MPLS forwarding, the possibility is
	provided to operators to still benefit from Traffic Engineering
	while precluding the mandatory usage of label switching in their
	network.
	IP tunnels, for instance, GRE tunnel [9], IPv6 over IPv4 tunnel
	[10, 11], L2TP tunnel [12], and IPsec tunnel [13], are widely
	deployed in ISPs. Currently there is no mechanism to make resource
	reservation, guarantee end-to-end QoS service, or setup explicit
	routing for those IP tunnels. Other applications such as Next-hop
	Fast Reroute [3] for IP traffic in the environment of pure IP
	networks may require explicitly routed IP tunnels to reach
	the nexthop or next-nexthop nodes.
	This document describes a mechanism called IP TE, which is very
	similar to MPLS TE and offers similar capabilities as MPLS TE,
	but it does not require the network to be MPLS forwarding capable.
	A simple GMPLS RSVP-TE protocol extension is used to signal the
	setup of the IP route switched paths (RSPs).
	In MPLS TE, the signaling model uses downstream-on-demand label
	distribution; while in this IP TE scheme, the egress of a RSP
	allocates an IP route entry for the tunnel, and determines the
	routing along the path for this tunnel. Those IP routing entries
	are no different from other IP routing entries in their routing
	table, thus it does not require IP forwarding plane changes in
	order to support the IP TE mechanism.
	Point-to-point IP tunnels are usually deployed as bi-directional
	circuits in networks. This document also describes an optional
	mechanism having two RSPs in opposite directions to be used as
	a bi-directional IP TE tunnel.
	4. Terminology
	IP Route Request Characterizes the IP tunnel being requested.
	These characteristics include RSP encoding the RSP
	payload and are encoded in the Generalized Label
	Request Object.
	IP Route (Label) Contains the information allowing the receiving
	node to program its IP forwarding engine; this
	information is encoded in the Generalized Label
	Object.
	IP TE Prefix A non-globally routable IP prefix assigned to an
	IP TE egress node. This prefix is advertised through
	IGP.
	IP TE Route An IP route with the IP TE Prefix on egress node
	assigned for a terminated RSP.
	IP Tunnel A tunnel uses IP as the encapsulation for payload.
	Such as GRE, L2TP, IPsec, GTP, IPv6 over IPv4, etc.
	Router ID TE Router-ID. It's a stable IP address such as
	defined in [14, 15].
	RSP IP Route Switched Path. An explicitly routed IP
	tunnel setup by the IP TE. It can be IPv4 RSP or
	IPv6 RSP. The route for the IP tunnel destination
	address is set along the RSP path along with all
	the traffic engineering characteristics.
	RSP Egress Address The RSVP tunnel end-point IP address. It is
	usually the router-ID of the egress node. This
	RSP egress address can be shared among multiple
	tunnels.
	RSP Tunnel Destination The IP tunnel destination address used
	in the packet encapsulation. This tunnel destination
	address is unique to each RSP tunnel in the network.
	It belongs to the IP TE prefix of the egress node.
	LSP An MPLS Label Switched Path. An explicitly switched
	MPLS TE tunnel.
	Trailing Loose Segment The last loose segment to the egress node
	in a strict/loose explicit path.
	5. IP Traffic Engineering Scheme
	A non-globally routable IP address space is reserved for this
	scheme in a network. A network can use private address space
	or it can be assigned by address allocation authorities for
	IPv4 and IPv6. Each egress node is configured with a prefix within
	this address space which is large enough to handle all the RSPs
	terminated on the node. Each RSP tunnel requires an unique
	IP address in this prefix and is allocated by the egress node
	on demand.
	The ingress node of the RSP decides the path to be setup to the
	egress node. It uses the RSVP to establish the tunnel as a special
	GMPLS switching mode. Instead of using Label Request Object in the
	Path message, a new Generalized Label Request Object, we call this
	IP Route Request, is defined in this document to signal the
	egress node to allocate an unused address within the IP TE prefix.
	For the Resv messages, instead of using Label Object, a new
	Generalized Label Object, we call this IP Route (Label), is defined
	to carry the IP host route along the path back to the ingress node.
	The ingress node and all the transit nodes will install this host
	route in their routing table towards the egress node of the RSP.
	Explicit Route Object MAY also be signaled along the Path
	message that used to setup the RSP along the specified path instead
	of following the native IP routing. The ingress node will use this
	IP host address as the RSP tunnel destination. When a RSP is
	brought down, the nodes along the path of this RSP MUST remove
	the host route associated with this RSP from their routing table.
	When a transit RSP node receives a Path message , it must
	determine the nexthop for this path towards the egress point.
	If the Explicit Route Object exists, it must follow the same
	procedure as described in section 4.3.4 of [2] to determine
	the nexthop. When a RSP node receives a Resv message containing the
	IP Route Object, It must install the host route of the tunnel
	destination address of the RSP with the appropriate nexthop
	towards the egress node defined on the path. Since the IP TE prefix
	and the RSP tunnel destination address is partitioned in such
	a way that each RSP has a unique IP TE address in the domain, the
	host route on each node along the RSP path must also be unique.
	Record Route object processing, for e.g. loop avoidance and
	route pinning follows the exactly mechanisms defined in [2].
	When initiating a Path message, the ingress node set the Tunnel
	Sender Address field of the SENDER_TEMPLATE object to its
	Router_ID. The Tunnel Endpoint Address field of the SESSION
	object is set by the ingress node to the egress node Router_ID.
	The Extended_Tunnel_ID field of the SESSION object is set to either
	zero or to an address of the ingress node.
	When initiating a Resv message, the egress node set the FILTER_SPEC
	object as specified by the incoming SENDER_TEMPLATE object.
	5.1 An Example of IP TE RSPs
	Consider the RSP nodes are interconnected as the following diagram
	Figure 1, the R1 is the ingress of RSPa and R4 is the ingress of
	RSPb. Both RSPs have R3 as the egress node:
	100.1.1.1 (router-id)
	10.1.3.0/24 (IP TE prefix)
	o [R1] ==== [R2] ==== [R3]
	| || || ^ 10.1.3.1 ^ 10.1.3.2
	| || || | |
	| +======= [R4] ==== [R5] | RSPa | RSPb
	| | |
	+------------>----------->--+ |
	o---------->----------------+
	Figure 1: An example of IP TE RSPs
	Assume all the links has the IGP metric of 10, R1 sets up RSPa
	with egress node of R3 and explicitly routed (with RSVP ERO
	routes in its Path message) through R4 and R5.
	IPv4 prefix 10.1.3.0/24 is reserved on R3 as the IP TE prefix
	address pool and this IP prefix is advertised through IGP in
	the network. When the Path message gets to R3, R3 picks the
	first unused address within this TE prefix, 10.1.3.1 to be the
	RSP tunnel egress address. The Resv message will be sent back
	following the path through R5, R4 and R1 containing the
	IP Route Object with host route 10.1.3.1. R1, R4 and R5 will
	install the 10.1.3.1/32 in their routing table following the
	explicit path towards R3.
	RSPb is setup from R4 to R3 through R5, and RSP tunnel
	destination address 10.1.3.2 is used. R4 and R5 install the
	route 10.1.3.2/32 towards the egress of the RSP.
	On R1, when the IP routing is resolved onto 100.1.1.1, the
	traffic will be sent through the RSPa with tunnel destination
	address of 10.1.3.1.
	5.2 IP TE Address Allocation
	IP TE prefix(es) are configured on each egress RSP node. The
	address should be allocated to handle the maximum number of IP TE
	tunnels that could terminate on the node.
	This IP TE prefix SHOULD be advertised through the IGP, but it
	SHOULD NOT be advertised outside the domain. The host routes
	installed for the RSPs are only local to the node, and they
	MUST NOT be redistributed into any dynamic routing protocols.
	The host routes allocated by the egress node within the IP TE
	prefix should be treated as local interface routes on the egress
	node. The source address of the tunnel SHOULD use the same
	IP address for the Extended Tunnel ID when the RSVP sets up the
	RSP. The egress node SHOULD check the validity of the RSP by
	examine the source and destination addresses of the IP tunnel.
	6. GMPLS RSVP-TE Extension
	This document defines three new RSVP object C-Types:
	1. Generalized Label Request Object (C-Num = 19, C-Type = 5) to
	encode the IP Route Request
	2. Generalized Label Object (C-Num = 16, C-Type = 4) to encode the
	IPv4 Route (label)
	3. Generalized Label Object (C-Num = 16, C-Type = 5) to encode the
	IPv6 Route (label)
	This is in symmetrical to the (Generalized) Label Request and
	(Generalized) Label objects in (G)MPLS TE label switching.
	6.1 IP Route Request Object (GMPLS Label Request Object Encoding)
	Class-Number = 19, C-Type = 5
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num (19)| C-Type (5) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Enc. Type |Switching Type | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RSP Key | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	LSP Encoding Type
	8 bit field. Must be set to 1.
	Switching Type
	8 bits field. Must be set to 0xFF and be ignored on receive.
	G-PID
	16 bit field. An identifier of the protocol type of tunnel
	payload using this path. Standard Ethertype [4] values are
	used.
	RSP Key
	It contains a two octet number which may be used between a
	pair of RSP nodes to identify two RSPs belong to the same
	bi-directional IP tunnel. The UPSTREAM LABEL used in GMPLS
	for bi-directional LSP establishment does not apply here
	in the IP TE context. The RSP Key MUST be set to zero if
	the RSP is a uni-directional one. The actual method by which
	this RSP Key is obtained is beyond the scope of the document.
	6.1.1 Handling of GENERALIZED_LABEL_REQUEST for IP TE
	To establish an RSP tunnel the sender creates a Path message with a
	GENERALIZED_LABEL_REQUEST object. The GENERALIZED_LABEL_REQUEST
	object indicates that an IP host route installation of the IP TE
	address for this path is requested and provides an indication of
	the network layer protocol that is to be carried over this path.
	The GENERALIZED_LABEL_REQUEST object SHOULD be stored in the Path
	State Block, so that Path refresh messages will also contain the
	GENERALIZED_LABEL_REQUEST object.
	A node that recognizes a GENERALIZED_LABEL_REQUEST object, but that
	is unable to support it SHOULD send a PathErr with the error code
	"Routing problem" with error value TBA to indicate "IP TE routing
	install failure".
	Upon Path message reception, if a RSVP router does not recognize the
	GENERALIZED_LABEL_REQUEST object, it SHOULD send a PathErr with
	error code "Unknown object class" toward the sender. If a RSVP
	router does not recognize the GENERALIZED_LABEL_REQUEST type, it
	SHOULD send a PathErr with error code "Unknown object C-Type"
	toward the sender. This causes the IP TE tunnel setup request to
	fail.
	6.2 IP Route Object (An GMPLS Label Object Encoding)
	The IP TE route MAY be carried in Resv messages. The IP TE
	route for a sender MUST immediately follow the FILTER_SPEC object
	for that sender in the Resv message.
	The IP Route object has the following format:
	Class Number = 16, C_Type = 4 (IPv4)
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num (16)| C-Type (4) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP TE Route (IPv4) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Prefix Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The contents of the IP Route of IPv4 is encoded in 8 octets.
	4 octets of IPv4 address. 1 octet of prefix length. The prefix
	length of value 32 should be used in this scheme.
	Class Number = 16, C_Type = 5 (IPv6)
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num (16)| C-Type (5) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP TE Route (IPv6) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP TE Route (IPv6 continued) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP TE Route (IPv6 continued) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP TE Route (IPv6 continued) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Prefix Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The contents of the IP Route of IPv6 is encoded in 20 octets.
	16 octets of IPv6 address. 1 octet of prefix length.
	6.2.1 Handling IP Route Objects in Resv Messages
	The egress RSP node allocates the IP TE route in the IP Route
	object. Once the IP route is allocated or received from a
	downstream node, the node formats an IP Route object and
	sends the new IP Route object as part of the Resv message to the
	previous hop. The transit node and the ingress node SHOULD
	install the IP host route into their routing table. The IP Route
	object SHOULD be kept in the Reservation State Block.
	If a RSVP router does not recognize the GENERALIZED_LABEL type,
	it SHOULD send a ResvErr with error code "Unknown object class"
	toward the receiver. This causes the reservation to fail.
	7. Bi-directional IP Tunnel with RSPs
	The IP TE RSP can be used as an uni-directional traffic truck,
	the same way as an MPLS LSP is used. This section describes an
	optional mechanism that can be applied to allow a pair of RSP
	established IP tunnels as a bi-directional circuit. Even though
	GMPLS has the bi-directional LSP mechanism, but the bi-directional
	LSP is signaled one end LSP, and it can not be used by the other
	end of the LSP as a normal routing interface for services and
	routing functionalities.
	RSVP matches a pair of bi-directional RSPs by identifying three
	fields in the RSVP Path messages: tunnel end-point address,
	Extended Tunnel ID [2, sections 4.6.1.1], and RSP Key
	(section 6.1 above, if there are multiple RSP pairs between the
	two RSP nodes). RSVP installs the source and destination
	addresses as the outbound data encapsulation to be used by the
	bi-directional IP tunnel. The source address is the same as
	the Extended Tunnel ID; the destination address is an IP TE
	host route assigned by the RSP egress node. RSVP also needs to
	inform the IP tunnel about the inbound data encapsulation since
	it will not be simply the reverse of the outbound as in most of
	the normal IP tunnel encapsulation cases.
	(b, a, key1)
	a (loopback) rsp1 --------------------->x (IP TE route)
	[A] [B] b (loopback)
	(IP TE route) y<--------------------- rsp2 [ CONTROL ]
	(a, b, key1)
	...............
	IP tunnel encap (x, a)----------------> [ DATA ]
	<------------------ IP tunnel encap (y, b)
	Figure 2: RSPs in control plane and IP tunnel in data plane
	Assume the IP tunnel is established using a pair of RSPs, rsp1
	and rsp2 between node A and B. Further assume A has its loopback
	address 'a' and B has its loopback address 'b'. RSVP on A sends
	a Path message for rsp1 using (b, a, key1), where 'b' is the
	tunnel end-point address, 'a' is the extended tunnel ID, and
	key1 is the RSP key. Assume B will assign an IP TE route 'x' for
	this rsp1. Similarly, RSVP on B sends a Path message for rsp2
	using (a, b, key1), and A will assign an IP TE route 'y' for
	this rsp2. Node A and node B match the pair of RSPs by those three
	identifiers to belong to a bi-directional circuit. RSVP on Nodes
	A and B determine the data encapsulation for the IP tunnel. On
	node A, the IP tunnel will use 'x' as the tunnel destination,
	and 'a' as the tunnel source for outbound encapsulation. It also
	checks the inbound tunnel with destination address of 'y' and
	source address of 'b' for the IP tunnel. The RSP Key key1 is not
	used by IP tunnel encapsulation and it is only internal to RSVP.
	On node B, the operation is the same as above, it sends out with
	destination of 'y' and source of 'b', and expects inbound with
	destination of 'x' and source of 'a'.
	A backup RSP should have a different IP TE route assigned by the
	same egress node to protect the primary RSP. When the backup RSP
	is used instead of the primary, the RSVP needs to update the
	IP tunnel with the new encapsulation.
	8. Trailing Loose Segment Optimization
	Different from the MPLS TE, since the RSP egress node advertises
	the assigned IP TE prefix to the network through IGP, it is possible
	to have the nodes along the trailing loose segment not to install
	the more specific IP host route for the RSP. Packets belong to the
	RSP can be delivered to the egress RSP node following the less
	specific IP TE prefix of the egress RSP node. Thus it is possible
	to have the first node on the trailing loose segment to send the
	Path message directly to the egress of the RSP.
	This optimization assumes that there is no traffic engineering
	requirement in the trailing loose segment of the RSP. For
	applications such as Next-hop Fast Reroute for IP/LDP traffic,
	this can be a valid assumption. In that case, a repair path usually
	only need to specify one or two short segments close to the ingress
	node, thus very few RSVP states need to be kept along the
	fastreroute repair paths.
	When this optimization is used, the Path message being sent
	directly to the egress node MUST NOT include the Router Alert
	IP option [6] in its IP header.
	9. IANA Considerations
	The IP TE proposal requires that IANA allocate a C-Type for
	GENERALIZED_LABEL_REQUEST object and a C-Type for GENERALIZED_LABEL
	object. IANA also needs to allocate the Error Code for "IP TE
	routing install failure" sub-code.
	10. Security Considerations
	The same RSVP security issues in [5] still apply. The reserved IP
	TE prefixes SHOULD not be advertised outside the domain. The
	operators can filter the traffic on non-backbone ports to drop
	the packets destine to the IP TE prefix blocks. The operators
	can also use IP tunnel with keys or authentication.
	11. Acknowledgments
	The authors would like to thank Changming Liu and Ping Pan for
	their comments to this document.
	12. References
	[1] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
	"Requirements for Traffic Engineering Over MPLS", RFC 2702,
	September 1999.
	[2] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
	tunnels", RFC 3209, December 2001.
	[3] Shen, N. and Pan, P., "Nexthop Fast ReRoute for IP and
	MPLS", draft-shen-nhop-fastreroute-00.txt, work in progress.
	[4] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
	October 1994.
	[5] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
	"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
	Specification", RFC 2205, September 1997.
	[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
	[7] L.Berger (Editor) et al., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description,"
	RFC 3471, January 2003.
	[8] L.Berger (Editor) et al., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource Reservation Protocol -
	Traffic Engineering (RSVP-TE) Extensions," RFC 3473,
	January 2003.
	[9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
	"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
	[10] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
	and Routers", RFC 1933, April 1996.
	[11] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains
	without Explicit Tunnels", RFC 2529, March 1999.
	[12] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
	and B. Palter, "Layer Two Tunneling Protocol - L2TP", RFC 2661,
	August 1999.
	[13] Kent, S. and R. Atkinson, "IP Encapsulating Security
	Payload (ESP)", RFC 2406, November 1998.
	[14] H. Smit, T. Li, "Intermediate System to Intermediate System
	(IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
	June 2004.
	[15] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE)
	Extensions to OSPF Version 2", RFC 3630, September 2003.
	13. Authors' Addresses
	Naiming Shen
	BCN Systems
	2975 San Ysidro Way
	Santa Clara, CA 95051
	Email: naiming@bcn-inc.net
	Albert Tian
	Redback Networks
	300 Holger Way
	San Jose, CA 95134
	Email: tian@redback.com
	Jun Zhuang
	Redback Networks
	300 Holger Way
	San Jose, CA 95134
	Email: junz@redback.com
	Dimitri Papadimitriou
	Alcatel
	Francis Wellesplein 1,
	B-2018 Antwerpen, Belgium
	Phone: +32 3 240-8491
	Email: dimitri.papadimitriou@alcatel.be
	Adrian Farrel
	Old Dog Consulting
	Phone: +44 (0) 1978 860944
	EMail: adrian@olddog.co.uk
	The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive
	Director.
	15. Full Copyright Notice
	Copyright (C) The Internet Society (year). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights."
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
	Network Working Group Naiming Shen
	INTERNET DRAFT BCN Systems
	Albert Tian
	Expiration Date: April 2005 Jun Zhuang
	Redback Networks
	D. Papadimitriou
	Alcatel
	Adrian Farrel
	Old Dog Consulting
	October 2004
	IP Traffic Engineering With Route Switched Paths (RSPs)
	draft-shen-ip-te-rsp-03.txt		draft-shen-ip-te-rsp-03.txt
	1. Status of this Memo		1. Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be		or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.		disclosed, in accordance with RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
End of changes. 1 change blocks.
	616 lines changed or deleted		0 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/