Network Working Group Naiming Shen
INTERNET DRAFT Albert Tian
Jun Zhuang
Expiration Date: December 2004 Redback Networks
June 2004
IP Traffic Engineering With Route Switched Paths (RSPs)
draft-shen-ip-te-rsp-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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,
congestion and bottlenecks with or without resource reservations.
MPLS must be enabled on the routers through which the LSPs traverse.
Shen, Tian, Zhuang Expires December 2004 [Page 1]
Internet Draft IP TE RSP June 2004
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 December 2004 [Page 2]
Internet Draft IP TE RSP June 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.
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
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
Shen, Tian, Zhuang Expires December 2004 [Page 3]
Internet Draft IP TE RSP June 2004
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.
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.
Shen, Tian, Zhuang Expires December 2004 [Page 4]
Internet Draft IP TE RSP June 2004
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
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
Shen, Tian, Zhuang Expires December 2004 [Page 5]
Internet Draft IP TE RSP June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6 continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TE Route (IPv6 continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shen, Tian, Zhuang Expires December 2004 [Page 6]
Internet Draft IP TE RSP June 2004
| 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.
(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, Tian, Zhuang Expires December 2004 [Page 7]
Internet Draft IP TE RSP June 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 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. 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.
9. 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.
10. Acknowledgments
The authors would like to thank Changming Liu and Ping Pan for
their comments to this document.
11. IPR Disclosure
Shen, Tian, Zhuang Expires December 2004 [Page 8]
Internet Draft IP TE RSP June 2004
By submitting this Internet draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
13. 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.
Shen, Tian, Zhuang Expires December 2004 [Page 9]
Internet Draft IP TE RSP June 2004
14. 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
Shen, Tian, Zhuang Expires December 2004 [Page 10]