1. IP Traffic Engineering RSP draft-shen-ip-te-rsp-01.txt Naiming Shen (naiming@redback.com) Albert Tian (tian@redback.com) Jun Zhuang (junz@redback.com)

2. 60th IETF, San Diego, August 2004 Routing Area Meeting 2 Motivation IP only network can not take advantage of MPLS TE Network backbone IP tunnels, such as GRE, v6-v4, L2TP, IPsec may need to be traffic engineered Applications, such as Nexthop FRR used in pure IP network may use IP bypass tunnel instead of MPLS bypass tunnel Most of the development in MPLS TE can be easily ported here to support IP TE No change in the IP forwarding plane

3. 60th IETF, San Diego, August 2004 Routing Area Meeting 3 Route Switched Path (RSP) Scheme Each egress RSP node is assigned an IP TE prefix, which should be non-globally routable Ingress RSP node decides the path to egress based on traffic engineering requirement just as in MPLS TE Instead of use Label Request Object in Path message, it uses IP Route Request Object Instead of use Label Object in Resv message, it uses IP Route Object. The IP Route Object contains the IP host route allocated by the egress for this RSP Each RSP node along the path installs the IP host route in RIB/FIB towards the path nexthop

4. 60th IETF, San Diego, August 2004 Routing Area Meeting 4 An Example R1 Setup an RSP to R4 explicitly routed through R5, R6 and R7. Each node on the RSP path installs a host route for the allocated 10.1.3.1/32 towards egress Each RSP node along the path installs the IP host route in RIB/FIB towards the path nexthop Setup an RSP with Path msg IP TE Prefix 10.1.3.0/24 Resv msg with route 10.1.3.1 FIB 10.1.3.1/32 R1 R2 R3 R4 R5 R6 R7

5. 60th IETF, San Diego, August 2004 Routing Area Meeting 5 RSVP Extension IP Route Request Object Class and Ctype to be allocated by IANA In Path message 16 bit of RSP Key (for use with bi-directional tunnel) 16 bit of Protocol Type of tunnel payload Similar to the MPLS LSP Label Request Object All the nodes on the RSP path must support this extension

6. 60th IETF, San Diego, August 2004 Routing Area Meeting 6 RSVP Extension (Continue) IP Route Object Class and Ctype to be allocated by IANA In Resv message An 32 bit or 128 bit IP prefix for either v4 or v6 An 8 bit prefix length field Ingress and transit nodes should install the prefix into their RIB/FIB Error code for “IP TE routing install failure” sub-code

7. 60th IETF, San Diego, August 2004 Routing Area Meeting 7 Bi-directional IP Tunnel with RSPs IP tunnel is often used in bi-directional mode in network The RSP keys in IP Route Request can be used to tie both RSPs in opposite direction to form a bi-directional IP TE tunnel Path message contains (source address, destination address, RSP key) Resv message contains (IP TE host address) IP tunnel encapsulation has the header of (source address, IP TE host address)

8. 60th IETF, San Diego, August 2004 Routing Area Meeting 8 Trailing Loose Segment Optimization The egress node advertises the IP TE prefix in IGP The nodes between the egress and the last node on the ERO list should know how to forward the IP TE tunnel traffic without installing the IP TE host route by RSVP The last node on ERO list could have send Path message directly to the egress node, without the Router Alert IP option. The nodes in the middle do not need to keep the RSVP state for the RSP

9. 60th IETF, San Diego, August 2004 Routing Area Meeting 9 Summary Borrowing mechanism from MPLS TE, with a simple extension in control plane, we are able to perform TE for IP It is particularly interesting when the network already deploys IP tunnels in the backbone, and traffic engineering for those tunnels are needed Comments are welcome ! http://www.ietf.org/internet-drafts/draft-shen-ip-te-rsp-01.txt