Network Working Group Naiming Shen INTERNET DRAFT Albert Tian Jun Zhuang Expiration Date: January 2005 Redback Networks July 2004 IP Traffic Engineering With Route Switched Paths (RSPs) draft-shen-ip-te-rsp-01.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 just as in MPLS TE technology but no MPLS forwarding capability is assumed on the switched path. IP routing is used to switch IP traffic trunks. A simple RSVP extension is needed to setup the IP route switched paths (RSPs). 3. Introduction MPLS TE [1, 2] LSPs have been developed and deployed to automatically route IP traffic away from network failures, Shen, Tian, Zhuang Expires January 2005 [Page 1] Internet Draft IP TE RSP July 2004 congestion and bottlenecks with or without resource reservations. 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. IP tunnels, for instance, GRE tunnel, IPv6 over IPv4 tunnel, L2TP tunnel, and IPsec tunnel, 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 network 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 capable. A simple RSVP protocol extension is used to signal the setup of the IP route switched paths (RSPs). Most of the protocol extensions used in MPLS TE can also be used in this mechanism without any change. 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 tunnel. 4. Terminology 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. RSP IP Route Switched Path. An explicitly routed IP tunnel setup by the IP TE. It can be IPv4 RSP or IPv6 RSP. Shen, Tian, Zhuang Expires January 2005 [Page 2] Internet Draft IP TE RSP July 2004 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. RSR IP Route Switched Router. The IP node supports IP TE. 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 similar to MPLS TE. Instead of using Label Request Object in the Path message, a new IP Route Request Object 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 IP Route Object 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 can also be used in this scheme 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 MUSH 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 Shen, Tian, Zhuang Expires January 2005 [Page 3] Internet Draft IP TE RSP July 2004 the nexthop. When a RSR 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. 5.1 An Example of IP TE RSPs Consider the RSRs 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) [R1] ==== [R2] ==== [R3] | || || ^ 10.1.3.1 ^ 10.1.3.2 | || || | | | +======= [R4] ==== [R5] | RSPa | RSPb | | | +------------>----------->--+ | ----------->----------------+ 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. In both cases, R3's router-ID 100.1.1.1 is used as the RSP egress address which is not unique among the RSP tunnels. RSP tunnels are still identified in the same way as in MPLS TE LSPs which has nothing to do with the IP TE prefixes. Shen, Tian, Zhuang Expires January 2005 [Page 4] Internet Draft IP TE RSP July 2004 On R1, when the IP traffic 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 An IP TE prefix is configured on each egress RSR. 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 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. RSVP Extension In this document, we define two new RSVP objects: IP Route Request object and IP Route object. This is in symmetrical to the Label Request and Label objects in MPLS TE. 6.1 IP Route Request Object Class = 195 (To Be allocated by IANA), C_Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSP Key | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSP Key It contains a two octet number which may be used between a pair of RSRs to identify two RSPs belong to the same bi-directional IP tunnel. 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. Protocol Type An identifier of the protocol type of tunnel payload using Shen, Tian, Zhuang Expires January 2005 [Page 5] Internet Draft IP TE RSP July 2004 this path. Standard Ethertype [4] values are used. 6.1.1 Handling of IP_ROUTE_REQUEST To establish an RSP tunnel the sender creates a Path message with a IP_ROUTE_REQUEST object. The IP_ROUTE_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 IP_ROUTE_REQUEST object SHOULD be stored in the Path State Block, so that Path refresh messages will also contain the IP_ROUTE_REQUEST object. A node that recognizes a IP_ROUTE_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". An node that does not recognize the IP_ROUTE_REQUEST object sends a PathErr with error code "Unknown object class" toward the sender. In either of the above two cases, the sender MUST bring down the RSP if this is an explicitly routed tunnel. 6.2 IP Route Object The IP TE route MAY be carried in Resv messages. The IP TE route for a sender MUST immediately follow the FILTER_SPEC for that sender in the Resv message. The IP Route object has the following format: Class = 196 (To Be allocated by IANA), C_Type = 1 (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. C_Type = 2 (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shen, Tian, Zhuang Expires January 2005 [Page 6] Internet Draft IP TE RSP July 2004 | 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 a new 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 IP_ROUTE object, 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. RSVP matches a pair of bi-directional RSPs by identifying three fields in the RSVP Path messages: tunnel end-point address, tunnel sender address [2, sections 4.6.1.1 and 4.6.2.1], and RSP Key (section 6.1 above, if there are multiple RSP pairs between the two RSRs). 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 tunnel sender address; 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. Shen, Tian, Zhuang Expires January 2005 [Page 7] Internet Draft IP TE RSP July 2004 (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 tunnel sender address, 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 RSR following the less specific IP TE prefix of the egress RSR. 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 Shen, Tian, Zhuang Expires January 2005 [Page 8] Internet Draft IP TE RSP July 2004 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 Class number for IP_ROUTE_REQUEST object and a Class number for IP_ROUTE 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 Shen, Tian, Zhuang Expires January 2005 [Page 9] Internet Draft IP TE RSP July 2004 Specification", RFC 2205, September 1997. [6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 13. Authors' Addresses Naiming Shen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: naiming@redback.com Albert Tian Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: tian@redback.com Jun Zhuang Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: junz@redback.com 14. Intellectual Property Considerations 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 Shen, Tian, Zhuang Expires January 2005 [Page 10] Internet Draft IP TE RSP July 2004 Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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, Tian, Zhuang Expires January 2005 [Page 11]