Transcript PPT Version

IP Traffic Engineering RSP
draft-shen-ip-te-rsp-01.txt
Naiming Shen ([email protected])
Albert Tian ([email protected])
Jun Zhuang ([email protected])
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
60th IETF, San Diego, August 2004
2
Routing Area Meeting
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
60th IETF, San Diego, August 2004
3
Routing Area Meeting
An Example
IP TE Prefix
10.1.3.0/24
FIB 10.1.3.1/32
R3
R2
R4
R1
R5
Resv msg with route
FIB 10.1.3.1/32
10.1.3.1
FIB 10.1.3.1/32
Setup an RSP with Path msg

R7
R6
FIB 10.1.3.1/32
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
60th IETF, San Diego, August 2004
4
Routing Area Meeting
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
60th IETF, San Diego, August 2004
5
Routing Area Meeting
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
60th IETF, San Diego, August 2004
6
Routing Area Meeting
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)
60th IETF, San Diego, August 2004
7
Routing Area Meeting
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
60th IETF, San Diego, August 2004
8
Routing Area Meeting
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
60th IETF, San Diego, August 2004
9
Routing Area Meeting