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 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. Resource ReSerVation Protocol (RSVP) is used as a signaling protocol described in Generalized Multi-Protocol Lable Swithing (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). Shen, et al Expires April 2005 [Page 1] Internet Draft IP TE RSP October 2004 3. Introduction Multi-Protocol Label Switching - Traffic Engineering (MPLS TE) [1, 2] and Generalized Multi-Protocol Label Switching (GMPLS) [7, 8] Label Switched Paths (LSP) 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. GMPLS RSVP-TE protocol extensions are 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. Shen, et al Expires April 2005 [Page 2] Internet Draft IP TE RSP October 2004 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 ingress node. 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. TE LSP An MPLS TE Label Switched Path. An explicitly source routed MPLS LSP tunnel instance along a sequence of LSRs starting at the ingress LSR and ending at the egress LSR. Trailing Loose Segment The last loose segment to the egress node in a strict/loose explicit path. Conventions used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16]. In addition, the reader is assumed to be familiar with the terminology used in [2, 7, 8]. Shen, et al Expires April 2005 [Page 3] Internet Draft IP TE RSP October 2004 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. For the Path message, a new C-Type for the Generalized LABEL REQUEST object referred to as the 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 message, a new C-Type for the Generalized LABEL object, referred to as the 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. Shen, et al Expires April 2005 [Page 4] Internet Draft IP TE RSP October 2004 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. Shen, et al Expires April 2005 [Page 5] Internet Draft IP TE RSP October 2004 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 Shen, et al Expires April 2005 [Page 6] Internet Draft IP TE RSP October 2004 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 object 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 object 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 node 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. Shen, et al Expires April 2005 [Page 7] Internet Draft IP TE RSP October 2004 6.2 IP TE Route and (Generalized) LABEL Object Encoding The IP TE Route is encoded as a (Generalized) LABEL object defined with a new C-Type for IPv4 and IPv6, respectively, and referred in the context of this document to as the IP ROUTE object. The IP ROUTE object 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. This object is defined with the following formats: Class Number = 16 (Class Name: LABEL), 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 (Class Name: LABEL), 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. Shen, et al Expires April 2005 [Page 8] Internet Draft IP TE RSP October 2004 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 TE 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 node that does not recognize the GENERALIZED_LABEL C-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 Shen, et al Expires April 2005 [Page 9] Internet Draft IP TE RSP October 2004 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. Shen, et al Expires April 2005 [Page 10] Internet Draft IP TE RSP October 2004 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. Shen, et al Expires April 2005 [Page 11] Internet Draft IP TE RSP October 2004 [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. [16] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. 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, Shen, et al Expires April 2005 [Page 12] Internet Draft IP TE RSP October 2004 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. Shen, et al Expires April 2005 [Page 13]